# Overview Source: https://docs.settlemint.com/docs/architecture/security/compliance How DALP compliance modules enforce per-asset rules for identity, geography, supply, approvals, collateral, and holding periods before regulated EVM token operations execute. ## Overview [#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 [#how-to-read-this-section] * To decide which investors or wallets may receive tokens, start with [identity verification](/docs/architecture/security/compliance/identity-verification), [identity lists](/docs/architecture/security/compliance/identity-lists), and [address block list](/docs/architecture/security/compliance/address-block-list). * To decide which jurisdictions may receive tokens, start with [country restrictions](/docs/architecture/security/compliance/country). * To understand issuance, fundraising, or holder limits, start with [supply and investor limits](/docs/architecture/security/compliance/supply-investor-limits), [capital raise limit](/docs/architecture/security/compliance/capital-raise-limit), and [issuance volume limit](/docs/architecture/security/compliance/issuance-volume-limit). * To require prior review for a transfer, start with [transfer approval](/docs/architecture/security/compliance/transfer-approval). * To tie minting to a cap or backing evidence, start with [supply cap and collateral](/docs/architecture/security/compliance/supply-cap-collateral). * To hold tokens for a minimum period, start with [TimeLock](/docs/architecture/security/compliance/timelock). * To place these controls in the full asset policy, read [asset policy concept](/docs/architecture/concepts/asset-policy) and the [asset policy compliance view](/docs/architecture/security/compliance/asset-policy). * To trace holder evidence into the gate, read [claims and identity](/docs/architecture/concepts/claims-and-identity) and [identity and compliance](/docs/architecture/security/identity-compliance). ## Runtime model [#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 [#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 [#ownership-boundary] DALP enforces the on-chain checks. Your organisation owns the policy choices and off-chain evidence that those checks depend on: DALP runs selected modules before regulated mints and transfers. Your organisation chooses modules and parameters that match the asset policy. DALP reads OnchainID claims and trusted issuers. Your organisation operates or integrates KYC/KYB, sanctions, accreditation, or other evidence providers. DALP stores and consumes transfer approvals according to the selected module. Your organisation decides who may approve transfers and how approval fits the operating process. DALP checks caps, issuance windows, and collateral claims at mint time. Your organisation maintains source evidence, trusted verifiers, asset terms, and off-chain reserve operations. DALP records acquisition batches and checks whether tokens are unlocked. Your organisation decides the policy basis for the hold period and any exemptions. 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. ## Module index [#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 [#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](/docs/architecture/flows/compliance-transfer). For the broader security model, see [Security overview](/docs/architecture/security).