Asset policy

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.

Asset policy is not the same as custody policy. Asset policy explains the token rule set. Compliance and custody split separates on-chain eligibility checks from signer, wallet, and custody-provider approvals.

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

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.

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, which parameters it receives, and whether any scope filters narrow the operations it checks.

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:

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

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.

How policy is configured

Asset policy can be set at creation time and changed later by governed roles. The same concept appears in three operator surfaces: asset creation, token compliance management, and platform compliance-module management.

The token exposes its active module list and parameters so the compliance engine can evaluate the current policy at execution time.

For scoped module bindings, the live policy also includes the module scope. Scope is part of the binding, not just a UI filter. An empty scope means every transfer goes through that module instance. A narrowed scope means the module applies only to the operations covered by that binding. When operators update a scoped module, DALP can update the module parameters and scope together so the policy does not pass through a half-updated state.

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.

How to read a policy decision

When a policy blocks an operation, read the failed check by enforcement question rather than by module name alone. The same asset can combine broad eligibility rules, stateful limits, approval workflows, and backing checks.

This makes the policy auditable without turning every module into a separate operating procedure. First identify the question the failed module answers, then verify the identity record, configured parameters, and lifecycle state for the affected asset.

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 controls handle exceptional cases. They do not replace the compliance modules that decide whether ordinary holder activity can proceed.

This split matters when you design an operating model:

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-operation review for those controls belong in the operator's custody procedure.

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

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

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 and token features are different extension points.

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

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 to review. Check 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

• Create an asset for the operator path that sets the initial policy on a new asset.
• Compliance modules for the available rule families and compliance-module controls.
• Claims and identity for the identity records and trusted-issuer claims that policy checks can require.
• Compliance and custody split for separating asset-policy checks from signing and custody-provider approvals.
• Compliance transfer flow for the end-to-end transfer decision path.
• SMART Protocol integration for the token standard layer underneath DALP assets.
• Token features for token behaviour that is not simply a compliance rule.