Bitcoin Note Security

With the Bitcoin Note we’ve endeavored to create a self-custodial Bitcoin storage solution that mirrors the function of bearer financial instruments like cash. 

There are some significant challenges in doing so; the nature of Bitcoin as a stateless money means that no party has an incentive to remove counterfeit notes from circulation. Conversely, any manufacturer of Bitcoin bearer instruments has an incentive to keep or derive copies of private keys which would allow them to transfer funds without consent of the holder.  

Leveraging a combination of currency-grade printing, secure NFC chips and a time-locked multisig we have worked to mitigate these challenges to create a usable, self-custodial Bitcoin bearer instrument. Our goal is not to move the majority of Bitcoin on to physical notes, but rather that the Bitcoin Note serves as an easy to use tool to onboard family, friends and their communities to Bitcoin with minimal technical hurdles and reasonable guarantees.



  • User: individual who loads and holds the Bitcoin Note.
  • Manufacturer: Offline Cash, the printer of Bitcoin Notes.
  • Client: an application that performs various operations like verification with the Bitcoin Note.
  • Note Server: a backend server that exposes an interface for the client app.
  • Claim by Date: a printed date on the note at which time the note is no longer recommended for use in commerce.



The Bitcoin Note consists of:

  • A denominated note that includes —
    • A durable synthetic paper substrate with high resolution offset printing, micro text features, intaglio and foiled elements.
    • A printed serial number and claim by date.
  • A NFC chip that —
    • Stores two Bitcoin private keys; a user key in plaintext and a manufacturer key, encrypted.
    • Includes a circuit trace on the NFC chip which, when cut, triggers an irreversible change in the NFC chip.
    • Stores encryption keys which are used in order to execute specific actions relative to the memory slots on the NFC chip.
  • A Bitcoin P2SH which —
    • Requires both keys on the note in order to spend associated funds before the claim by date.
    • Downgrades after the printed “claim by” date such that only the user key is required to claim funds.
  • A note server which —
    • Authenticates notes through encrypted sessions
    • Releases decryption keys for the factory key upon validation that the trace on the NFC chip has been cut
    • Signs Bitcoin block hashes and writes them to the note
    • Facilitates re-key procedures whereby the holder requests the creation of a new multisig with a new user key stored on the note.
  • An open source client app which —
    • Arbitrates messages between the note and the manufacturer server
    • Writes to and reads from memory slots on the note relating to the key material as well as with respect to the memory structure.
    • Audits messages between the note and the manufacturer server as well as the memory structure of the note with respect to a checksum.

All value of a Bitcoin Note relates to the P2SH; the printed security features have no bearing on the ability to spend associated Bitcoin. They indicate the intended Bitcoin value stored as well as when spending should occur to ensure that no previous holder can spend the funds.



A note is first provisioned by the manufacturer. For each note manufacturer generates a unique ECDSA secp256k1 key pair, the manufacturer public key and manufacturer private key, and a unique AES key, the server wrapping key.

The manufacturer public key is stored on the  note in plaintext. The manufacturer private key is generated and then encrypted using server wrapping key. The encrypted form of the manufacturer private key is stored on the note. This data is written to the note, together with a face value and a claim by date. At this point, the note still has no value.


In order to make use of the note, the first holder or user must perform a personalization process. This is done using a dedicated client application. 

During the process, the user generates a unique ECDSA secp256k1 key pair, the user public key and user private key. This key pair is stored on the note, both portions in plaintext.

From the manufacturer public key and user public key, a Bitcoin P2SH is created with the following conditions: 

  • If current date is before the note’s claim by date: the P2SH is a 2-of-2 multisig. A signature with the manufacturer private key and user private key is required in order to withdraw funds.
  • If current date is after note’s claim by date: only a signature with the user private key is required in order to withdraw funds.

The user is instructed to send the face value of BTC to the address corresponding to the P2SH. The process is complete after the sufficient amount of funds appears on the wallet. By default the client app will use any excess funds for miner fees. If the note has insufficient funds, it will show as invalid when scanned.

Key Rotation

A user may rotate the user private key. During the process, a new key pair will be written to the note, without overriding the current key pair. Because the user’s key pair has changed, a new P2SH multisig will be generated, with the same conditions as described in “Personalization” above. 

The user must present the server with the encrypted manufacturer private key such that in memory the server can generate a transaction to move funds from the old wallet to the new wallet, sign it with the manufacturer private key and provide the transaction to the user. 

