DALP signing flow: custody and compliance controls

How DALP moves an EVM transaction from a verified user or API request through compliance simulation, custody signing, provider policy review, and broadcast.

System context

The signing flow is the shared path for DALP operations that write to an EVM network. DALP first verifies that the caller is allowed to submit the request, then the Execution Engine builds the transaction, the SMART Protocol compliance model is checked before signing, and the configured custody provider signs before broadcast.

Rendering diagram...

Overview

Standard DALP transactions pass through three checks before reaching the blockchain:

Request controls - DALP authenticates the caller, checks authorization, and applies wallet verification when a user session submits an operation that needs a blockchain signature. API-key integrations authenticate through the API key path instead of user wallet verification.
On-chain compliance - the SMART Protocol verifies identity claims, transfer restrictions, and supply limits via simulation.
Custodian policy - the configured custody provider applies operational controls such as amount limits, multi-party approval, or hardware-backed quorum before signing.

For normal transfers, minting, redemption, and similar lifecycle operations, the applicable request controls, compliance checks, and custody policies must pass before the transaction completes. Custodian-only exception operations, such as forced transfers, use the custodian role and bypass standard transfer-compliance checks by design. Treat those operations as exceptional servicing controls, not as ordinary transfer flows.

End-to-end sequence

Rendering diagram...

Flow steps

Submit the request - DALP authenticates the caller and checks the permission required for the operation. User-session writes that need a blockchain signature include wallet verification evidence. API-key integrations use API-key authentication and do not prompt for a user's PIN, OTP, or backup code.
Prepare the transaction - The accepted operation enters the Execution Engine, which builds the payload, estimates gas, and assigns a nonce. No signing or state change occurs yet.
Run the compliance pre-check - The engine simulates canTransfer via eth_call. The simulation checks identity claims, compliance modules, and amount or volume limits without spending gas. If the simulation reverts, DALP surfaces the failure immediately.
Route through the unified signer - The Transaction Signer delegates to a provider-agnostic layer that supports approved custody backends and local signing modes. Switching the configured backend changes provider setup, not the transaction flow.
Apply custody provider policy - The active provider evaluates its own policy rules before signing. Custody backends can combine key shares, enforce approval workflows, or require hardware-backed quorum before returning a signature.
Check signed payload integrity - For sign-only custody paths that return signed EVM bytes after an approval step, DALP validates the signed transaction before broadcast. The signed payload must match the original transaction request for nonce, destination contract, calldata, chain ID, optional value, and signer address. If any field differs, DALP refuses to broadcast the payload.
Broadcast and execute on-chain - The validated signed bytes are submitted via eth_sendRawTransaction. The node returns the transaction hash for those submitted bytes. DALP records that hash, waits for the matching receipt, and only then marks the operation complete. The compliance engine enforces canTransfer again on-chain. If compliance state changed between simulation and broadcast, the transaction reverts.

Payload integrity before broadcast

DALP treats custody approval as permission to sign a specific EVM payload. It is not permission to broadcast any signed bytes returned later. On async sign-only custody paths, the platform parses the signed transaction after approval. The signed transaction must match the prepared request before it reaches the RPC node. DALP submits those validated bytes to the node and records the transaction hash returned for that submission. If durable execution replays after the node already accepted the transaction but before the hash was recorded, DALP derives the same hash from the validated signed bytes and continues confirmation instead of broadcasting a different payload.

Check	What DALP verifies	Why it matters
Nonce	The signed transaction uses the nonce reserved for the sender and chain	Prevents a stale or substituted payload from consuming the wrong nonce lane
Destination	The `to` address matches the contract selected by the original operation	Prevents a signature for one target from being replayed against another target
Calldata	The function data matches the prepared operation	Prevents a changed method call or changed arguments from being broadcast after approval
Chain ID	The signed transaction carries the expected EVM chain ID	Prevents cross-chain replay of an approved payload
Value	When the original request includes native value, the signed payload carries the same amount	Prevents payable value substitution on the same nonce and calldata
Signer	The recovered signer address matches the wallet that owns the nonce reservation	Prevents a payload signed by another key from completing the reserved transaction
Broadcast hash	The transaction hash is recorded from the node response for the validated signed bytes	Binds completion tracking and receipt lookup to the payload that DALP submitted

If validation fails, DALP fails the operation before broadcast. If broadcast succeeds but the journal replays before the transaction hash is recorded, DALP can recover the already-known transaction hash from the same validated signed bytes and continue confirmation without reusing the nonce reservation.

Control model

Layer	Where enforced	What it controls	Configured by
Request controls	DALP API and Asset Console request path	Authentication, authorization, participant and executor selection, wallet verification for user-session signing requests	Platform administrators and user security settings
On-chain compliance	SMART Protocol contracts	Identity/KYC claims, country restrictions, blocklists, supply caps, investor counts, time locks, volume modules	Issuer / compliance manager via DALP API
Custodian policies	Configured custody provider policy and quorum controls	Per-transaction amount limits, rolling spend limits, approver workflows, IP/time restrictions, destination allowlists, quorum approval	Operations team in the custody provider control surface

Key invariants:

Request controls reject unauthenticated, unauthorized, or unverifiable user-session requests before the signing flow starts.
On-chain compliance enforces regulatory transfer rules at protocol level for standard token lifecycle operations.
Custodian policy provides operational controls and approval workflows at infrastructure level.
Standard token operations must pass each applicable control layer before they complete.
Custodian-only exception operations, including forced transfers, do not follow the standard canTransfer compliance path. Use them only for controlled servicing cases where the custodian role is authorised to intervene.
On-chain amount limits (via custom compliance modules) are auditable on-chain; custodian limits are off-chain operational controls.

Failure modes

Failure point	Cause	Resolution
Request rejected	Authentication, permission, wallet setup, or wallet verification failed	Check the caller, role, participant/executor, and wallet verification method
Simulation revert	On-chain compliance module blocked the transaction	Check compliance status, claims, and module configuration
Custodian policy block	Transaction exceeds custodian amount limit, provider rule, or quorum policy	Adjust policy thresholds or request approval
Pending approval timeout	Approvers have not completed the provider approval request	Escalate or configure auto-reject after timeout
Signed payload mismatch	Signed bytes do not match the prepared nonce, target, calldata, chain, value, or signer	Treat as failed before broadcast and review the custody approval record
Signing failure	Network, provider, or custody backend issue	Automatic retry with exponential backoff
Broadcast failure	Gas underpricing or nonce conflict	Transaction Signer resubmits with increased gas
On-chain revert	Compliance state changed between simulation and broadcast	Surface revert reason; re-evaluate compliance

Signing Flow