Stablecoins
Bank-issued stablecoins through DALP support controlled on-chain issuance, transfers, redemption burns, holder and supply visibility, collateral-claim checks, compliance controls, operational history, and API integration around the token lifecycle.
Who should read this: Treasury teams, payment operations, and financial institutions evaluating bank-issued stablecoins as part of a controlled settlement and treasury operating model.
Business value: Issue and operate stablecoins with on-chain supply and holder visibility, controlled mint and burn workflows, collateral-claim checks, compliance controls, and API integration into the surrounding banking and treasury estate. DALP records token-side evidence for reconciliation; reserve custody, treasury approval, accounting, and independent assurance remain with the institution and its appointed providers.
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
DALP's 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
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 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.
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:
- 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.
- 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.
- 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.
- 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
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. Those capabilities can be handled by deployment-specific integrations around DALP's on-chain lifecycle.
Bridge or cross-chain settlement boundary
A stablecoin programme can reference activity outside the DALP EVM network only through an explicit integration boundary. 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 boundary 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 boundary, see Supported networks.
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 boundary |
|---|---|
| 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 boundary. 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
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 can expose DALP data through APIs or custom portals, but those channels depend on the bank's access model, tenancy requirements, and disclosure policy.
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. 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
Stablecoin programmes usually combine on-chain restrictions with provider and operations controls. DALP can enforce 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 can make 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 boundary
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
A bank can integrate 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:
- The bank's core, treasury, or payment system approves the external cash or reserve movement and creates a stable instruction reference.
- The integration validates the asset, wallet, amount, compliance state, customer or participant mapping, and operating approval before it calls DALP.
- 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.
- 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. - 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, 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, Operational integration patterns, and Transaction tracking.
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
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 can connect DALP to the fiat rails, custody providers, compliance vendors, accounting tools, client portals, and core-banking systems required by their operating model.
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.
For detailed compliance architecture, see Compliance & Security.
Precious metals
Precious metals tokenization through DALP helps model gold, silver, platinum, and palladium assets with metal metadata, weight-based pricing, custody context, and compliance controls.
Deposit certificates
Time deposits meet blockchain in this modernization of certificates of deposit. DALP automates the entire lifecycle—from issuance and vault-secured reserves through yield accrual to redemption—while maintaining FDIC insurance and regulatory compliance. Real-time observability replaces quarterly statements, giving both customers and treasury teams continuous visibility into deposit positions and reserve health.