# Asset policy

Source: https://docs.settlemint.com/docs/architects/architecture/concepts/asset-policy
Understand how DALP combines identity records, compliance modules, lifecycle hooks, and governance controls to decide whether regulated token operations can execute.



An asset policy is the per-token rule set DALP checks before a regulated mint, transfer, or burn changes balances. Use it to answer one question: can this asset perform this operation for these wallets and this amount right now?

The policy combines the token's identity registry, token compliance engine, active token-scoped compliance modules, system-level compliance modules, and module parameters. If any required check rejects the operation, DALP reverts before accepting the balance change.

Recovery uses a different path. DALP checks the identity registry's lost-wallet relationship before moving a lost wallet's full balance to the replacement wallet. You should review recovery permissions separately from transfer rules because recovery does not prove that every ordinary transfer module approved the balance move.

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

An asset policy is asset-scoped. Two assets can use the same deployed compliance module contract while carrying different parameters, such as different allowed countries, holding limits, approval windows, or claim-expression requirements.

| Policy part        | Scope                    | What it controls                                                                                                                  |
| ------------------ | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| Identity registry  | Per asset                | Which wallet maps to which OnchainID for this token.                                                                              |
| Token compliance   | Per asset reference      | The token-bound compliance engine that evaluates token-scoped modules and delegates to system-level modules.                      |
| Compliance modules | Per asset list           | Rule contracts active for this token, such as country restrictions, identity verification, investor limits, or transfer approval. |
| Module parameters  | Per asset and per module | ABI-encoded settings the module reads when evaluating this token.                                                                 |
| Lifecycle hooks    | Per operation            | Post-operation calls that let stateful modules update counters, approval usage, holding periods, or issuance trackers.            |
| Governance roles   | Per asset and system     | Which operators can add, remove, disable, enable, or reconfigure modules.                                                         |

The module implementation and the asset configuration are separate. A module contract defines reusable logic. The asset policy decides whether that module is active for a given token and which parameters it receives.

## Smallest example [#smallest-example]

A simple asset policy for a Belgian-only bond can be described as three checks:

1. The recipient wallet must map to an identity in the asset's identity registry.
2. The identity verification module must confirm the recipient has the required claim expression.
3. The country allow-list module must confirm the recipient's registered country is Belgium.

If Alice transfers the bond to Bob, DALP evaluates the policy before moving tokens:

```text
transfer(Alice, Bob, 100)
  -> check Bob's token identity record
  -> run identity-verification module with this asset's claim parameters
  -> run country-allow-list module with this asset's country parameters
  -> run any system-level compliance modules
  -> move the balance only if all checks pass
  -> run lifecycle hooks after the balance change succeeds
```

This is the smallest useful mental model for integrators: configure the module list and parameters for the asset, then test the exact paths the asset will allow.

## How DALP evaluates policy [#how-dalp-evaluates-policy]

For an ordinary regulated operation, DALP follows this order:

1. Resolve the token's current compliance module list and parameters.
2. Verify the relevant wallet identity through the token's identity registry.
3. Call each active token-scoped module for the requested token, sender, recipient, and amount.
4. Evaluate system-level modules that apply across bound tokens.
5. Revert if any required module rejects the operation.
6. Execute the token state change only after the checks pass.
7. Run lifecycle hooks so stateful modules can update counters, approval usage, holding periods, or issuance trackers.

The same policy model applies to ordinary issuance and destruction paths. Modules that only care about minting can inspect `from == address(0)`. Modules that maintain state can use creation, transfer, and destruction hooks to update their accounting after the token operation succeeds.

Recovery is different. A custodian recovery checks the lost-wallet relationship in the identity registry, then executes the balance move as a forced update. During that forced update, DALP verifies the replacement wallet's identity, but it does not run the ordinary compliance-module `canTransfer` path. Treat recovery permissions, lost-wallet records, and operator approval as separate controls from ordinary transfer rules.

<Mermaid
  chart="flowchart TD
  Operation{Token operation}

  Operation -- Ordinary mint, transfer, or burn --> Policy[Read asset policy]
  Policy --> Identity[Verify token identity registry]
  Identity --> Modules[Evaluate token-scoped modules]
  Modules --> Registry[Evaluate system-level modules]
  Registry --> Decision{All checks pass?}
  Decision -- No --> Revert[Revert operation]
  Decision -- Yes --> State[Apply token state change]
  State --> Hooks[Run lifecycle hooks]

  Operation -- Custodian recovery --> Lost[Check lost-wallet relationship]
  Lost --> Replacement[Verify replacement wallet identity]
  Replacement --> Forced[Apply forced balance update]
  Forced --> RecoveryHooks[Run recovery lifecycle hooks]"
/>

## How policy is configured [#how-policy-is-configured]

Asset policy can be set at creation time and changed later by governed roles.

* At asset creation, initial module and parameter pairs are passed into the token setup. DALP validates the modules and parameters before storing them on the token.
* After creation, governed operators can install, disable, enable, uninstall, or reconfigure token-scoped modules.
* Parameter changes are validated by the compliance engine before they become active.
* The token exposes its active module list and parameters so the compliance engine can evaluate the current policy at execution time.

