The point of the secure element is to hold value. The point of the record is to say who holds it. This page is about the second part, because that is where a double spend would live.
Every token lives in a slot on a smart card chip held by the bank. That chip is the root of the digital cash: it is where the value physically is, it is what a reconciliation reads, and it is the thing the bank can point at when asked to prove an instrument exists. Nothing is destroyed — a token that is spent or redeemed stays in its slot and changes hands.
MongoDB holds the ownership record. For each instrument the database says who may spend it, what state it is in, and which chip and slot hold it. That record is what retail runs on: a till, a phone, or a counter asks it, and the answer is authoritative because the owner of the record is also the owner of the chip.
The card in a customer's hand is an authority copy. It carries the same identifier, denomination and contract, so the holder can prove possession and cause a movement — offline if need be. Possession is not ownership: the record decides, and a copy whose record has moved cannot claim anything.
Everything else in these documents follows from those three sentences. Capacity is
chips × slots, because a token needs a physical place to exist. A merchant's float
is a set of tokens whose ownership record names the shop. A cash-out returns ownership to the
bank and the token to the shelf, rather than deleting anything. And the reason a phone wallet
cannot hold cash is that it has no slots — only a key — which is why the phone authorises
movements of tokens that live at the bank.
CoinCard is a digital cash design: a bank-issued instrument lives in a tamper-resistant chip the holder carries, and moves without a consensus network, without a public ledger, and without every participant maintaining a copy of every balance. The chip is what makes the value hard to forge or copy. There is no chain because there is nothing to agree on between strangers — one issuer stands behind its own instruments.
The record is the arbiter; the card is evidence. A token's value is claimed by whoever the issuer's record currently names as its holder. The copy in a card slot proves the holder has the instrument — its identifier, its denomination, its contract — but possession alone does not create a claim. Once the record moves to another holder, the copy in the old card is inert: it can still be read, and it will still fail to claim anything, because the record no longer names the card that would present it.
The chips are not there for speed. They are there so that at some future moment — a dispute, an audit, a regulator's question — the issuer can answer four questions with something better than its own assertion:
| Question | What answers it |
|---|---|
| Did this instrument exist? | The chip: the token is in a slot, readable, on a card the issuer registered. |
| Was it for that value and those terms? | The issuer's signature over the canonical terms, and the anchor record of what was signed. |
| Who held it, when? | The ownership record and its ledger entries; the sweep, transfer and redemption rows carry timestamps. |
| Which physical object was it? | The master-signed vault identifier on the card, the slot index, and the serial derived from the identifier and the denomination. |
None of that depends on the answer arriving quickly. A reconcile runs daily; an adoption is done once; a proof is assembled when somebody asks. What the design owes is that the pieces agree — and where they disagree, that the disagreement is visible rather than papered over.
| Where | What it is | What it can do |
|---|---|---|
| The bank's record | The value. The instrument exists here, with its denomination, its backing terms and a named holder. | Nothing on its own. It cannot be spent by being read; it can only be reassigned by the issuer's authority. |
| The card's token | The power to transfer that value, plus evidence of what the instrument is — identifier, denomination, contract, signature. | Authorises a movement. It is a capability, not a balance: it confers the right to instruct, not a quantity of anything the card owns. |
| Escrow | The moment of change. The record of the transfer, written before the sender's authority is consumed. | Turns a transfer into an event with a time, a pair of parties, and an audit trail. |
So the card does not hold a balance and never needs to. It holds the right to move one instrument, and that right is consumed by use. The value stays where it was issued.
The ordering is deliberate, and it is the opposite of erase-first. Escrow writes the record of the transfer before the sender's authority is removed:
1 the sender's card authorises the transfer ← the capability is exercised 2 escrow records the transfer and names the new holder ← the value has moved, on the record 3 the sender's token is removed from the card ← the capability is spent 4 a receipt closes the transfer ← evidence for both sides
Between steps 2 and 3 the sender's card still carries a token that has already been spent. It is harmless, because authority over that instrument no longer lies with the card that holds the copy — the record names somebody else. Removing it is housekeeping, and its removal cannot change who owns the value, because ownership was never stored in the card.
The same ordering, stated as a rule:
1 the record changes owner ← the arbiter moves 2 the previous card's copy can no longer claim value ← immediately, by rule 3 the copy is erased from the previous card ← hygiene, not safety
Between steps 1 and 3 two physical copies exist. Only one of them can claim, because claiming is a question asked of the record, not of the chip. Erasing is done to keep the physical inventory honest and to stop a stale copy being presented at a counter where an operator might pay first and reconcile later.
| Property | Consequence of record-first |
|---|---|
| Dispute resolution | A holder who loses a card still holds a claim if the record names them; the instrument is not lost with the plastic. |
| Reversal | An erroneous transfer can be corrected by the issuer, because ownership is a decision the issuer makes, not a fact the card enforces alone. |
| Audit | Every movement has an issuer-side entry. A regulator asking "who held this at time T" gets an answer without interrogating hardware. |
| Recovery | A damaged chip is a re-issuance problem: the value did not leave the issuer's book when the card broke. |
This is what makes it a bank product rather than a bearer note. A note is valuable because whoever holds the paper owns it; an instrument whose ownership the issuer records is valuable because the issuer stands behind it, and the chip is how the holder proves they are the one the issuer named.
A record-first claim needs the record to be reachable. When two cards must exchange value with no network — a basement, a village, a sealed appliance — there is nobody to ask, and the ordering reverses:
1 the sender's spend capability is irreversibly locked and relinquished 2 the payload is transferred and stored on the receiving card 3 the sender's copy is confirmed gone, and a receipt is issued
Here safety comes from the erase, because there is no record to appeal to. The cost is real and worth naming: an interruption can destroy value. Destroying a token is the acceptable failure; duplicating one is not. That is the trade the offline appliance exists to make, and why it has two sockets, retention sensing and a durable journal.
At a shop or a bank branch that accepts CoinCard, the card alone is what the customer presents. No phone, no app, no account login, no internet on the customer's side:
1 the terminal selects the applet and the customer enters their PIN ← possession proved 2 the card returns the instrument: identifier, denomination, contract, signature 3 the terminal asks the issuer whether that instrument is still unspent ← record consulted 4 the issuer marks it redeemed and credits the merchant ← atomically, once 5 the merchant hands over cash, and the card's slot is cleared ← capability retired
Two checks make this safe, and they answer different questions. The PIN proves the presenter is entitled to use this card; it is verified inside the chip, with a limited number of attempts. The record proves the instrument has not already been spent; it is verified by the issuer, and marking it redeemed is a single atomic step, so a second terminal asking about the same instrument a moment later is told it is gone.
Neither check is sufficient alone: a PIN without the record lets a cloned token be spent twice, and the record without a PIN lets anyone who picks up the card cash it.
A terminal that cannot reach the issuer cannot complete step 3, and therefore cannot safely pay. Offline acceptance would need a risk limit per card — the same shape as offline card payments — with a settlement window and a floor under the merchant's exposure. That is a design decision for a pilot, not something to invent at a cash desk.
Status. Presenting a card and reading its slots works, and the issuer can pay against a presented slot exactly once (the receipt is the pair of vault identifier and slot identifier, so a repeat presentation is refused). What is not built is the terminal side of the conversation — a merchant-authenticated endpoint, and a counter application that clears the slot after payment. Until those exist, the same effect is achieved through the account paths rather than from the card alone.
| Situation | Arbiter | Failure mode |
|---|---|---|
| Both parties online | The record | None that loses value; a stale copy simply cannot claim. |
| Two cards, no network, one appliance | The erase | Interruption may destroy the token. It cannot duplicate it. |
| Card presented at a counter | The record, checked against the chip | An unrecorded chip copy is adopted or refused before payment, never paid twice. |
AVAILABLE with its signature intact and is resold; only the holder
changes.Not "a token cannot be copied" — a bit string can always be copied. What is claimed is that a copy is worth nothing unless the issuer's record names it, and that the record moves before the physical erase, so the window in which two copies exist is a window in which only one of them is a claim. Duplication becomes a storage problem, not a monetary one.
Sandbox deployment, USD, English. Test values, not money. This page states the ownership rule the implementation follows; where the implementation is partial, the list above says so.