# Asset policy

Source: https://docs.settlemint.com/docs/compliance-security/security/compliance/asset-policy
Reference page for DALP asset policy compliance configuration, module categories, configuration scope, and the pages to use when reviewing per-asset rules.



An asset policy is the configured set of compliance modules and parameters that DALP evaluates for one regulated EVM asset. The policy decides which ordinary mint, transfer, and burn operations can execute.

Review the full model in [How DALP applies per-asset compliance rules](/docs/architects/architecture/concepts/asset-policy). Use this reference to choose the right module page for a concrete asset review.

## What belongs in an asset policy [#what-belongs-in-an-asset-policy]

DALP stores policy choices per asset. A deployed compliance module can be reused across assets, but each asset keeps its own selected module list and parameter values. Changing one asset's policy does not silently rewrite another asset's policy.

| Policy area              | What it controls                                                                        | Start here                                                                                                                                                                                                                                                                                     |
| ------------------------ | --------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Geographic eligibility   | Countries that may or may not hold the asset.                                           | [Country restrictions](/docs/compliance-security/security/compliance/country)                                                                                                                                                                                                                  |
| Identity eligibility     | Claim expressions, identity allow lists, identity block lists, and address block lists. | [Identity verification](/docs/compliance-security/security/compliance/identity-verification), [identity lists](/docs/compliance-security/security/compliance/identity-lists), and [address block list](/docs/compliance-security/security/compliance/address-block-list)                       |
| Supply and holder limits | Caps on supply, issuance volume, investor count, or capital raise amount.               | [Supply and investor limits](/docs/compliance-security/security/compliance/supply-investor-limits), [capital raise limit](/docs/compliance-security/security/compliance/capital-raise-limit), and [issuance volume limit](/docs/compliance-security/security/compliance/issuance-volume-limit) |
| Transfer workflow        | Prior approval requirements and holding-period checks before transfer execution.        | [Transfer approval](/docs/compliance-security/security/compliance/transfer-approval) and [TimeLock](/docs/compliance-security/security/compliance/timelock)                                                                                                                                    |
| Collateral and backing   | Collateral checks and supply-cap controls for backed assets.                            | [Supply cap and collateral](/docs/compliance-security/security/compliance/supply-cap-collateral)                                                                                                                                                                                               |

## Runtime rule [#runtime-rule]

For ordinary regulated operations, DALP reads the asset's active policy and evaluates the selected modules before the token state change. If a required module rejects the operation, the operation reverts and the token balance does not change. Stateful modules update their counters, approval usage, or holding-period records only after a successful operation.

Lost-wallet recovery is different from an ordinary transfer. Recovery checks the identity registry's lost-wallet relationship and replacement wallet, then applies a forced balance update through recovery-specific controls. Review recovery controls separately from ordinary transfer policy.

## Configuration review checklist [#configuration-review-checklist]

Before moving an asset policy into production, verify these facts for the specific asset:

* The token uses the intended identity registry and trusted issuer records.
* Every active module is required for the asset's jurisdiction, instrument, and operating model.
* Module parameters match the schema for that module, including country-code format, identity or wallet address type, claim-expression shape, and numeric limit units.
* Stateful modules are tested across the lifecycle they track, including mint, transfer, burn, and any recovery-side state migration that applies to the asset.
* Governance roles for installing, disabling, enabling, uninstalling, or reconfiguring modules are restricted to the intended operators.
* Operational approvals outside the smart contract transaction exist for policy changes that require maker-checker review.

## Related pages [#related-pages]

* [Asset policy concept](/docs/architects/architecture/concepts/asset-policy)
* [Compliance modules](/docs/compliance-security/security/compliance)
* [Claims and identity](/docs/architects/architecture/concepts/claims-and-identity)
* [Compliance transfer flow](/docs/architects/architecture/flows/compliance-transfer)
* [SMART Protocol integration](/docs/architects/architecture/components/asset-contracts/smart-protocol-integration)