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.

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 and which parameters it receives.

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.

• 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 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 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

• Compliance modules
• Claims and identity
• Compliance transfer flow
• SMART Protocol integration
• Token features