DALP compliance module index for regulated token controls

Choose the DALP compliance module that matches each asset policy rule, including identity, geography, supply, approvals, collateral, and holding-period controls.

Compliance module index

DALP compliance modules are reusable smart-contract controls that each asset configures independently. 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 failing module blocks the operation.

Use this index after you know the policy rule and need the matching module reference. If your team is still designing the full operating model, start with tokenized asset compliance controls and return here for module-level details.

Choose the right control page

To decide which investors or wallets may receive tokens, see identity verification, identity lists, and address block list.
To decide which jurisdictions may receive tokens, see country restrictions.
To understand token-unit caps and holder limits, see supply and investor limits.
To cap gross fiat value raised through minting, see Capital Raise Limit.
To map the full policy-based transfer control path, see policy-based transfer controls.
To require prior review for a transfer, see transfer approval.
To tie minting to a cap or backing evidence, see supply cap and collateral.
To hold tokens for a minimum period, see 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. It 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.

Each control reads only the state it needs: OnchainID claims, country codes, address lists, supply counters, approval records, collateral amounts, or TimeLock batches.

Rendering diagram...

Several controls also record state after a successful mint or transfer. Investor-count controls update holder counts, issuance-volume controls update their windows, approval controls consume the approval record, and TimeLock records new acquisition batches.

Configuration model

The shared module catalog contains reusable contracts: country lists, identity checks, transfer approval, collateral, and TimeLock. The per-token asset policy stores the selected controls, their order, and the encoded parameters for that token.

Identity and issuer data tell claim-based controls which holder identities, trusted issuers, claim topics, and country codes apply to the asset. Operational state holds mutable values: investor counts, issuance windows, approval records, and TimeLock batches. Both data types are maintained independently of the module code, so you can update evidence without redeploying any module.

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. Understanding this split helps you design operational processes around each control.

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, banking ledger reconciliation, or off-chain reserve operations. DALP gives the asset selected EVM token controls that block or allow on-chain transactions.

A compliance module is not a signer approval, a custody decision, or a provider case outcome. Provider outcomes and custody policies take effect only after the token configuration turns them into a trusted issuer, identity claim, module parameter, token role, or signing route. If you need to separate those layers during architecture review, read the compliance and custody split before changing any module configuration.

Choose controls for an asset policy

Start from the asset policy, then pick the smallest set of controls that enforces it. Each selected module adds a hard execution gate, so avoid installing one 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, investor, or time-window cap?	Token supply limit, investor count, issuance volume limit, or capped module	Asset terms, token decimals, holder-count policy, and cap-change governance.
Must issuance stay below a gross fiat fundraising cap?	Capital raise limit	Asset terms, standard `price` feed topic, period length, rolling or fixed window choice, and governance for cap changes.
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

The table below maps each control family to the modules that enforce it.

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

The table below shows which operation each module family covers and whether it updates state after success.

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.

Compliance module index

On this page