DALP compliance transfer: on-chain validation flow

Step-by-step sequence for how DALP validates token transfers through recipient identity checks, token-specific compliance modules, global compliance policy, and post-transfer state hooks.

System context

DALP checks transfer restrictions at execution time for standard token movements. A holder-initiated transfer, an allowance-based transferFrom, and a standard batch transfer all end in the token's state-update path, where the token verifies the recipient identity and asks the configured compliance contract whether the movement is allowed before balances change.

Custodian forced transfers are a separate exception path for governed recovery, legal, or compliance cases. These custodian-only operations bypass holder approval, standard freeze restrictions, and the configured compliance canTransfer check. The recipient must still pass the token's identity check before balances change.

Rendering diagram...

DALP reads identity, compliance, balances, feature hooks, and external-call paths during token movement. That transfer path is the review surface for flash-loan and reentrancy behaviour.

Identity & Compliance - architecture explanation
Compliance Modules - module catalog
Signing Flow - complete transaction security sequence
Paymasters and gas sponsorship - who funds eligible account abstraction transactions
SMART Protocol integration (ERC-3643) - core protocol architecture

Transfer validation sequence

Standard transfers, including holder-initiated transfers, allowance-based transfers, and batch helpers, pass through the token's recipient identity check and compliance engine before balances change.

Rendering diagram...

Step-by-step flow

Transfer initiation - A caller uses transfer(to, amount), transferFrom(from, to, amount), or a standard batch helper that submits individual token transfers.
Compliance check - Before any balance update, the token checks the recipient identity and calls the configured compliance contract for the current from, to, and amount.
Recipient identity verification - The identity registry verifies the recipient. If the recipient is not registered or verified, the token movement reverts before balances change and before compliance modules run.
Sequential module evaluation - The compliance contract evaluates active, in-scope modules in stored binding order, then delegates to the deployment's global compliance policy:
- Each module receives the token movement context. Current module instances read their own stored configuration; adapted legacy modules receive their adapter configuration.
- Modules that require claims can query the sender's or recipient's on-chain identity.
- Claim validation can include required topics, trusted issuers, expiry, and configured claim data.
- The first failing module reverts and blocks the movement.
Balance transfer - After recipient identity, token-specific compliance, and global policy checks pass, the token updates balances.
State update hooks - After the balance update, the token notifies the compliance contract so active in-scope modules can update transfer-related state:
- Investor count modules update holder counts
- Supply tracking modules update accumulation
- Time lock modules record acquisition timestamps
- Transfer approval modules consume single-use approvals

Compliance verification checks gate all token transfers

Key invariants

Execution-time validation: DALP checks the current token, identity registry, and compliance contract state when the transfer is attempted.
Pre-execution validation: Identity and compliance checks complete before balances change, so failed checks revert before token state is updated.
Allowance path coverage: approve only grants an allowance. The later transferFrom still updates token state through the same transfer hooks and compliance check.
Batch helper coverage: Standard batch helpers submit per-recipient token transfers, so each item is checked as its own movement.
Fail-fast evaluation: First failing module stops evaluation and blocks the movement.
Atomic state updates: Post-transfer hooks must succeed or the whole transfer reverts.
Module ordering matters: Modules evaluate in configuration order. Put broad eligibility checks before more expensive stateful checks where possible.

Gas and failed-execution behavior

A failed compliance transfer does not partially move tokens. Recipient identity checks and compliance canTransfer evaluation run before the balance update. If the identity check fails, a module reverts, global policy rejects the movement, a post-transfer hook fails, or the transaction runs out of gas, the EVM reverts the transaction and token balances stay unchanged.

DALP transfer checks are bounded by the modules configured for the token and the deployment's global compliance policy. A standard transfer asks the compliance engine to evaluate token-specific modules and global modules in order. List-based modules and batch helpers still consume gas according to the configured list size or batch size, so operators should keep those configurations within tested limits.

The gas boundary is different from the token-state boundary. A reverted public-chain transaction can still consume gas from the submitting wallet or sponsor. DALP therefore treats gas management as an execution concern and compliance failure as an asset-state concern.

Scenario	Token-state result	Gas and operator result
Recipient identity is missing	No balances change. The token reverts before module evaluation.	Broadcast attempts can still consume gas.
A compliance module blocks the movement	No balances change. The compliance check stops the transfer.	The caller or sponsor may pay for the reverted execution. Review the module reason before retrying.
A post-transfer module hook fails	The whole transfer reverts, including the balance update and module state changes.	Treat the operation as failed and fix the hook or configuration before retrying.
A batch item fails in a standard batch transfer	The batch transaction does not complete.	Split or correct the failing item before submitting the batch again.

For sponsored account abstraction flows, sponsorship changes who funds eligible execution. Sponsorship does not bypass identity checks, compliance checks, custody approval, or final contract execution.

Operationally, gas protection is a combination of protocol design and deployment monitoring:

Keep the active module set focused on the policy the asset needs.
Put broad, low-cost eligibility checks before more expensive stateful checks.
Monitor transaction receipts and failed transaction states so operators can detect underfunded wallets, misconfigured modules, or unusually expensive transfer attempts.
Treat gas funding for operator and user wallets as an operational control, not as a token-ledger exception.

Flash-loan and reentrancy boundaries

DALP asset tokens do not expose a native flash-loan entry point. Standard asset movements use the ERC-20 transfer surface and run the same recipient identity and compliance checks before balances change. A borrowed balance only matters to DALP if a transaction reaches the token through a supported transfer path and passes the configured token controls for the current from, to, and amount.

