# Supply cap and collateral Source: https://docs.settlemint.com/docs/architecture/security/compliance/supply-cap-collateral How DALP combines circulating supply caps with collateral claims to control minting for reserve-backed assets. DALP can block reserve-backed issuance before new tokens enter circulation. A supply cap limits the maximum post-mint supply. A collateral requirement checks that the asset identity carries a valid collateral claim with enough value for the post-mint supply and configured ratio. Related pages: [Compliance overview](/docs/architecture/security/compliance), [Collateral user guide](/docs/user-guides/compliance/collateral), [Mint assets](/docs/user-guides/asset-servicing/mint-assets), [Maturity redemption](/docs/architecture/components/token-features/maturity-redemption), and [XVP settlement](/docs/architecture/components/capabilities/xvp-settlement). ## Where these modules apply [#where-these-modules-apply] | Concern | CappedComplianceModule | CollateralComplianceModule | | ---------------- | ------------------------------------------------------------ | -------------------------- | | Minting | Enforces circulating supply cap | Checks collateral ratio | | Transfers | - | - | | Burns | Frees up capacity because the cap reads live `totalSupply()` | - | | Forced transfers | - | - | ## Reserve-backed issuance model [#reserve-backed-issuance-model] For reserve-backed assets, DALP can enforce two mint-time controls: | Control | What DALP checks | What the operator owns | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | Supply cap | Post-mint circulating supply must stay at or below the configured cap. Burns can restore minting capacity. | Choose the cap. Change the cap through asset governance when the programme terms allow it. | | Collateral requirement | The asset identity must have a valid collateral claim from a trusted issuer. The claim amount must cover the post-mint supply at the configured ratio. | Maintain reserve evidence, select trusted issuers, renew claims before expiry, and decide what off-chain proof supports each claim. | DALP does not create reserve proof. The collateral claim is the on-chain control input. A mint fails when the claim expires, comes from an untrusted issuer, has malformed claim data, or does not cover the post-mint supply. ### Proof of reserve and independent verification [#proof-of-reserve-and-independent-verification] DALP does not provide cryptographic proof of reserve for physical gold or other off-chain backing. It does not generate a Merkle proof, zero-knowledge solvency proof, or oracle proof that token supply matches vault holdings. Banks, investors, and auditors verify backing outside DALP by comparing vault, custodian, treasury, or audit evidence with the verifier attestation and the collateral state exposed by DALP. The DALP mechanism is narrower. An appointed verifier publishes a reserve amount and expiry as an ERC-735 claim on the asset identity. DALP trusts that claim only when the issuer is allowed for the configured proof topic, the claim data is valid, the claim has not expired, and the amount covers the post-mint supply at the configured ratio. If any of those checks fail, the mint fails. For independent verification, use this order of evidence: | Evidence step | What the verifier checks | What DALP exposes | What the reviewer compares | | -------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Physical reserve evidence | Vault records, custodian statements, bar lists, treasury files, or audit reports | Outside the mint check | Reserve quantity, asset identity, valuation date, custodian, and reporting period | | Verifier attestation | Approved reserve evidence and programme backing policy | Signed collateral claim with issuer, topic, amount, and expiry on the asset identity | Whether the attestation amount and expiry match the approved reserve evidence | | Mint-time enforcement | - | Mint succeeds only when the trusted claim is present, valid, current, and sufficient | Whether issued supply stayed within the cap and collateral ratio at the time of minting | | Operational reconciliation | Treasury, custody, accounting, and reserve evidence records | Collateral stats, transaction results, required collateral, mintable supply, and confidence | Whether DALP state, issued supply, and off-chain reserve records reconcile for the period | The deployment boundary is the same for every reserve-backed programme. DALP enforces the configured on-chain collateral rule; the operator, custodian, verifier, auditor, or bank owns the source reserve file and the reconciliation process that proves the claim corresponds to physical holdings. The collateral stats response is review data, not standalone proof that the reserve exists. Use [Collateral requirement](/docs/user-guides/compliance/collateral) for the operational setup flow. Use this page as the architecture reference for the public reserve-proof boundary: `/docs/architecture/security/compliance/supply-cap-collateral`. These controls do not by themselves settle cash, move physical metal, redeem tokens, or operate a secondary market. Use [Maturity redemption](/docs/architecture/components/token-features/maturity-redemption) for bond-style redemption mechanics and [XVP settlement](/docs/architecture/components/capabilities/xvp-settlement) for linked settlement flows. ## Distribution and settlement controls [#distribution-and-settlement-controls] Reserve-backed offerings usually need more than a mint check. DALP separates the controls that protect issuance from the controls that govern who can receive tokens and how token-versus-payment legs settle. | Topic | DALP scope | How it works | | ---------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Primary issuance | Covered by DALP | The mint path can combine a supply cap with a collateral claim so new tokens cannot exceed configured supply or backing evidence. | | Investor and venue eligibility | Covered by DALP when configured | Transfer compliance modules check recipient identity, jurisdiction, block lists, investor limits, time locks, or approval records. These rules apply to secondary transfers because they run on token movement, not only on minting. | | Exchange or distributor onboarding | Standard integration | The operator onboards the exchange, distributor, or broker wallet through the same identity and claim model used for other participants. Corporate KYC or KYB evidence can be represented through trusted-issuer claims before that participant receives or redistributes tokens. | | Secondary-market rulebook | Not DALP by itself | DALP enforces the on-chain transfer checks that the operator configures. Venue admission rules, order matching, market surveillance, investor notices, and off-chain regulatory reporting remain responsibilities of the operator, exchange, distributor, or appointed service provider. | | XvP or DvP settlement | Covered by DALP for token legs | An XvP settlement defines one or more flows with a sender, receiver, token, and amount. Each local sender approves the settlement and provides ERC20 allowance. When every local approval is present, execution moves all local token flows in one transaction or none at all. If an external-chain or off-chain leg exists, the settlement can use a shared hashlock so the local token movement waits for the external leg's secret reveal. | For a secondary distribution, use this sequence: 1. Onboard the receiving participant or venue wallet. 2. Issue or refresh the required identity claims. 3. Configure transfer rules on the asset. 4. Mint only when supply and collateral checks pass. 5. Use ordinary transfers or XvP settlement for post-issuance movement. The supply and collateral modules do not decide whether a venue may list the token. They protect the amount issued. Transfer modules and settlement workflows control whether a specific post-issuance movement can complete. ## CappedComplianceModule [#cappedcompliancemodule] Enforces a maximum circulating supply cap for minting operations. ### Interface [#interface] | Capability | Who can call | Inputs | On-chain effect | Emits | Notes | | -------------------------- | ------------------------------ | ------------------------- | ------------------------------------------------------------------ | ----- | ---------------------------------------------------------------------------- | | `setModuleParameters` | Token admin through compliance | `maxSupply` (`uint256`) | Stores supply cap. `validateParameters` reverts if `maxSupply = 0` | - | Cap must be a positive raw token-unit value | | `canTransfer` on mint path | Compliance engine | Sender, recipient, amount | Checks `totalSupply() + mintAmount <= maxSupply` | - | Only enforced on mints. Reads live `totalSupply()` so burns free up capacity | ### Configuration [#configuration] | Parameter | Type | Description | | ----------- | --------- | --------------------------------------------- | | `maxSupply` | `uint256` | Maximum circulating supply in raw token units | ### Use cases [#use-cases] * Bond issuance caps, where total outstanding bonds must stay within the programme limit. * Fixed supply instruments, where the configured token supply represents a fixed pool or asset value. * Regulatory or policy caps that limit maximum issuance for a jurisdiction, investor class, or product programme. ### Key invariants [#key-invariants] * Burns free up capacity because the cap tracks live circulating supply through `totalSupply()`, not lifetime minted amount. * Calling `setModuleParameters` with `maxSupply = 0` reverts. The cap must be a positive value. * The module checks mints only. Transfers between existing holders are unaffected. * Forced transfers do not affect the cap because supply does not change. ### Operational signals [#operational-signals] No events are emitted by this module. Monitor failed mint transactions for `ComplianceCheckFailed` with the supply-cap reason when a mint exceeds the cap. ### Failure modes and edge cases [#failure-modes-and-edge-cases] * Concurrent mint transactions execute in chain order. A later transaction can fail if an earlier mint consumes the remaining cap. * Reducing `maxSupply` below current `totalSupply()` does not burn tokens. It prevents further minting until supply decreases through burns. *** ![Supply cap and collateral requirement configuration](/docs/screenshots/asset-designer/asset-designer-supply-limit.webp) ## CollateralComplianceModule [#collateralcompliancemodule] Enforces collateral requirements for minting through on-chain identity claims. ### Interface [#interface-1] | Capability | Who can call | Inputs | On-chain effect | Emits | Notes | | -------------------------- | ------------------------------ | -------------------------------------------- | --------------------------------------------------------------------------------- | ----- | --------------------------------------------------------------------------- | | `setModuleParameters` | Token admin through compliance | `proofTopic`, `ratioBps`, `trustedIssuers[]` | Stores collateral configuration. `ratioBps = 0` disables enforcement | - | `proofTopic` is an ERC-735 claim topic | | `canTransfer` on mint path | Compliance engine | Sender, recipient, amount | Checks that post-mint supply does not exceed claim amount at the configured ratio | - | Collateral amount is read from identity claims. Expired claims are rejected | ### Configuration [#configuration-1] | Parameter | Type | Description | | ---------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------- | | `proofTopic` | `uint256` | ERC-735 claim topic representing collateral proof. A zero topic is rejected. | | `ratioBps` | `uint16` | Ratio in basis points. `10000` means 100%, `20000` means 200%, and `0` disables enforcement. Values above `20000` are rejected. | | `trustedIssuers` | `address[]` | Additional trusted issuers for collateral claims. Zero addresses are rejected. | ### Claim selection and validation [#claim-selection-and-validation] The collateral module reads claims from the token's own OnchainID identity. A claim can satisfy the mint check only when all of these conditions hold: | Check | Requirement | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Topic | The claim topic matches the configured `proofTopic`. | | Issuer | The claim issuer is trusted through the issuer registry for that proof topic and identity, or through the module's additional trusted issuer list. | | Signature | The trusted issuer validates the claim signature for the token identity. | | Data shape | Claim data decodes as `(uint256 amount, uint256 expiry)`. | | Expiry | `expiry` is greater than the current block timestamp. | | Amount | The decoded amount covers the required collateral for the post-mint supply. | If more than one valid claim exists, DALP uses the valid claim with the highest collateral amount. Required collateral uses ceiling division: `(postSupply * ratioBps + 9999) / 10000`. The ceiling prevents small amounts from being under-enforced when integer division would otherwise round down. ### Use cases [#use-cases-1] * Stablecoin collateral backing, where minting must stay within the highest collateral amount from any currently valid backing claim. * Over-collateralized tokens, where `ratioBps` is above `10000`, such as `15000` for a 150% collateral requirement. * Deposit tokens or precious-metal tokens where an appointed verifier issues reserve evidence as a claim on the asset identity. ### Key invariants [#key-invariants-1] * Collateral claims carry an expiry timestamp. Claims at or past expiry are rejected. * Issuers must renew claims before expiry or minting halts for assets that still require collateral enforcement. * The module checks mints only. Transfers between existing holders are unaffected. * Setting `ratioBps = 0` disables collateral checking entirely. * If the token does not expose a supported SMART identity or has no token identity, the module finds no valid collateral claim and a mint that requires collateral fails. ### Collateral stats and reserve review [#collateral-stats-and-reserve-review] DALP also exposes collateral stats for operator review. The stats response includes total collateral, required collateral, mintable supply, collateralization percentage, configured collateral ratio, utilization percentage, and data confidence. Data confidence helps operators decide whether the displayed stats are complete enough for review. `high` means the displayed collateral data had no known malformed or incomplete values for that calculation. `degraded` means the available collateral data contained malformed or incomplete values, so operators should refresh the claim evidence before relying on the displayed numbers. The stats response supports review. The mint check is still enforced by the compliance module at transaction time, using the asset's configured proof topic and live claim validation. ### Operational signals [#operational-signals-1] No events are emitted by this module. Monitor failed mint transactions for `ComplianceCheckFailed` with the insufficient-collateral reason. Monitor claim expiry timestamps. Approaching expiry requires issuer renewal to avoid minting disruption. ### Failure modes and edge cases [#failure-modes-and-edge-cases-1] * Collateral claim expires without renewal. Minting halts until a trusted issuer issues a new valid claim. * Claim data cannot decode to amount and expiry. The module ignores that claim. * Multiple trusted issuers provide different collateral amounts. The module uses the highest valid amount. * `ratioBps = 0` disables enforcement, so the operator must not use that configuration for a reserve-backed programme that requires mint-time backing checks. ## See also [#see-also] * [Compliance overview](/docs/architecture/security/compliance) - module architecture and regulatory templates * [Identity verification](/docs/architecture/security/compliance/identity-verification) - ERC-735 claim system also used for collateral claims * [Legacy-equivalent presets](/docs/architecture/components/asset-contracts/instrument-profiles) - bond and stablecoin presets reference these modules * [Reconcile balances](/docs/developer-guides/operations/reconciliate-balances) - operator workflow for comparing platform and external records