03 — Issuance to redemption
Issuance, reserve custody, attestation and a redemption path that still clears when everyone asks at once.
A stablecoin is a redemption promise with software attached. The software is the easy half. The hard half is proving the reserve exists, proving it is unencumbered, and holding the redemption path open on the day the promise is tested — which is the only day that matters.
We build the issuance and burn mechanics, the reserve custody and segregation model, the attestation pipeline that produces evidence on a schedule rather than on request, and the redemption flow with its queueing and stress behaviour designed in advance rather than discovered.
Common questions
What does a stablecoin attestation actually prove?
That a stated quantity of reserve assets existed at a point in time in accounts the issuer controls. It does not by itself prove those assets are unencumbered, that they are liquid at par under stress, or that the issuer can meet redemptions at speed. A credible programme addresses all four and publishes on a fixed schedule rather than on request.
How should redemption behave under stress?
Predictably and publicly. The queueing model, per-holder limits and settlement windows should be documented before launch and unchanged during an event. Discretionary redemption decisions made during a run are what turn a liquidity problem into a solvency narrative.
What does MiCA require of a stablecoin issuer?
In broad terms: authorisation in an EU member state, reserve assets held one-to-one and segregated, redemption at par on demand, published white paper disclosures, and ongoing reporting. The detail varies by whether the token references a single currency or a basket, and thresholds trigger additional requirements. Take this as orientation, not legal advice — the applicable requirements should be confirmed with counsel in your jurisdiction.
Next capability
Banking-as-a-Service
Bring us the hard part.
Forty-five minutes with the people who would actually run the build.