DALP separates token-ledger controls from external DeFi, voting, or valuation logic. The token can expose current balances, historical balance checkpoints for asset classes that include them, and timestamp-based voting checkpoints for voting-enabled assets. DALP does not provide a default time-weighted average balance oracle. DALP also does not make an external lending, collateral, or voting protocol safe merely because that protocol reads a DALP balance.

For flash-loan-sensitive integrations, use a balance reference that cannot be created and consumed inside the same transaction. A DeFi protocol that accepts a DALP token as collateral should use its own oracle, eligibility, liquidation, and time-weighting policy, or read a prior checkpoint where that is available. A governance flow should use voting checkpoints rather than the holder's current balance. If the external protocol reads only the current balance during the same transaction, the mitigation belongs in that protocol, not in the DALP transfer hook.

Scenario	DALP token boundary	Required integration mitigation
Borrowed DALP tokens are moved into a DeFi protocol	The incoming transfer still needs recipient identity and compliance approval before balances change.	The DeFi protocol should not value collateral from a same-transaction balance alone; use an oracle, prior checkpoint, delay, or TWAB policy.
Borrowed tokens are used to influence voting or holder weight	Voting-enabled assets expose timestamp-based checkpoints for voting power.	Read voting power from the relevant checkpoint, not the caller's current balance after an intra-transaction transfer.
A protocol needs historic balances for eligibility or exposure	Asset classes with historical balances record checkpoints after mint, burn, and transfer state changes.	Choose and document the timepoint policy. DALP does not choose that policy for the external protocol.
A custom wrapper adds lending, callbacks, or transfer hooks	The wrapper is outside the standard DALP token transfer surface.	Re-run the integration's security review and static analysis for the wrapper and any new callback paths.

Reentrancy-sensitive DALP token paths are bounded by the token surface:

Area	Boundary
Standard transfers	Recipient identity checks and compliance checks run before the balance update. Post-transfer compliance notifications run in the same transaction, so a failed hook reverts the whole transfer.
Compliance module callbacks	Modules are part of the trusted compliance configuration. A malicious module requires governance control to install; custom modules should be reviewed for callback behavior before activation.
Feature payout flows	`DALPAsset.payout()` and bond redemption entry points that make external transfers use reentrancy guards. Other configured payout or redemption features need deployment-specific review evidence for their own external-call paths.
ERC-777 and ERC-1363 callbacks	DALP asset tokens use an ERC-20 style transfer surface. ERC-777 send hooks and ERC-1363 transfer callbacks are not part of the standard DALP token interface.
Custom transfer hooks	Custom hooks are not part of the default transfer surface. If a deployment adds wrapper contracts or custom hook logic, those contracts must carry their own reentrancy protections and deployment-specific evidence.

Security evidence for the deployed token scope should include static-analysis and review results for the actual token implementation, enabled feature contracts, compliance modules, and any wrapper contracts. For a clean reentrancy answer, that evidence should show no open untriaged reentrancy findings on the deployed token transfer and external-call paths, including results from the analysis tools selected for the deployment such as Slither or Mythril, or identify the specific guard, role boundary, or accepted-risk decision for each finding.

Bypass and exception boundaries

Path	DALP behavior
`transfer`	Runs the standard transfer validation flow before balances change.
`transferFrom`	Uses the caller's allowance, then runs the same transfer validation flow before balances change.
Standard batch transfer	Executes each item through the standard transfer path. If one item reverts, the batch transaction does not complete.
Custodian forced transfer	Custodian authority may move tokens for governed recovery, legal, or compliance operations. Holder approvals, standard freeze restrictions, and the configured compliance `canTransfer` check do not apply. The recipient identity check still applies.
Delegatecall by external contracts	External wrapper contracts cannot change DALP token balances directly. If a wrapper calls the DALP token contract, the token's state-update path applies.
ERC-777 hooks	DALP asset tokens use an ERC-20 style token surface. ERC-777 send hooks are not part of the DALP transfer surface.
Flash loan callbacks	DALP asset tokens do not expose a flash-loan transfer path. If an external protocol returns DALP tokens through a normal token transfer, the normal token transfer checks still apply.

Dynamic eligibility boundary

Eligibility is checked against current on-chain platform state at the time the token movement is attempted. That includes the current identity registry, trusted issuer and claim state, and the configured compliance modules for the asset.

If eligibility changes in an off-chain compliance or investor system, DALP can only enforce that change on-chain after the relevant registry, claim, or compliance state has been updated. The lag between an external eligibility decision and on-chain enforcement is therefore an operating and integration boundary, not a fixed DALP protocol delay.

Failure modes

Failure	Cause	Behavior
Recipient identity not registered	Recipient wallet has no OnchainID mapping	Immediate revert, no module evaluation
Recipient identity is not verified	Recipient fails the registry's current identity policy	Immediate revert, no module evaluation
Module claim rule fails	Required claim topic, issuer, expiry, or value fails	The evaluating module reverts with its configured denial reason
Module limit exceeded	Supply cap, investor count, or holding period violated	The evaluating module reverts with its configured denial reason
Global compliance policy rejects movement	Deployment-level compliance policy blocks the transfer	The compliance check reverts before balances change
State hook failure	Post-transfer module state update fails	Entire transfer reverts

Compliance Transfer