Skip to content

Insights

Redemption is not a feature. It is the only thing being tested.

4 min read

In short

A stablecoin platform is judged on whether redemption clears when everyone asks at once, not on whether issuance works. That requires three things designed together: reserve custody where the assets can actually be liquidated on the timeline redemption promises, attestation frequent and granular enough to be believed before a stress event instead of during one, and a redemption path with no operational step that depends on a person being awake. Platforms that treat redemption as the reverse of issuance discover the difference the first time volume is one-directional.

Issuance is easy and proves nothing

Minting against a received deposit is a straightforward flow, and it is the one that gets built first, demonstrated and measured. It also runs almost exclusively in benign conditions: volumes are manageable, the operator is motivated, and nobody is watching closely.

Redemption runs in exactly the opposite conditions. It matters most when it is busiest, when the reason it is busy is that confidence is falling, and when every delay is read as evidence. A redemption path that is merely the inverse of issuance inherits none of the properties it needs.

Reserve composition is a liquidity question, not a yield question

Reserves get optimised for yield because yield is the visible number and holding cash is the visible cost. The constraint that actually binds is settlement timing: whether the assets can be converted to the redemption currency on the timeline the product promised, in the size the product might be asked for, on a day when markets are not cooperating.

Instruments that are liquid in normal conditions can settle on timelines that make a same-day redemption promise undeliverable. That mismatch does not appear in any dashboard during good weather. It appears once, at the worst possible time, and it is the mechanism behind most stablecoin failures that were not outright fraud.

Attestation is a trust instrument with a shelf life

Attestation exists to make a claim about reserves checkable by someone who does not trust the issuer. Its value therefore depends almost entirely on frequency and granularity, and it decays quickly. A monthly report is nearly worthless in a week where confidence is moving hourly.

The engineering consequence is that attestation should be a continuous property of the system, not a periodic exercise imposed on it. If producing the figure requires people to assemble it, the frequency will be set by how much effort that takes, which is precisely the wrong input. Reserve position, liabilities outstanding and the reconciliation between them should be derivable on demand.

The reporting cadence then becomes a policy decision, not an operational limit, and the number can be published during a stress event instead of six weeks after it.

The redemption path should not need a human

Most redemption flows contain at least one step that is operational rather than automatic. A treasury instruction, an approval, a manual transfer above a threshold. Each is defensible on its own and each is a queue in an event where the queue is the problem.

The design goal is that redemption below a defined size clears without intervention, that the controls gating it are enforced in the path rather than applied by a person, and that the thresholds requiring judgement are set high enough to be rare and low enough to be safe. Where a human step is genuinely unavoidable, it needs defined coverage and a documented escalation, not an assumption that someone will be reachable.

The peg is a consequence, not a mechanism

Discussion of stablecoin design tends to centre on the peg as though it were a thing the system does. It is not. The peg is what arbitrage produces when redemption is credible and frictionless, and it holds exactly as long as that remains true.

This reframing has a practical consequence: effort spent defending the price is usually effort spent in the wrong place. If redemption clears reliably at par, arbitrageurs restore the peg without being asked, because doing so is profitable. If redemption is slow, gated, or uncertain, no amount of market operation holds the price for long, because the trade that would correct it has become risky.

So the engineering question is never "how do we hold the peg". It is "what would make a professional counterparty confident enough to buy at a discount and redeem". And every answer to that is about settlement timing, operational reliability and evidence.

Build the bad day first

The practical discipline is to design the stress case before the happy path, because the happy path is a subset of it and never the other way round. What clears when redemption volume is one-directional for a week? What is the largest single redemption that completes without a person? Which reserve assets are available on the day, at what haircut, and who confirms it?

A platform that can answer those questions has an architecture. One that cannot has an issuance product with a redemption endpoint attached, which is a different thing, and the difference only ever becomes visible once.

Bring us the hard part.

Forty-five minutes with the people who would actually run the build.