Policy-based transfer controls
Understand how DALP combines identity, eligibility, asset policy, transfer approvals, and settlement conditions before regulated token transfers execute.
Overview
DALP enforces a layered compliance path before any regulated token transfer executes. If any layer rejects the operation the transfer stops without reaching the ledger, and post-transfer events produce a verifiable audit evidence chain that ties the request to the outcome.
This page walks you through three phases: pre-execution checks, the approved transfer itself, and post-transfer events that prove what happened.
Pre-execution checks
A DALP transfer is not only a token move. The token calls its compliance engine before the operation runs. The engine evaluates the modules selected for that token. If one selected module rejects the transfer, the operation stops.
The check path verifies:
- The sender and receiver are known as token holders or wallet identities.
- Identity and claim-based controls match the evidence required by the asset policy.
- Address, country, supply, investor-count, TimeLock, and other configured modules evaluate their own rules.
- If the asset requires prior review, the transfer approval module checks whether the transfer has an approval that still applies.
- In settlement workflows, the platform checks the surrounding deal and leg state to confirm the move is ready.
For the underlying compliance model, start with Compliance Modules, Asset policy compliance, and Transfer approval.
Execution
The transfer executes only after the selected policy layers allow it. The token contract evaluates the compliance modules in the on-chain path. The transfer approval layer can allow a reviewed transfer to proceed, but it does not bypass identity, country, address, holder-limit, supply, TimeLock, or settlement-state checks.
Settlement workflows add a second boundary around the token move. A PvP or DvP flow coordinates the approved token leg with the matching payment or exchange leg, expiry rules, a cancellation path, and proof of the workflow outcome. See the XvP settlement overview and settlement execution controls. When the platform returns a policy failure, your API client should treat the rejected transfer as a policy decision, not a transient transport error to retry blindly. See the token holder transfer API guide for approval-aware transfer calls.
Post-transfer events and audit evidence
After the transfer completes, reconcile the API request, the approval record, the transaction hash, and the final on-chain outcome. Your event consumers should connect the emitted event, settlement workflow state, and audit record before any external workflow treats the transfer as complete.
Use webhook endpoints for the delivery model, token holder transfers for transfer request semantics, and reporting and audit access for query paths.
Control layers
Each layer runs in sequence. A rejection at any layer stops the transfer before it reaches the ledger.
Policy and eligibility checks run first.
| Layer | What it checks | Related docs |
|---|---|---|
| Asset policy | Which controls apply. | Asset policy compliance |
| Holder eligibility | Whether holder evidence matches policy. | Identity verification, identity lists, country restrictions |
| Address restrictions | Whether a wallet is blocked. | Address block list |
Limit and approval checks follow.
| Layer | What it checks | Related docs |
|---|---|---|
| Limits and holding periods | Holder, supply, issuance, and TimeLock limits. | Supply and investor limits, TimeLock |
| Prior approval | Whether a prior approval exists and applies. | Transfer approval |
Workflow evidence closes the path.
| Layer | What it checks | Related docs |
|---|---|---|
| Workflow evidence | Whether events and settlement outcome align. | Token holder transfers, webhook endpoints, XvP settlement overview, reporting and audit access |
What transfer approval covers
Transfer approval is one policy layer, not the whole transfer-control system. An asset can require a review record before a transfer executes, but the transfer must still satisfy the other selected compliance modules and any settlement workflow checks that apply.
An approval shows that a workflow authorised a proposed transfer. The approval record does not replace identity, country, address, holder-limit, supply, TimeLock, event, audit, or settlement-state checks.
Production readiness
Check each of the following before relying on policy-based transfer controls in production:
- Asset policies list the required modules and parameters for each regulated token.
- Identity and trusted-issuer records are maintained by the right operational process.
- Transfer approval roles, expiry, and revocation rules match the workflow.
- API clients handle rejected transfers as policy decisions rather than retry-only failures.
- Event consumers reconcile the requested transfer, approval state, transaction hash, settlement state, and final on-chain outcome.
- Operational teams know which evidence is off-chain: KYC/KYB records, legal approvals, banking records, custody records, and reserve or backing proof.
DALP enforces the selected EVM token controls. Your organisation remains responsible for choosing the policy, maintaining source evidence, and reconciling the external systems around the transfer.
Identity verification reference
Configure postfix claim expressions that gate token recipients on KYC, AML, accreditation, or any trusted issuer claim before a transfer executes.
Supply & Investor Limits
TokenSupplyLimit and InvestorCount modules for time-based and rolling supply caps with currency conversion, plus unique holder limits with per-country granularity.