This keeps reusable compliance logic separate from live asset configuration. Updating a template or module implementation does not silently rewrite every asset's stored policy parameters. Treat live policy changes as governed operational changes that require review and verification for the specific asset.

## Where custodian controls fit [#where-custodian-controls-fit]

Custodian controls protect balances through a separate role path from ordinary asset policy. The Custodian role can freeze a full address, freeze part of a wallet balance, unfreeze balances, force-transfer tokens, and recover a lost wallet to a replacement wallet. These actions are administrative controls for exceptional cases, not a replacement for the compliance modules that decide whether ordinary holder activity can proceed.

This boundary matters when you design an operating model:

| Question                                                  | Use ordinary asset policy                                                                        | Use custodian controls                                                                          | Verify outside the token policy                                                                                                    |
| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Can this holder receive or transfer this asset?           | Yes. Configure identity, country, holding-limit, transfer-approval, or other compliance modules. | No. A custody action should not be the normal eligibility test for holder transfers.            | Check which wallet verification, signer selection, request approval, and provider custody rules must pass before signing.          |
| Should a wallet be stopped during review?                 | Only if the compliance rule itself should reject the next ordinary operation.                    | Yes. Freeze the address or a partial amount while the operational review runs.                  | Check who can request the freeze, who signs it, which provider approval path applies, and how the action is recorded.              |
| Should an operator move assets without holder initiation? | No. Ordinary policy evaluates holder-initiated mint, transfer, and burn paths.                   | Yes, when the asset's governance and operating procedures permit a forced transfer or recovery. | Check the custody procedure for quorum, destination controls, exception approval, signer custody, and post-action review evidence. |

Ordinary transfers still check freeze state before they move balances. Forced updates deliberately use the custodian path instead of the normal transfer path, so the approval, evidence, and post-action review for those actions belong in the operator's custody procedure.

Before publishing or approving an integration design, separate the controls by enforcement point:

| Enforcement point               | Verify                                                                                                                                                                   |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DALP asset policy               | Active modules, module parameters, identity registry records, issuance limits, holding limits, approval windows, and lifecycle hooks for mint, transfer, and burn paths. |
| DALP custodian role             | Which addresses can freeze, partially freeze, unfreeze, force-transfer, pause, unpause, or recover balances for the asset.                                               |
| Application or custody provider | Wallet verification, signer custody, signing quorum, destination allowlists, amount limits, request approval, and custody-provider exception procedures.                 |
| Operating evidence              | The approval record, actor identity, provider decision, transaction hash, and post-action review evidence for each exceptional custody action.                           |

DALP enforces the on-chain policy and custodian-role checks on the configured EVM token. Provider wallet, signing, approval, and custody policies sit outside the token compliance module. Treat them as required integration controls, not as implicit asset-policy behavior.

## Where recovery fits [#where-recovery-fits]

Lost-wallet recovery is related to asset policy because it changes balances, but it does not run as an ordinary transfer. The recovery path checks that the identity registry marks the source wallet as lost and maps it to the replacement wallet. The token then moves the full lost-wallet balance through a forced update and runs recovery hooks, including migration of full-freeze and partial-freeze state to the replacement wallet.

That distinction matters operationally:

* Transfer approval modules are evaluated for ordinary transfers, not as the operator approval record for a wallet recovery.
* Country, claim, and holding-limit modules should be tested against the mint, transfer, and burn paths they govern.
* Recovery procedures need their own controls around identity recovery, custodian permissions, replacement-wallet verification, and post-recovery review.

## Asset policy vs. token features [#asset-policy-vs-token-features]

Asset policy and token features are different extension points.

| Extension point | Purpose                                                                               | Example                                                                                               |
| --------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Asset policy    | Decide whether ordinary regulated operations are allowed and update compliance state. | Country allow lists, identity verification, investor-count limits, transfer approvals, issuance caps. |
| Token features  | Add ordered token behavior around configured feature contracts.                       | Feature hooks that affect token behavior beyond compliance-module checks.                             |

Use compliance modules when the rule belongs to ordinary transfer, mint, or burn eligibility. Use recovery-specific procedures and roles for lost-wallet recovery controls. Use token features when the asset needs additional token behavior that is not simply a compliance rule.

## What to check before production [#what-to-check-before-production]

Before using a policy on a live asset, verify:

* The identity registry points to the intended identity records for the token.
* Each active compliance module is required for the asset's jurisdiction, instrument, and operating model.
* Every module parameter payload is encoded for that module's expected schema.
* Stateful modules are tested across the full lifecycle they track, including mint, transfer, burn, and any recovery-side state migration that applies to the asset.
* Recovery controls are reviewed separately from ordinary transfer policy. Confirm who can mark a wallet as lost, who can recover balances, and how the replacement wallet is verified.
* Governance roles for adding, removing, disabling, enabling, or reconfiguring modules are restricted to the intended operators.
* Asset policy changes have an operational approval path outside the smart contract transaction itself.

For auditors, this checklist defines the evidence boundary. Review the configured modules, parameters, identity records, role assignments, and operational approvals for the specific asset. Derive each asset's eligibility model from that asset's own configuration, even when another asset uses the same module contract.

## Related pages [#related-pages]

* [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)
* [Token features](/docs/architects/architecture/components/token-features)