The user adds a signature with user’s old private key from the note and dispatch the transaction to the network. The process is finished after the funds are successfully moved to the new P2SH multisig. 


A user is able to withdraw the funds covered by the  note to an arbitrary Bitcoin address.

In order to do so, they need to mechanically cut a trace in a designated place one the  note (indicated by “Cut to claim”). This will trigger a function in the NFC chip indicating that it is in claim mode. This process is irreversible, so carefully re-connecting the trace will not reset the triggered state in the chip.

The user needs to use a dedicated client app that facilitates communication between the chip and note server. The server will validate whether the note’s chip reports tampering alert. If so, the server will release the server wrapping key to the user.

With possession of both the manufacturer private key and user private key the user can create a transaction to remove funds from the associated P2SH address.

Chip Specification

Memory Slots

The NFC chip includes three memory slots with different write capabilities: 

  1. Persistent Slot: stores information including URL, the denomination of the note, the time until the claim by date and the manufacturer keys. Cannot be written by either the client or note server.
  2. Server Slot: stores information from the note server about the note lifecycle, a nonce and a note server signature of a Bitcoin block. The client may allow writes to this slot by the note server in an audited fashion.
  3. Client Slot: stores information written by the client including the user keys as well as a sha256 hash of the persistent memory slot data. Writable only by the client.

The state of the NFC chip is tracked across various stages of the note lifecycle by the note server. The server records a single source of truth of a note’s state whereby the server memory slot is synchronized with the server with each online verification.

Communication and Authentication

The client app acts as a proxy, forwarding messages between the Bitcoin Note and the Note Server. The NFC chip has a secure authentication protocol which includes the following properties:

  • Authentication is performed using challenge-response scheme with an AES cipher.
  • Each authentication generates a unique set of session keys, which are valid only while the chip is powered (i.e. invalidated after removing a phone or reader from the chip) providing protection against reply attacks.
  • After authentication, all commands for the NFC chip are signed using the session key.
  • Successful responses of NFT chip are signed using the session key.

Client App Command Whitelist

The app includes a command whitelist whereby it verifies each command transmitted to the NFC chip from the note server and denies execution of disallowed commands (for instance, an attempt to read the user private keys).

Potential Risks

Corrupted Memory Slot 

The client could write corrupted data to the client’s memory slot due to a bug in software or software modification. The server is reliant upon the client correctly writing data to the client memory slot.

Inconsistencies will be detected by subsequent clients attempting to validate a corrupted note. It will be either: 

  • Result in a parsing error of the client’s memory slot (detectable offline)
  • Result in an inconsistent persistent memory slot hash (detectable offline) 
  • Result in a scenario where the note server stored user public key doesn’t match the user private key stored on the  note (detectable online only)

Malicious Server 

A malicious note server may carry out several actions:

  • For the chips that were not personalized yet: issue a command that breaks settings permanently rendering the  note unusable. 
  • For all chips: issue a command that will corrupt the server memory slot. Such notes will be temporarily rejected on the client-side, but it would be possible to recover from this attack. 
  • Release all server wrapping keys, allowing all current holders to decrypt manufacturer private key. 

Information Harvested by Malicious Client

A malicious client app could harvest information about Bitcoin Notes it has encountered. The attacker would obtain:

  • Encrypted manufacturer private keys
  • Manufacturer public keys
  • Manufacturer private keys

If a server wrapping key is stolen or leaked then a transaction for immediate withdrawal of the funds for notes where this information has been harvested may be created. 

Rotating the user keys during the lifecycle of the note alleviates this problem.

Chip Fault 

The note could stop responding to the commands or experience memory corruption. If the encrypted manufacturer private key and user private key are still readable, funds may be recovered if the wrapping key is manually released or the expiration date is exceeded. If the keys are not readable, the funds are lost.

Chip Counterfeit

There are no known attacks against the NFC chip used in the Bitcoin Note which would allow for the creation of a counterfeit chip. Such an attack would require successful recovery of the authentication keys of each individual chip intended for counterfeit.

In order to counter these kinds of possible attacks the server memory slot contains a nonce value. This value is stored both on the server and on the chip. Upon each online verification, the server reads the nonce from the chip and compares it against the value in the note server database. The note server updates the nonce during each online verification. Likewise, only when this check is complete will the server write an updated signature to the note.

A mismatched nonce could indicate counterfeit chips in the field, however, only one chip between an original note and the counterfeits would validate moving forward.