Custody design for tokenized reserves

One design, not two

Programmes with a reserve behind them routinely run two workstreams: a custody workstream about keys and approvals, and a reconciliation workstream about the daily close. They are the same design. The custody boundary determines what can move without the reserve knowing, and the reconciliation model determines how quickly that divergence is detected. Split them and each team assumes the other has covered the gap.

Where the authoritative balance lives

The question to settle before any contract is written: when the on-chain supply and the custodial position disagree, which one is the institution’s answer to a holder asking what they own? There is a defensible answer either way, and the wrong outcome is having neither answer written down, which is the state most programmes are in when the first break occurs.

The daily close

• A stated toleranceThe size of difference that is operationally normal, agreed with finance rather than assumed by engineering.
• A named ownerOne person accountable for open breaks, with an escalation threshold above which they must escalate.
• An authority rule while a break is openWhich record the institution answers from during the window. This is the sentence that is always missing.

Designing for the resignation

Reserve-backed programmes concentrate signing authority in a small number of senior people, which makes them unusually exposed to the attrition failure described elsewhere in this hub. Design the rota with a margin, alarm on the margin, and rehearse the recovery on the staging reserve at a fixed cadence rather than when someone remembers.

What to write down

The authority rule, the tolerance, the escalation threshold, the break owner, and the rehearsal cadence. Five short paragraphs, agreed before the contract interface is frozen. On at least one engagement we settled the interface first and retrofitted the break procedure, and it cost weeks a programme built the other way round does not spend.