Cashu is an open protocol for e-cash: digital tokens issued by a mint. They often represent bitcoin amounts; deposits or withdrawals can be made through the Lightning Network, for example. Holders control the tokens, not the mint’s bitcoin keys, and still depend on its cooperation.
Imagine Anna sending Petr a Cashu token in a private message. She is not broadcasting a Bitcoin transaction. She is handing over data that Petr can redeem at the relevant mint. A token can contain one or more proof records, called Proof in the specification. Each record includes an amount, a secret value and a mint signature, among other fields. Cashu is a shared protocol, not one service with a common reserve. The issuer, currency unit and signing keyset all matter. An amount in sats denotes small units of bitcoin; the same number in another unit means something else. One mint’s tokens are not automatically accepted by another. For readers interested in the format, V4 uses compact CBOR binary encoding and carries proofs from a single mint. [1] [2] [9]
Anna can keep a copy of an ordinary token with no additional spending conditions. Petr therefore needs a swap: his wallet submits the old proofs to the mint and receives new ones with secrets Anna does not know. The mint invalidates the old inputs. That successful exchange prevents Anna from spending the same copy again. A state check alone is insufficient. UNSPENT means the mint has no record of processing or spending; it does not reserve anything for Petr. PENDING means processing is under way, while SPENT means the proof has been redeemed. Do not publish a token as if it were a payment receipt: whoever gets a usable copy may win the race to redeem it. [3] [5]
A Blind Signature helps separate token issuance from later use. The wallet creates a secret, hides its mathematical representation and asks the mint to sign it. It then removes the blinding. The mint should not be able to identify the earlier issuance request from the redeemed token itself. This does not conceal everything: denominations have different keys, so the issuer knows which value classes it issues. The technical method is called BDHKE and uses the secp256k1 curve. You do not need to calculate curve points to understand a payment; what matters is which link this mathematics protects. [1]
The optional NUT-12 extension adds DLEQ, a mathematical proof that the signing key is the same private key corresponding to the mint’s public key. With the necessary accompanying data, Petr can verify the signature without contacting the mint. It cannot tell him whether another copy has been spent, whether the service responds or whether sufficient bitcoin reserves exist. If DLEQ is included, the specification requires the wallet to verify it. Signature verification still does not replace a completed swap. Counterparty risk—the risk that the operator fails to perform—remains. [7]
Petr may want to pay a Lightning Network request rather than receive more tokens. This exchange is called melt. The wallet first requests a quote: how many tokens in which unit, how long the quote remains valid and whether it includes a fee reserve. Input fees may apply as well. It then submits proofs and the mint makes the external payment. HTTP 200 indicates a successful web request, not necessarily a paid bill. PENDING still means processing, whereas PAID reports success. The wallet must follow the final outcome and any confirmation specific to the payment method. [4]
A mint can rotate its signing keyset. active=false means no new tokens are issued under the old set; that alone does not stop old proofs being accepted as inputs. Optional final_expiry is different: after this final deadline, the specification no longer requires the mint to redeem tokens from that keyset. Do not confuse these situations. The input_fee_ppk fee is also charged per input, not simply as a percentage of the amount sent. Rates for all proofs used are added, the sum is divided by 1000, and only then is the fee rounded up to whole units. For example, with a keyset denominated in sat, 3 inputs at 100 ppk each give a sum of 300; after division and rounding, the fee is 1 sat. Two payments of the same value can therefore cost different amounts if they use different numbers of proofs or different keysets. [2]
A blind signature does not remove payment timing, amounts or network connection data. Even the way a wallet requests new denominations can reveal information. NUT-03 recommends ordering requested values from smallest to largest, so their order does not unnecessarily reveal the split between payment and change. Repeated sender queries about the state of transferred tokens can also help link sender and recipient. Cashu provides tools for more private circulation of money; it does not mean every application or situation automatically hides every connection. [3] [5]
Recovery must match the wallet and mint in use. NUT-13 describes deriving token secrets and blinding factors again from the seed—the starting secret—together with the keyset and a counter. Keyset version 01 uses HMAC-SHA256; older 00 uses BIP32. The mint supplies signatures the seed cannot create through NUT-09, after which spent states must be checked. “I have a Seed Phrase, so I can restore everything anywhere” is therefore insufficient. Before relying on a wallet, check its backup and recovery procedure and try a small withdrawal. A backup cannot make a vanished mint respond or replenish its reserves. [8] [6]
For the clearest picture, read this entry together with Fedimint, Chaumian eCash, Blind Signature, Lightning Network, Counterparty risk, Satoshi. The reverse links also lead from Chaumian eCash, Blind Signature, Fedimint, Fiduciary Media.