Overview
How DALP compliance modules enforce per-asset rules for identity, geography, supply, approvals, collateral, and holding periods before regulated EVM token operations execute.
Overview
DALP compliance modules are reusable smart-contract controls that each asset configures for itself. Before a regulated EVM token mints or transfers, the token asks its compliance engine to run the selected modules with that token's parameters. One failed module blocks the operation.
Use this page to choose the right architecture page before you configure a module, review an asset policy, or explain why a mint or transfer was blocked.
How to read this section
- To decide which investors or wallets may receive tokens, start with identity verification, identity lists, and address block list.
- To decide which jurisdictions may receive tokens, start with country restrictions.
- To understand issuance, fundraising, or holder limits, start with supply and investor limits, capital raise limit, and issuance volume limit.
- To map the full policy-based transfer control path, start with policy-based transfer controls.
- To require prior review for a transfer, start with transfer approval.
- To tie minting to a cap or backing evidence, start with supply cap and collateral.
- To hold tokens for a minimum period, start with TimeLock.
- To place these controls in the full asset policy, read asset policy concept and the asset policy compliance view.
- To trace holder evidence into the gate, read claims and identity and identity and compliance.
Runtime model
The compliance engine sits in front of asset activity. The engine loads the controls selected for the token and passes token-specific parameters to each one. Evaluation stops as soon as one control rejects the request.
A control reads only the state that control needs: OnchainID claims, country codes, address lists, supply counters, approvals, collateral claims, or TimeLock batches.
Several controls also record state after a successful mint or transfer. Investor-count modules update holder counts. Issuance-volume modules update issuance windows. Transfer-approval modules consume approvals. TimeLock modules record acquisition batches.
Configuration model
The shared module catalog contains reusable contracts, such as country lists, identity checks, transfer approval, collateral, and TimeLock.
The per-token asset policy stores the selected controls, their order, and their encoded parameters for one token.
Identity and issuer records tell claim-based modules which holder identities, trusted issuers, claim topics, and country codes count for the asset.
Operational records hold mutable state, such as investor counts, issuance windows, approvals, and TimeLock batches.
A deployed module can serve multiple tokens, but each token keeps its own policy. DALP validates module parameters before accepting the configuration, so reusable logic still produces token-specific enforcement.
Ownership boundary
DALP enforces the selected on-chain checks for each asset. Your organisation owns the policy choices and the off-chain evidence those checks depend on.
| Control area | What DALP enforces | What your organisation owns |
|---|---|---|
| Module selection | The token evaluates the modules and parameters installed for that token before the covered operation executes. | Choose the modules, parameter values, and change process that match the asset terms and regulatory policy. |
| Identity evidence | Claim-based modules read OnchainID claims, trusted issuers, and allowed topics. | Operate or integrate KYC, KYB, sanctions, accreditation, and other evidence sources. Keep the underlying evidence off chain. |
| Transfer approval | The transfer-approval module checks for active identity-bound approval. The module consumes the approval after a successful transfer. | Decide who may approve transfers, when approvals expire, and how approval fits the operating workflow. |
| Issuance and supply controls | Supply, issuance-volume, investor-count, capital-raise, capped, and collateral modules block mints or transfers that exceed configured limits. | Maintain asset terms, verifier relationships, reserve or collateral evidence, and off-chain reconciliation records. |
| Holding period controls | TimeLock records acquisition batches and blocks transfers of locked balances. | Decide the policy basis for the hold period and any exemption claims. |
DALP does not replace legal advice, regulatory permissioning, custody policy, banking ledger reconciliation, or off-chain reserve operations. DALP gives the asset selected EVM token controls that can block or allow on-chain transactions.
Choose controls for an asset policy
Start from the asset policy, then pick the smallest module set that enforces that policy. Each selected module adds a hard execution gate, so avoid installing a module unless the asset has a real rule for that gate.
| Policy question | Start with | Evidence to prepare before production |
|---|---|---|
| Must the holder have KYC, AML, accreditation, or issuer-status claims? | Identity verification | Claim topics, trusted issuers, issuer keys, and off-chain evidence retention. |
| Must only specific identities or wallets participate? | Identity lists or address block list | The identity or wallet list owner, update process, and emergency removal path. |
| Must the asset restrict jurisdictions? | Country allow list or country block list | Numeric ISO country codes on identity records and the source system that keeps them current. |
| Must issuance stay below a unit, value, investor, or fundraising cap? | Token supply limit, investor count, capital raise limit, issuance volume limit, or capped module | Asset terms, currency and decimal precision, price or base-value source, and cap-change governance. |
| Must a mint depend on backing or collateral evidence? | Collateral module with capped supply where needed | The verifier, claim topic, evidence location, and reserve or collateral operating process. |
| Must transfers wait for review or a holding period? | Transfer approval or TimeLock | Approval authority, expiry rules, hold-period basis, and exemption logic. |
For the API shape used to install or configure modules, see Compliance modules. For reusable policy templates, see Compliance templates.
Module index
| Control family | Modules | Use it for |
|---|---|---|
| Jurisdiction rules | CountryAllowList, CountryBlockList | Allowing or blocking recipients by country code on the identity record |
| Identity and wallet lists | IdentityAllowList, IdentityBlockList, AddressBlockList | Allowing or blocking named investor identities or EVM wallet addresses |
| Claim-based eligibility | SMARTIdentityVerification | Requiring recipient OnchainID claims from trusted issuers |
| Supply and investor limits | TokenSupplyLimit, InvestorCount | Limiting minted supply or investor counts over the configured scope |
| Fundraising value cap | CapitalRaiseLimit | Capping gross raised fiat value through minting in a fixed or rolling window |
| Issuance quota | IssuanceVolumeLimit | Capping token units issued during a fixed or rolling window |
| Transfer pre-approval | TransferApproval | Requiring identity-bound approval before a transfer can proceed |
| Backing and supply cap | CappedComplianceModule, CollateralComplianceModule | Blocking mints above supply cap or without a valid collateral claim |
| Minimum holding period | TimeLock | Preventing transfer until configured acquisition batches have matured |
Where modules apply
| Module family | Transfer | Mint | Burn | State update after success |
|---|---|---|---|---|
| Country restrictions | Checks recipient country | Checks recipient country | Not applicable | No |
| Identity verification | Checks recipient claims | Checks recipient claims | Not applicable | No |
| Identity lists | Checks recipient identity | Checks recipient identity | Not applicable | No |
| Address block list | Checks sender and recipient wallet | Checks recipient wallet | Not applicable | No |
| Supply limits | Checks cap where configured | Checks cap where configured | Not applicable | Yes, for rolling supply tracking |
| Capital raise limit | Passes through | Checks gross raised fiat cap | Passes through | Yes |
| Issuance volume limit | Passes through | Checks issuance quota | Releases capacity by burn attribution | Yes |
| Investor count | Tracks new holders | Tracks new holders | Not applicable | Yes |
| Transfer approval | Checks active approval | Not applicable | Not applicable | Yes, approval consumption |
| TimeLock | Checks unlocked balance | Not applicable | Not applicable | Yes, acquisition batches |
| Supply cap | Passes through | Checks post-mint supply | Not applicable | No |
| Collateral | Passes through | Checks collateral claim | Not applicable | No |
For the transfer-level sequence, see Compliance transfer flow. For the broader security model, see Security overview.
Private mempool routing for DALP transactions
How to route DALP transaction submission through a private or encrypted mempool service by replacing the public RPC endpoint, what the service protects against, and what remains an operator responsibility.
Asset policy
Reference page for DALP asset policy compliance configuration, module categories, configuration scope, and the pages to use when reviewing per-asset rules.