DALP asset policy: per-asset compliance controls

Conceptual guide to DALP asset policy: the per-asset compliance modules, identity registry, lifecycle hooks, and governance controls that decide whether regulated token operations can execute.

An asset policy is the rule set DALP evaluates for a regulated token before mint, transfer, burn, and recovery flows change balances. It combines the token's identity registry, compliance engine, active compliance modules, and module-specific parameters. If a configured module rejects an operation, the operation reverts before the non-compliant state change is accepted.

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.
Compliance engine	Per asset reference	The engine that asks all active modules whether an operation is allowed.
Compliance modules	Per asset list	The 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	Accounting updates after transfers, mints, burns, and recovery flows complete.

The important distinction is between the module implementation and the asset's configuration. A module contract defines reusable logic. The asset policy decides whether that module is active for a given token and which parameters it receives.

How DALP evaluates policy

For a normal regulated transfer, DALP follows this order:

Resolve the token's current compliance module list and parameters.
Call each active module's pre-check for the requested token, sender, recipient, and amount.
Evaluate registry-level modules that apply across the system.
Revert if any module rejects the operation.
Execute the token state change only after the checks pass.
Run lifecycle hooks so stateful modules can update counters, approval usage, holding periods, or issuance trackers.

The same policy model also applies to 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 own accounting after the token operation succeeds.

flowchart TD
  Request[Token operation requested] --> Policy[Read asset policy]
  Policy --> Modules[Evaluate active compliance modules]
  Modules --> Registry[Evaluate registry-level modules]
  Registry --> Decision{All checks pass?}
  Decision -- No --> Revert[Revert operation]
  Decision -- Yes --> State[Apply token state change]
  State --> Hooks[Run lifecycle hooks]

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 add a compliance module, remove a module, or update parameters for an existing module.
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.

Asset policy vs. token features

Asset policy and token features are different extension points.

Extension point	Purpose	Example
Asset policy	Decide whether 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 is part of transfer, mint, burn, or recovery eligibility. 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 recovery flows where applicable.
Governance roles for adding, removing, or updating modules are restricted to the intended operators.
Asset policy changes have an operational approval path outside the smart contract transaction itself.

Where to go next

Use Compliance Modules to choose the rule families that belong in the policy.
Use Compliance Transfer Flow to follow the execution path for a regulated transfer.
Use Identity & Compliance to understand wallet identity, trusted issuers, and claim validation.

Asset Policy