One device, two lives

A hardware wallet that is also always online has a problem. The connected half is where a remote exploit is most likely. The offline half is where one would be permanent. We wanted a guarantee, not a convention: code running in the Nostr life must not be able to reach the bitcoin seed, not even by rebooting the processor into the bitcoin life, and the only thing that reopens the bitcoin life is pulling the power, which clears any exploit from memory before the seed is ever decrypted. The guarantee had to be enforced by a part the application processor cannot impersonate.

The full technical note is below as a PDF. This page is the short version and the public record of the publication.

Why publish instead of patent

We are not filing a patent on this. A dated, public, enabling description is prior art: once it is out, nobody else can validly patent the same mechanism, in Australia, the US or Europe. That is the outcome we want. The idea belongs to anyone who wants to build it, and the only thing a patent would have bought us is the right to stop them.

The one risk of this route is an examiner not finding the write-up. So the note is written to be found and to be complete: every secure-element object identifier, every policy, the exact byte derivation of every latch value, a sequence diagram from cold boot to key gating, and a list of everything the design does not claim. A competent embedded engineer can reproduce it from the PDF alone. If a change in plan ever did mean a patent, Australia's twelve month grace period for an inventor's own disclosure runs to the complete application, so this page does not close that door. It just means we would need to decide before 21 October 2027.

The mechanism in one paragraph

Inside the NXP SE051 there is one persistent 32-byte register, a PCR, that we call the mode latch. A PCR can only be moved forward: each write hashes the new data onto the old value, and only a holder of the DELETE right can reset it to its starting point. The two PINs can extend it but never reset it. The STM32G0, a second microcontroller whose reset pin goes only to the programming pads, is the only party with the reset right, and it will reset the latch exactly once per physical boot of itself. The bitcoin seed key is wrapped by an SE key whose decrypt right is granted to the bitcoin PIN only while the latch equals a value that is derived from a secret held in the G0 and nowhere else. The Nostr key's wrap is granted to the G0 only while the latch equals the public Nostr value.

Once the Nostr PIN has moved the latch, nothing the application processor can do, with or without any PIN, with or without a reboot, brings it back to a value the seed key will accept. Only pulling the power does.

The five values

In the bitcoin life every signature goes through the whole cycle: the bitcoin PIN arms the latch, the G0 resets it and mints BTC, the secure element strips its layer of the seed for that PIN session, and the G0 burns the latch to SPENT before it strips its own layer and signs. BTC exists in the latch for milliseconds. A crash, a power-off or a removed G0 leaves SPENT, which opens nothing.

Three things we learned on the way

The note records the parts of the chip's documented behaviour that did not hold on silicon, because those are the parts a reader would otherwise trust and be wrong about.

1. The SE cannot witness a power cycle on its own. Every transient object type is refused on this applet, so there is nothing that clears only when the power goes away. The witness had to be the second microcontroller.
2. A PCR clause on a PIN object is accepted but not enforced. We built two throwaway PINs, one gated on the wrong latch value, and both opened. The gate has to sit on the key operations, not on the PIN.
3. Two policy entries for the same credential are not OR'd. Only the first is read. Entries for different credentials are. So every policy in the design carries one entry per credential, and the seed key splits its rights across the two PINs.

What it does not claim

• Protection against someone holding the device and the bitcoin PIN. That is the owner.
• Protection against code that survives in the application processor's flash across a power cycle. That is secure boot's job, and it is a production step.
• Readout of the G0 before its read-out protection is set, also a production step.
• Transaction substitution during a genuine signing. The processor cross-checks every input, you verify outputs in your coordinator wallet, and we recommend multisig.