# Stablecoin minting, redemption, and operations
Source: https://docs.settlemint.com/docs/business/executive-overview/use-cases/stablecoins
Bank-issued stablecoin programmes use DALP for controlled EVM issuance, role-gated minting, holder transfers, redemption burns, collateral-claim checks, compliance controls, operational history, and API integration around the token lifecycle.
DALP gives a bank-issued stablecoin programme a controlled EVM token lifecycle:
asset creation, role-gated minting, holder transfers, redemption burns,
collateral-claim checks, compliance controls, holder and supply visibility, and
transaction history. Reserve custody, treasury approval, accounting, payment
execution, and independent assurance stay with the issuing institution and its
appointed providers.
This page is for treasury teams, payment operations, compliance reviewers, and
financial institutions evaluating stablecoins as part of a controlled settlement
or treasury model.
Use DALP for the token side of the programme: creating the stablecoin, minting
and burning supply under role and compliance controls, moving balances between
eligible holders, and reconciling token activity through transaction status,
holder balances, total supply, collateral state, and activity history. Keep the
reserve account, fiat movement, accounting entries, customer statements, and
independent reserve assurance in the bank or provider systems that own those
controls.
## Stablecoin lifecycle at a glance [#stablecoin-lifecycle-at-a-glance]
| Lifecycle step | What DALP controls | What stays outside DALP |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Create the programme token | Stablecoin asset creation, token metadata, roles, compliance modules, and configured collateral requirements. | Legal programme approval, reserve-account setup, accounting model, payment-rail selection, and issuer policy. |
| Mint supply | Role-gated minting to eligible wallets, wallet verification, pause checks, positive amount checks, [mint replay and idempotency controls](/docs/compliance-security/security/replay-idempotency-mint-controls), transaction status, and indexed mint history. | Funding confirmation, treasury approval, reserve movement, customer-account posting, and reserve evidence approval. |
| Transfer balances | Holder-to-holder token movement on the configured EVM network under the asset's transfer controls. | External payment-network execution, non-EVM settlement legs, client statements, and payment-message reconciliation. |
| Burn on redemption | Role-gated burns, redemption-related transaction status, indexed burn events, supply reduction, and activity history. | Fiat or reserve release, treasury and custody instructions, bank ledger posting, and client redemption settlement. |
| Reconcile operations | Holder balances, total supply, collateral metrics, token documents, activity history, and API reads for the token lifecycle. | Independent reserve assurance, regulatory reporting, accounting close, and exception handling in bank or provider systems. |
Start with the [operator stablecoin lifecycle guide](/docs/operators/user-guides/asset-servicing/stablecoin-operations-lifecycle) for day-to-day mint, transfer, burn, collateral, and reconciliation work. Developers automating stablecoin operations should pair it with [Token lifecycle and API operation flows](/docs/developers/developer-guides/api-integration/token-lifecycle) for token-creation idempotency, queued transaction status, event reconciliation, and safe retry decisions. Use the [stablecoin operating responsibilities](/docs/compliance-security/security/stablecoin-architecture-trust-boundaries) explanation when reviewers need the split between DALP token controls and external reserve, payment, custody, and banking controls.
## Business challenge [#business-challenge]
Regional Bank wants to issue a USD-backed stablecoin for commercial clients to
use in B2B settlement, trade finance, and treasury workflows. The bank needs the
on-chain token lifecycle to reflect its operating controls: who can hold the
asset, when supply can be minted or burned, what collateral or reserve state is
recorded, and how operations are audited.
The payment rail around that lifecycle is not a single universal system. Fiat
movements, reserve custody, treasury and accounting systems, core-banking
posting, client portals, and payment networks vary by deployment. DALP provides
the on-chain stablecoin lifecycle and integration surfaces that those systems
can use.
### Traditional operating model [#traditional-operating-model]
## DALP's role in the stablecoin operating model [#dalps-role-in-the-stablecoin-operating-model]
DALP is the control and record layer for the on-chain stablecoin lifecycle. A
stablecoin can be created from a template, configured with its currency and
reserve model, minted to eligible holders, transferred under configured
compliance rules, and burned during redemption or supply-reduction operations.
The platform records the lifecycle events and exposes operational views for
holder balances, total supply, collateral and reserve state, compliance status,
documents, feeds, and activity history. This gives operations, treasury, and
compliance teams a shared view of the token state that can be reconciled with
the institution's off-chain systems.
### Issuance and reserve state [#issuance-and-reserve-state]
Regional Bank creates a stablecoin token pegged 1:1 to USD. The bank or its
appointed providers operate the off-chain reserve accounts and custody model.
DALP records the on-chain asset, its reserve and collateral state, and the
configured controls that must be satisfied before new supply is issued.
When a client funds the reserve through the bank's chosen fiat process, the
operations team can record the required state in DALP and mint the corresponding
stablecoin supply to the client's eligible wallet. The on-chain supply then
becomes visible in holder and asset views, while fiat balances remain governed
by the bank's treasury and accounting controls.
### Reserve and backing verification [#reserve-and-backing-verification]
Reserve backing has two parts in DALP. The institution, custodian, or treasury
system controls the off-chain reserve account. DALP records the token-side
collateral state and exposes the indexed metrics that operators use to compare
issued supply with the programme's configured backing requirement.
When collateral enforcement is configured for the asset, the collateral state is
recorded as a collateral claim on the token identity. The claim carries an amount
and an expiry timestamp. Trusted issuers for the collateral topic, usually
compliance or treasury officers in the operating model, update that reserve
value after the external reserve evidence has been approved. DALP then derives
collateral metrics from indexed token and claim data: total collateral, required
collateral, available collateral, mintable supply, collateralisation percentage,
utilisation percentage, and a parity confidence flag. If indexed collateral data
is incomplete, the API marks the parity confidence as `degraded` instead of
presenting the value as a clean match.
| Review question | DALP evidence | External evidence |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| How much supply has been issued? | Token total supply, holder balances, mint and burn history | Treasury, core-banking, and accounting records |
| What collateral state backs the token record? | Collateral amount, expiry timestamp, required collateral, available collateral, and utilisation metrics | Reserve account statements, custodian attestations, audit files, and treasury approvals |
| Can additional supply be minted? | Mint permissions, token pause state, configured collateral ratio, and mintable supply calculation | Funding confirmation, reserve movement approval, and programme operating policy |
| Is the displayed ratio reliable? | Collateral parity confidence reported by the stats endpoint | Reconciliation between DALP, custody, treasury, and accounting systems |
These metrics support reserve review and reconciliation. They do not replace the
external proof that the reserve assets exist, are legally available, or satisfy
the institution's regulatory treatment.
Attach reserve evidence files to the token record when the programme needs a
shared diligence packet. A practical packet usually includes the approved reserve
audit, the latest attestation report, reserve-composition files, the collateral
claim value and expiry that operations entered in DALP, the collateral stats used
for the mint decision, and the reconciliation record tying issued supply back to
treasury and accounting systems. Reserve proof and attestations remain
institution- or provider-owned evidence unless the deployment adds a separate
integration that verifies them. Use these files to keep approved evidence close
to the token lifecycle, not to claim that DALP independently verifies the reserve
account. For the upload flow, document types, replacement metadata, visibility
settings, and retention boundary, see
[Token document uploads](/docs/developers/developer-guides/api-integration/token-documents).
For a diligence walkthrough, configure the demo tenant with one stablecoin asset
that has collateral enforcement enabled. The tenant should show the collateral
topic, the compliance or treasury identity that is trusted to issue collateral
claims, a visible collateral claim on the token identity, and a supply amount
large enough to demonstrate both a passing mint and a rejected over-mint. The
live sequence should show four things in order:
1. **Reserve policy setup**: the stablecoin is created with the collateral topic
and a 10,000 bps backing requirement. A zero ratio disables collateral
enforcement, so a backed stablecoin demonstration should use a non-zero ratio.
2. **Trusted issuer configuration**: the treasury, compliance, or collateral
verifier identity is added as a trusted issuer for the collateral topic before
it records reserve-backed claims on the token identity.
3. **Reserve value and limit update**: the trusted issuer records or updates the
collateral amount and expiry after the off-chain reserve evidence is approved.
Operators can then show how the updated collateral amount changes required
collateral, available collateral, mintable supply, utilisation, and parity
confidence in the stats view.
4. **Enforcement check**: before minting more supply, DALP calculates required
collateral from the post-mint supply and configured ratio. If the valid
collateral claim is lower than the required amount, the mint fails with an
insufficient-collateral compliance error. If the claim is high enough and the
other token controls pass, the mint can proceed.
The screen evidence for that call is the stablecoin detail view, the
Verification Topics & Issuers page for the collateral trusted issuer, the token
identity's collateral claim, and the operational history for the trusted issuer
configuration, collateral update, and mint attempt. The API evidence is the
collateral-ratio stats endpoint:
`/api/v2/tokens/{tokenAddress}/stats/collateral-ratio`.
### Transfers between eligible holders [#transfers-between-eligible-holders]
Clients can transfer stablecoin balances between eligible wallets. Transfers
move existing supply from one holder to another without changing total supply.
Eligibility depends on the configured compliance controls for the asset, such as
identity, jurisdiction, allow-list, or other provider-backed checks.
DALP records and indexes the token movement on the configured EVM network. It
does not, by itself, prove execution on external payment networks, banking rails,
or another chain. DALP does not natively validate Circle CPN or CCTP messages,
ISO 20022 payment messages, ACH or wire execution, core-banking posting, payment
message translation, or universal network fee treatment. Handle those
capabilities in deployment-specific integrations around DALP's on-chain
lifecycle.
### Bridge or cross-chain settlement responsibilities [#bridge-or-cross-chain-settlement-responsibilities]
A stablecoin programme references activity outside the DALP EVM network only
through an explicit integration model. Treat a bridge, external settlement
network, payment rail, or non-EVM chain as a separate control plane with its own
approval, replay protection, finality rule, monitoring, and reconciliation
evidence.
For a bridge or cross-chain pattern, keep DALP as the source for the configured
EVM token action and require the surrounding integration to prove the external
leg. A safe operating model binds one approved external instruction to one DALP
mutation, submits retryable DALP calls with a stable `Idempotency-Key`, waits for
the DALP transaction status and the environment's finality rule, then reconciles
the external reference against the indexed token event.
| Question to settle before production | DALP evidence | External control evidence |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------- |
| Which side controls supply? | Token address, holder address, amount, transaction ID, status URL, hash, and indexed mint, transfer, or burn event | Bridge contract policy, external-network message, settlement instruction, or payment reference |
| How is replay prevented? | One `Idempotency-Key` per approved DALP mutation and transaction-status lookup before retries | Gateway anti-replay checks, unique external instruction references, and duplicate-message handling |
| When can the external leg be treated as final? | Configured EVM finality rule and indexed DALP event | External-chain finality, payment-rail confirmation, bridge proof, or bank-side posting rule |
| How is a mismatch handled? | DALP token state, activity history, and API reads | Exception queue, manual approval, reserve reconciliation, and client or treasury adjustment process |
Do not describe a cross-chain stablecoin as automatically safe because the DALP
side is controlled. The bridge or external route decides whether supply can be
duplicated, delayed, replayed, or released before the matching token event is
final. For the network-level model, see [Supported networks](/docs/architects/architecture/integrations/supported-networks).
### Redemption burns and reserve release [#redemption-burns-and-reserve-release]
When a holder redeems stablecoins for fiat, DALP records the on-chain burn of the
corresponding stablecoin amount. The burn reduces both the holder balance and
total supply, leaving the token record aligned with the current issued amount.
The fiat or reserve movement stays with the institution's treasury, banking,
custody, or payment providers.
DALP does not provide a universal commit-reveal, escrow, or bonded-settlement
agent for external fiat reserve release. A bank integration should bind one
approved redemption instruction to one DALP burn request, submit the burn with an
idempotency key, then release reserves only after the programme's transaction
status, indexing, finality, and reconciliation checks pass.
| Risk to prevent | DALP control or integration responsibility |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| A token burn is submitted without authority | Burn routes require the configured token role, wallet verification, matching address and amount lists, and an unpaused token before DALP submits the on-chain transaction. |
| A client retry creates a second burn | Use one `Idempotency-Key` for one approved redemption instruction and check transaction status before submitting a replacement request. |
| Reserve release happens before the burn is accepted | Keep the bank, treasury, custody, or payment release behind the integration gateway until DALP returns the transaction status and transaction hash, then apply the required finality rule. |
| Reserve release happens without a matching DALP burn record | Reconcile the bank instruction reference against DALP's `transactionId`, `statusUrl`, transaction hash, token address, holder address, amount, and indexed burn event. |
The minimum confirmation depth is a deployment rule, not a fixed value for every
stablecoin. Networks that support the EVM `finalized` block tag can use that
finalized point. Private or consortium EVM networks that do not expose the tag
must configure `supportsFinalizedTag: false` with an explicit
`finalityConfirmations` depth before operators treat the burn as final for
reserve release.
### Visibility and operational history [#visibility-and-operational-history]
DALP exposes the operational history around stablecoin activity: creation,
minting, transfers, burns, holder balances, total supply, compliance state,
documents, feeds, and collateral or reserve state. This supports internal
oversight, reconciliation, and audit preparation.
External regulator or client-facing portals are deployment choices. A programme
exposes DALP data through APIs or custom portals only when those channels match
the bank's access model, tenancy requirements, and disclosure policy.
## Stablecoin operations after issuance [#stablecoin-operations-after-issuance]
A live stablecoin programme is an operating loop, not a one-time mint. For the
operator guide, see [Operate stablecoins after issuance](/docs/operators/user-guides/asset-servicing/stablecoin-operations-lifecycle).
The guide covers holder eligibility, reserve and collateral updates, controlled
minting, transfers, redemption burns, transaction tracking, and reconciliation
against treasury, custody, accounting, and client records.
## Compliance controls [#compliance-controls]
Stablecoin programmes combine on-chain restrictions with provider and
operations controls. DALP enforces configured controls such as holder
eligibility, jurisdiction rules, and transfer restrictions. AML screening,
sanctions checks, transaction monitoring, case management, and alert handling
depend on the compliance providers and workflows connected to the deployment.
This distinction matters. DALP makes a transfer subject to configured
compliance state, but it is not a universal AML or sanctions monitoring system
unless those provider integrations and rules are part of the programme design.
## Integration responsibilities [#integration-responsibilities]
DALP integrates with external systems around the on-chain lifecycle rather than
replacing the whole payment and banking estate.
| Area | DALP role | Deployment-specific systems |
| ------------------------ | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Stablecoin lifecycle** | Create assets, mint supply, transfer balances, burn supply, and expose holder and supply state | Asset programme policy and operating approvals |
| **Reserve operations** | Record collateral and reserve state associated with issuance and redemption | Reserve custody, bank accounts, treasury workflows, and accounting systems |
| **Compliance** | Enforce configured holder, jurisdiction, and transfer controls | KYC/KYB providers, AML and sanctions screening, transaction monitoring, and case management |
| **Payment rails** | Provide the on-chain token movement and lifecycle data | ACH, wire, card, RTP, ISO 20022 messaging, Circle CPN/CCTP, correspondent banking, or other rail integrations |
| **Client experience** | Expose APIs and operational data for stablecoin activity | Client portals, banking channels, statementing, and core-banking posting |
### Core banking and treasury integration pattern [#core-banking-and-treasury-integration-pattern]
A bank integrates DALP with core banking and treasury systems by treating DALP
as the controlled token lifecycle system and the bank ledger as the source for
fiat, reserve, and customer-account postings. The integration should move only
approved instructions into DALP, then reconcile the on-chain result back to the
bank systems.
A typical flow is:
1. The bank's core, treasury, or payment system approves the external cash or
reserve movement and creates a stable instruction reference.
2. The integration validates the asset, wallet, amount, compliance state,
customer or participant mapping, and operating approval before it calls DALP.
3. DALP submits the token operation through its transaction queue. Mint and burn
routes require the configured token role, wallet verification, positive
amounts, and the token to be unpaused for that operation.
4. The integration records DALP's `transactionId`, `statusUrl`, transaction
hash, token address, holder address, amount, and the original bank instruction
reference in the bank-side reconciliation record.
5. Treasury, accounting, or core-banking systems post their own ledger entries
only after the programme's finality and reconciliation rules are satisfied.
DALP does not replace maker-checker controls, payment-network execution, account
posting, GL accounting, reserve custody, or customer statementing. Those controls
stay in the surrounding banking systems. DALP provides the token action, indexed
state, activity history, transaction status, and API reads needed to reconcile
that external process.
Secure the integration in two layers. DALP does not ship a universal core-banking
adapter or prescribe one bank-side authentication protocol for every deployment.
The bank owns the gateway that accepts core, treasury, or payment instructions;
DALP owns the token lifecycle API surface those gateways call after approval.
| Layer | Security controls | Where it is implemented |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Bank integration gateway** | Caller authentication (for example mTLS, OAuth 2.0 client credentials, or institutional SSO per programme policy), instruction-reference binding, payload schema validation, size limits, and anti-replay checks | Bank or middleware in front of DALP |
| **DALP API** | `X-Api-Key` authentication, organisation-scoped read or read-write scope, route permissions, optional participant and wallet headers on supported routes, `Idempotency-Key` on mutations, and transaction-queue role, wallet, amount, and pause checks | DALP platform ([Getting started](/docs/developers/developer-guides/api-integration/getting-started), [Operational integration patterns](/docs/developers/developer-guides/api-integration/operational-integration-patterns)) |
Non-repudiation of the approved bank instruction stays in bank systems through
maker-checker, core posting, and audit logs. DALP returns `transactionId`,
`statusUrl`, transaction hashes, and indexed token events as reconciliation
evidence. Validate every mutation payload against the approved instruction
before calling DALP, and reject tampered or replayed requests at the gateway.
Keep CIF, onboarding, and account identifiers in the bank-side system or in the
approved integration mapping, then map them to DALP participants, identities,
wallets, and token holders only when the operation is submitted or reconciled.
Use idempotency keys for retryable mutation calls and keep the bank instruction
reference outside DALP as the reconciliation key. If a request times out or a
network call is retried, check the DALP transaction status and token events
before submitting another token operation. A successful on-chain mint or burn
should be matched to one approved bank instruction, not recreated because the
HTTP client lost the first response.
For implementation detail, pair this use-case model with
[Token lifecycle and API operation flows](/docs/developers/developer-guides/api-integration/token-lifecycle),
[Operational integration patterns](/docs/developers/developer-guides/api-integration/operational-integration-patterns),
and [Transaction tracking](/docs/developers/developer-guides/operations/transaction-tracking).
## Stablecoin lifecycle in DALP [#stablecoin-lifecycle-in-dalp]
The diagram shows DALP's stablecoin scope: the on-chain asset lifecycle,
operational state, and integration points that surround it. It does not imply
that DALP executes every fiat movement, payment message, custody action, or
banking ledger entry.
## Outcomes [#outcomes]
**On-chain settlement visibility**: Stablecoin transfers settle on-chain and are
reflected in holder balances, total supply, and activity history.
**Controlled issuance and redemption**: Minting and burning can be tied to the
programme's reserve, collateral, approval, and compliance controls.
**Operational reconciliation**: Treasury and operations teams can compare
off-chain reserve and accounting records with DALP's token lifecycle and supply
data.
**Integration flexibility**: Banks connect DALP to fiat rails, custody providers,
compliance vendors, accounting tools, client portals, and core-banking systems
required by their operating model.
## Considerations [#considerations]
Bank-issued stablecoins require jurisdiction-specific legal, compliance,
treasury, accounting, and operational review. DALP provides the stablecoin
lifecycle and control surface, while the broader payment, custody, reserve,
reporting, and client-channel architecture depends on the institution's
programme design.
## What to read next [#what-to-read-next]
* [Operate stablecoins after issuance](/docs/operators/user-guides/asset-servicing/stablecoin-operations-lifecycle)
for the operator loop.
* [Stablecoin operating responsibilities](/docs/compliance-security/security/stablecoin-architecture-trust-boundaries)
for the split between DALP token controls and external reserve, payment, and
custody controls.
* [Token lifecycle and API operation flows](/docs/developers/developer-guides/api-integration/token-lifecycle)
for token-creation idempotency, queued transaction status, event
reconciliation, and safe retry decisions for automated operations.
* [Compliance & Security](/docs/business/executive-overview/compliance-security) for the
wider control model.