Operate stablecoins after issuance
Run the post-issuance stablecoin lifecycle across holder eligibility, reserve and collateral updates, controlled minting, transfers, burns, and reconciliation.
Operate a live stablecoin as a controlled loop: verify holder eligibility, refresh reserve or collateral evidence, mint only after programme approval, move existing supply between eligible holders, burn supply during redemption, and reconcile the platform view with treasury, custody, accounting, and client records.
This page is for operations, treasury, compliance, and platform teams that already have a stablecoin asset or are preparing the first post-issuance run.
DALP enforces token controls. The issuing institution maintains the reserve, payment, legal, and accounting evidence outside the token contract.
For the executive model, start with Bank-issued stablecoins for controlled on-chain settlement. For API deployment, use Deploy and mint a stablecoin. For the architecture split, read Stablecoin trust boundaries.
Operating model
The stablecoin lifecycle in DALP has six repeatable stages. The platform records token state and enforces configured controls. The institution still owns reserve custody, treasury approval, banking ledger entries, payment execution, client disclosures, and external compliance operations.
| Stage | Platform state to check | External operating evidence |
|---|---|---|
| Holder readiness | Identity records, trusted issuer claims, jurisdiction controls, transfer rules, holder balances | KYC/KYB files, sanctions screening, onboarding approval, case-management outcome |
| Reserve or collateral update | Collateral claim amount, expiry, collateral ratio, mintable supply, token documents | Reserve movement, custodian evidence, treasury approval, accounting entry |
| Mint | Supply management role, token pause state, configured collateral check, transaction request status | Funding confirmation, programme approval, client instruction |
| Transfer | Sender and recipient eligibility, transfer controls, holder balances, transaction status | Payment workflow decision, case alerts, client communication where required |
| Redemption burn | Burn action, holder balance reduction, total supply reduction, lifecycle events | Fiat payout, reserve release, client statement, bank ledger posting |
| Reconciliation | Holders, total supply, events, documents, price or feed state, collateral stats | Treasury, custody, accounting, client, and reporting systems |
This model matches the documented platform invariants used across the stablecoin, collateral, minting, burn, and transaction-tracking pages: stablecoins use the same EVM token lifecycle as other assets, add stablecoin-specific reserve and collateral checks before minting, expose indexed holder and supply state after transactions, and keep fiat reserve operations outside the token contract.
Prerequisites
Before you run the loop, confirm these controls are in place:
- The stablecoin asset exists and the operating account has the required supply-management permission.
- Holder identities and trusted issuer claims exist for the compliance rules configured on the asset.
- Collateral-backed minting, when enabled, has a trusted issuer for the collateral topic and a current collateral claim on the asset identity.
- Treasury or reserve teams have approved the off-chain reserve movement before any mint that increases issued supply.
- Your team can track long-running writes through transaction request status before retrying or reconciling.
Steps
Check holder eligibility
Open the asset's holder and compliance views before minting or transferring supply. The recipient may need an identity record, a trusted issuer claim, a permitted jurisdiction, or another configured control before the transfer can execute.
If a holder is missing required verification, complete the identity or trusted issuer workflow first. Do not treat a failed transfer as proof that the wallet is wrong. The configured compliance rule may be doing its job.
Update reserve or collateral state
Confirm the off-chain reserve evidence first. Then update the platform state that the token lifecycle uses: token documents, collateral claim amount, collateral expiry, price or feed values, and any configured backing metrics.
For collateral-backed stablecoins, DALP checks the recorded collateral claim and the configured collateral ratio before allowing additional minting. The collateral update records an amount and a future expiry timestamp. The collateral view can show total collateral, required collateral, available collateral, mintable supply, utilisation, collateralisation percentage, and parity confidence. If indexed collateral data is incomplete, parity confidence is degraded rather than presented as a clean match.
Treat the collateral claim as a mint-time control input, not as proof that the off-chain reserve exists by itself. Keep the bank statement, custodian report, treasury approval, verifier attestation, and accounting entry with the runbook evidence for the mint or burn cycle. If the collateral claim and external reserve records disagree, stop the supply change until the institution resolves the source record.
Mint after approvals and checks
Mint only after reserve funding, programme approval, holder eligibility, supply permission, pause state, and collateral checks are ready. A successful mint increases total supply and credits the holder after the transaction completes and indexed views catch up.
Send each mint with a stable idempotency key for that approved instruction, then save the transaction request ID or transaction hash returned by the operation. Use Transaction tracking before retrying a mint after a timeout or temporarily stale view.
Transfer existing supply between eligible holders
Transfers move existing supply between holders. They do not change total supply. Check both sender and recipient eligibility, because a configured rule can block the transfer even when the sender has enough balance.
DALP records the token movement and exposes holder, activity, and transaction status. External payment messages, banking rail execution, and client communication remain programme-specific integrations around the token lifecycle.
Burn during redemption or supply reduction
When a holder redeems stablecoins for fiat, burn the corresponding token amount from the holder after the redemption instruction and approval path are complete. The burn reduces the holder balance and total supply.
Treasury, payment, and banking systems still own the fiat payout, reserve release, bank ledger posting, and client statement. The burn records the on-chain supply change that those systems reconcile against.
Reconcile and investigate gaps
Reconcile the platform view against treasury, custody, accounting, and client records on a regular cadence. Compare holders, total supply, mint and burn history, collateral claims, collateral ratio metrics, price or feed state, token documents, and transaction request status.
If the transaction is final but a read view is stale, poll the affected read side for a short period instead of resubmitting the write. If external reserve evidence and platform state disagree, pause the operational action that depends on the disputed value until treasury or compliance resolves the source record.
Reserve reconciliation checks
Run these checks before each mint, burn, and reporting cycle:
| Check | What to compare | Why it matters |
|---|---|---|
| Collateral claim | Claim amount, expiry, trusted issuer, and collateral ratio metrics | DALP can block minting when the recorded claim is missing, expired, or insufficient. |
| Token supply | Current total supply, mint history, burn history, and holder balances | The token view shows the issued supply that treasury and client records reconcile against. |
| External reserve evidence | Custodian statement, bank ledger, treasury approval, verifier attestation, and accounting entry | Reserve custody and legal availability remain institution responsibilities outside DALP. |
| Transaction status | Mint or burn request status, receipt, event history, and indexed read views | A final transaction and a temporarily stale read model should not trigger a duplicate mint or burn. |
Canonical checks for the operating loop
Use these checks when you review a stablecoin runbook or prepare a demo:
| Check | Expected alignment |
|---|---|
| Asset lifecycle | The asset follows create, configure, mint, transfer, burn, and reconcile steps rather than stopping at issuance. |
| Collateral and reserve state | Collateral-backed minting uses a trusted issuer and current collateral claim before new supply is minted. Reserve custody and legal availability remain external evidence. |
| Compliance controls | Holder and transfer eligibility comes from configured identity, jurisdiction, trusted issuer, or transfer rules. External AML, sanctions, and case management stay with the programme unless integrated. |
| Transaction finality | Operations track transaction request status and receipts before retrying writes. Indexed views can lag terminal request state. |
| Operating split | The platform records and enforces token lifecycle controls. Treasury, custody, payment rails, core banking, accounting, and client disclosures remain outside the token contract. |
Troubleshooting
| Issue | What to check |
|---|---|
| Mint button or API call is blocked | Confirm supply-management permission, pause state, holder eligibility, and collateral-backed minting requirements. |
| Collateral metrics do not support the desired mint | Update the collateral claim through a trusted issuer and confirm the claim has not expired. |
| Holder cannot receive a transfer | Check identity, trusted issuer claims, jurisdiction rules, and any transfer approval or allow-list control on the asset. |
| Burned supply does not appear in a read view yet | Check transaction request status first, then allow for indexed-state lag before retrying or escalating. |
| Platform supply differs from reserve records | Compare mint and burn history, collateral claims, reserve movements, custody evidence, accounting entries, and client instructions before the next supply change. |
Related pages
- Stablecoins use case explains the business model and scope split.
- Deploy and mint a stablecoin covers the API creation path.
- Collateral requirement explains how collateral verification controls minting.
- Mint assets in the console and Burn assets cover the console actions.
- Transaction tracking explains finality, receipt lookup, and safe retry behaviour.