Stablecoin architecture and operating responsibilities in DALP

Understand the DALP stablecoin issuance architecture, including mint, burn, reserve, compliance, governance, and operator-owned responsibilities.

DALP stablecoins are SMART Protocol assets with controlled mint, burn, transfer, custody, pause, collateral, identity, and compliance behaviour. The platform enforces the on-chain token controls. The issuing institution owns the reserve, treasury, legal, accounting, client, and operational controls around those token actions.

Use this page when reviewing a stablecoin programme architecture, preparing a control walkthrough, or separating what DALP enforces from what must be governed by the operator.

Direct answer

A DALP stablecoin programme has three layers:

On-chain asset layer: the stablecoin token contract, token identity, access manager, compliance engine, and configured compliance modules.
DALP platform layer: APIs, dApp workflows, indexing, transaction tracking, and operator screens that create, monitor, and service the asset.
Institution operating layer: reserve custody, treasury approval, bank ledger posting, client records, payment rails, audit evidence, and governance procedures.

DALP enforces token permissions, mint and burn authorization, compliance checks, collateral-claim checks, pause and custody controls, and transaction execution on an EVM network. DALP does not custody fiat reserves, operate payment rails, prove physical backing by itself, or replace the institution's treasury, legal, accounting, and governance approvals.

Architecture overview

Rendering diagram...

What DALP enforces on-chain

Control area	DALP mechanism	What this protects
Mint authorization	Stablecoin mint and batch mint calls require the supply-management role.	New supply cannot be issued by an ordinary holder or unauthorised integration account.
Burn authorization	Stablecoin burn and batch burn calls require the supply-management role.	Redemption burns stay tied to the approved operational path.
Governance configuration	Compliance, identity, claim-management, and module configuration require governance authority.	Policy-changing actions stay separated from routine mint and burn operations.
Reserve-backed minting	A collateral module can require a valid collateral claim on the token identity before minting.	New supply can be blocked when trusted collateral evidence is missing, expired, malformed, or insufficient.
Supply ceiling	A supply-cap module can reject a mint when post-mint supply would exceed the configured cap.	Issuance cannot exceed the configured programme limit.
Holder and transfer eligibility	Transfer compliance modules can check identity, country, approval, investor, and other configured rules.	Tokens can move only when the configured eligibility rules allow the transfer.
Emergency controls	Pause, freeze, forced transfer, and token recovery operations are role-gated.	Exceptional actions require dedicated privileged authority.

These controls run on the EVM asset controls. They do not decide whether the reserve evidence is legally sufficient, whether fiat settlement completed, or whether a bank ledger entry is correct.

What remains off-chain

Responsibility	Owner	DALP control
Fiat or reserve custody	Issuer, custodian, treasury, or appointed service provider	DALP can use a collateral claim as a mint-time control input. It does not custody fiat or physical reserves.
Reserve verification	Issuer, verifier, auditor, or bank control team	DALP can check trusted collateral claims and expose collateral stats. It does not produce a standalone cryptographic proof of off-chain reserves.
Treasury approval	Issuer or operator workflow	DALP enforces the submitted on-chain role and compliance checks. The approval policy before submission is external to the token contract.
Client account posting	Bank ledger or client system	DALP records token state and transaction status. Banking ledger posting and statementing remain external integrations.
Payment rail execution	Bank or payment provider	DALP can move the token leg. Fiat payment execution stays outside the token contract.
Legal and regulatory programme rules	Issuer and advisers	DALP can encode supported controls. It does not replace jurisdiction-specific legal, licensing, disclosure, or supervisory obligations.

Smallest runnable example

A minimal stablecoin control walkthrough uses this sequence:

Create a stablecoin asset with the required identity, access manager, and compliance configuration.
Configure a supply cap when the programme has a maximum outstanding supply.
Configure collateral enforcement when minting must depend on a reserve or backing claim.
Issue or refresh the collateral claim on the token identity through an approved verifier.
Submit a mint through an account with the supply-management role.
Confirm the mint transaction, token supply, holder balance, and collateral stats in DALP.
For redemption, complete the external redemption approval first, then burn the corresponding token amount through the supply-management path.

For the API runbook, use Deploy and mint a stablecoin. For the operator loop after issuance, use Operate stablecoins after issuance.

Isolating one stablecoin from other asset classes

DALP isolates stablecoin operations at the asset and configuration level. A stablecoin is issued as its own asset contract with its own token identity, access-managed permissions, compliance module bindings, balances, supply, transaction history, and collateral state.

Other asset classes, such as bonds, funds, equities, deposits, real estate, or precious metals, use their own issued assets and configurations. A stablecoin mint or burn changes that stablecoin's supply. It does not change the supply of another asset class. Shared platform infrastructure can index and display multiple asset types, but token actions execute against the specific asset contract and its configured controls.

For an AED stablecoin, the same responsibility split applies: isolate the AED programme by its own asset, identity, role assignments, compliance modules, collateral or reserve claims, operational approvals, treasury records, and reconciliation process. Do not rely on a generic platform role alone when the programme requires currency-specific approval, reserve, or reporting controls.

Production readiness checklist

Area	Required before go-live
Roles	Separate governance, supply-management, emergency, custody, and operating roles. Grant only the accounts needed for the stablecoin programme.
Reserve evidence	Define the reserve evidence source, verifier, claim topic, collateral amount format, expiry process, and renewal cadence.
Mint controls	Configure supply cap and collateral checks when the programme depends on capped or reserve-backed issuance. Test failed mint cases before launch.
Burn controls	Define the redemption approval sequence before burn submission. Reconcile burn transactions with client and treasury records.
Transfer rules	Configure identity, jurisdiction, investor, approval, or other eligibility modules needed for holder and venue transfers.
Monitoring	Track transaction status, total supply, balances, collateral stats, claim expiry, and failed compliance checks.
Reconciliation	Reconcile DALP token state against reserve, treasury, accounting, client, and custody records for each reporting period.
Evidence package	Keep a repeatable audit pack that joins reserve evidence, verifier attestation, mint and burn instructions, transaction results, and reconciliation output.

Evidence handoff for reviewers

A reserve-backed stablecoin review should join DALP-controlled evidence with operating evidence outside the token contract. The mint check proves that a configured on-chain rule accepted the collateral claim at execution time. It does not prove whether operator approvals or reconciliation records match the on-chain record.

Review question	DALP evidence to collect	Operator evidence to attach
Was minting allowed by configured controls?	Mint transaction result, token event history, supply cap configuration, and collateral stats.	Approved mint instruction and the programme rule that allowed issuance.
Was backing evidence current at mint time?	Token identity collateral claim, claim issuer, topic, amount, expiry, and collateral confidence state.	Reserve report, verifier attestation, or audit file behind the claim.
Was redemption handled through the approved process?	Burn transaction result, token event history, holder balance change, and related action status.	Approved redemption instruction and client redemption record.
Can the period be reconciled?	Holder register, token events, transaction hashes, webhook delivery evidence, and dashboard exports.	Reserve report, accounting workpapers, and reporting workpapers.

Use Reporting and audit access for the read APIs, dashboard exports, webhook delivery records, and reconciliation workflow that turn those DALP records into a review pack.

Stablecoin operating responsibilities