Policy-based transfer controls for regulated DALP tokens

Understand how DALP combines identity, eligibility, asset policy, transfer approvals, and settlement conditions before regulated token transfers execute.

Overview

DALP policy-based transfer controls decide whether a regulated EVM token transfer may execute. The control path combines holder identity, asset policy, compliance modules, optional transfer approval, execution state, settlement workflow state, and post-transfer evidence.

The page separates the transfer path into three phases: validation before execution, execution of the approved movement, and post-transfer events that prove what happened.

Validation before execution

A DALP transfer is not only a token movement. The token calls its compliance engine before the operation executes. The compliance engine evaluates the modules selected for that token. If one selected module rejects the transfer, the operation stops.

The validation path checks:

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 application checks the surrounding deal and leg state before it treats the movement as ready for settlement execution.

For the underlying compliance model, start with Compliance Modules, Asset policy compliance, and Transfer approval.

Execution

Execution starts only after the selected policy layers allow the transfer. The token contract evaluates the compliance modules in the transaction 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 execution boundary around the token movement. A PvP or DvP flow coordinates the approved token leg with the matching payment or exchange leg, expiry rules, cancellation path, and evidence for the workflow outcome. See the XvP settlement overview and settlement execution boundaries.

API clients should treat rejected transfers as policy decisions when the platform returns a policy failure. They should not retry the same request as if it were only a transient transport failure. See the token holder transfer API guide for approval-aware transfer calls.

Post-transfer events and audit evidence

After execution, the operating record has to reconcile the requested transfer, the approval record, the transaction hash, and the final on-chain outcome. Event consumers should connect the API request, emitted event, settlement workflow state, and audit record before an external workflow treats the transfer as complete.

Use events for the event model, idempotency and on-chain outcome events for retry and outcome semantics, and reporting and audit access for inspection paths.

Control layers

Layer	What it checks	Related docs
Asset policy	Which controls apply to the token	Asset policy compliance
Holder eligibility	Whether sender and receiver evidence matches policy	Identity verification, identity lists, country restrictions
Address restrictions	Whether a wallet is blocked	Address block list
Limits and holding periods	Holder, supply, issuance, and TimeLock limits	Supply and investor limits, TimeLock
Prior approval	Whether the transfer requires and consumes an approval	Transfer approval
Workflow evidence	Whether API state, events, audit evidence, and settlement outcome line up	Token holder transfers, events, XvP settlement overview, reporting and audit access

Transfer approval boundary

Transfer approval is one policy layer, not the whole transfer-control system. An asset can require a review record before a transfer executes. The transfer still has to satisfy the other selected compliance modules and any settlement workflow checks that apply.

An approval can show 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 evidence.

Production readiness

Before relying on policy-based transfer controls in production, confirm that:

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 business process;
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, such as KYC/KYB, legal approvals, banking records, custody records, and reserve or backing evidence.

DALP enforces the selected EVM token controls. Your organisation remains responsible for choosing the policy, maintaining source evidence, and reconciling the external systems that sit around the token transfer.

Policy-based transfer controls