The Word 'Yield' Was Doing Too Much Work

Every reserve-backed credit system keeps two ledgers whether it admits it or not: what was put in, and what it earned. Ours was keeping one and calling it two things.

Our depository contract tracks a credit expansion multiplier — the ratio that decides how much synthetic credit a pool of deposits can support. Reserve backing arrives through an attestation function. The treasury process that deploys accumulated order revenue was calling the one named attestYield — which meant deployed principal and measured yield were being written to the same line, under the yield label.

Yield is a claim about performance. Principal is a claim about deployment. Conflating them overstates what the reserve has earned — a nuance that survives until the first serious reader checks the math, and then it becomes a credibility question.

Three fixes in one pass

Split the attestation. attestPrincipal and attestYield now mint into separate cumulative counters with separate events. Deployed principal is what the treasury process attests when it moves accumulated fees to the reserve. Measured yield is what gets attested after the reserve's value is reconciled against that principal. The event log now says which is which — an auditor reads it and knows what the money is.

Isolate the multiplier per pool. The expansion multiplier was global — reserves attested against one deposit pool lifted available credit on every pool. Each pool now computes its own multiplier from its own reserve/deposit ratio, with a governance-set default for pools that have never been attested.

Make it bidirectional. Reserves could only ratchet up — there was no code path for "the deployed value fell." reviseReserve is the downward correction: gateway-signed, event-logged, and it recomputes the affected pool's multiplier in whichever direction the evidence points. A control that can only move upward isn't a control; it's a ratchet with good intentions.

The migration was small on purpose

The vault's live state was a single deposit pool. We deployed the new contract, withdrew the position from the old one, re-deposited on the new, and repointed the service layer. Same keys, same pool ID, same deposits — new rules.

What didn't change: user deposits remain structurally untouchable by the reserve machinery, and reserve attestations remain gateway-signed. What changed is that the ledger now distinguishes deployment from performance, pools carry their own multipliers, and the number can go down when the truth does.

What ships next

The reserve rail's production-network credentials are staged. The contract and the attestation code already speak the production ledger's language; the cutover itself is gated on one thing — funded, verified accounts on the other side. Account creation there happens by inbound funding: the keys exist, the balances do not yet. When they do, signed transactions complete the accounts, the network flag flips, and the first production sweep reconciles against the public mirror before any external claim is made. The staging network did its job: it proved the loop arms, fires, and reconciles end to end before real value moves.