Signing Flow

System context

The signing flow is the shared path for every DALP operation that writes to an EVM network. DALP first verifies that the caller can submit the request. The Workflow Engine then builds the transaction payload, the SMART Protocol compliance model runs before signing, and the configured custody provider signs before broadcast.

DALP routes each write through one of two paths: a directly signed EVM transaction from an externally owned account (EOA), or a smart wallet that submits a UserOperation. The transaction queue chooses the path. Request controls, compliance checks, and custody policies apply on both. If you are integrating or auditing the smart wallet path, see Advanced accounts route below; the rest of this page covers the EOA path.

See also: Wallet verification | Key Management | Transaction Signer | Identity & compliance

---

Overview

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

1. 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.
2. On-chain compliance: the SMART Protocol verifies identity claims, transfer restrictions, and supply limits via simulation.
3. Custodian policy: the configured custody provider applies operational controls such as amount limits, multi-party approval, or hardware-backed quorum before signing.

For transfers, minting, redemption, and similar lifecycle operations, all applicable request controls, compliance checks, and custody policies must pass before the operation completes. Custodian-only operations such as forced transfers use the custodian role and bypass standard transfer-compliance checks by design. Treat them as exceptional servicing controls, not as ordinary transfer flows. To locate where your operation failed, use the control model table and failure-modes table below.

End-to-end sequence

Flow steps

1. 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.

2. Prepare the transaction. The accepted operation enters the Workflow Engine, which builds the contract call payload, estimates gas, and assigns a nonce from the reserved nonce pool. No signing, state change, or on-chain submission occurs at this step.

3. Run the compliance pre-check. The engine simulates canTransfer via eth_call before any signing occurs. The simulation checks identity claims, compliance modules, and amount or volume limits without spending gas or changing state. If the simulation reverts, DALP surfaces the compliance module's revert reason immediately and stops the flow before the custody provider is involved. This early gate lets you resolve compliance issues without exhausting a nonce reservation or triggering a custody approval workflow.

4. Route through the unified signer. The Transaction Signer delegates to a provider-agnostic signing layer. This layer supports approved custody backends and local signing modes so that switching your configured backend changes only provider setup, not the transaction flow.

5. 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.

6. 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.

7. 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, not as permission to broadcast any signed bytes returned later. When you review a signing failure, check whether the failure occurs before or after this validation step.

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

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.

Advanced accounts route

The sequence above covers the externally owned account (EOA) path: the custody provider signs an EVM transaction and DALP broadcasts the raw bytes to the node. DALP also supports a smart wallet route. Your organisation's advanced accounts setting, plus an optional executor override on the request, determines which route the transaction queue selects.

On the smart wallet route, request controls, preparation, and the compliance pre-check are the same. Execution differs after signing:

• DALP builds a UserOperation instead of a plain EVM transaction, signs it with the controlling key, and submits it through the bundler to the ERC-4337 EntryPoint rather than broadcasting raw bytes to the node.
• When a paymaster is enabled and funded, it pays the gas, so the smart wallet does not need its own native token balance. When sponsorship is off, the smart wallet pays its own gas.
• When the smart wallet requires a signing threshold, DALP records a pending approval and waits for the co-signers before the UserOperation is submitted, in the same way the EOA path waits for a custody provider approval.

The control model is identical on both routes. Identity claims, transfer policy, and custody approval are evaluated against the operation, not against the execution route. Account abstraction changes which account submits the transaction and how gas is paid, not whether the operation is allowed. If you need the full route-resolution and signing model, see Transaction signer; for the concepts, see Advanced accounts.

Control model

Key invariants to understand when you integrate or audit this flow:

• 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

Use this table to locate the layer where your operation failed and what to check next.

See also

To diagnose a signing failure, start with the failure-modes table above before reading these pages.

• Wallet verification - per-request PIN, OTP, and backup-code checks before user-session signing operations
• Key Management - key storage and custody backend options for signing operations
• Transaction Signer - gas management, nonce coordination, and retry logic
• Advanced accounts - the smart wallet execution route and the boundary it keeps
• Advanced accounts infrastructure - UserOperations, bundlers, EntryPoint, and paymasters
• Identity & compliance - on-chain compliance modules including amount and volume controls
• Broadcast - EVM RPC node access and transaction broadcast