SettleMint
ArchitectureFlows

Signing Flow

End-to-end transaction signing sequence in DALP, from on-chain compliance validation through the unified signer interface to MPC custody providers (DFNS and Fireblocks), including custodian policy evaluation and blockchain broadcast.

Purpose: Describes the end-to-end path a DALP transaction takes from initiation through dual-layer policy enforcement to on-chain execution.

Doc type: Explanation

What you'll find here:

  • End-to-end signing sequence with diagram
  • Step-by-step flow breakdown (compliance simulation, custody signing, broadcast)
  • Two-layer policy model (on-chain compliance + custodian policies)
  • Failure modes and resolution

See also: Key Guardian | Transaction Signer | Identity & compliance


Overview

Every DALP transaction passes through two independent policy layers before reaching the blockchain:

  1. On-chain compliance --- the SMART Protocol verifies identity claims, transfer restrictions, and supply limits via simulation.
  2. Custodian policy --- the configured custody provider (DFNS or Fireblocks) applies operational controls (amount limits, multi-party approval) before MPC signing.

Neither layer can be bypassed independently. A transaction must pass both to complete.

End-to-end sequence

Rendering diagram...

Flow steps

  1. Initiate transaction --- The operation enters the Execution Engine, which builds the payload, estimates gas, and assigns a nonce. No signing or state change occurs yet.

  2. On-chain compliance pre-check --- The engine simulates via eth_call against the SMART Protocol's canTransfer. This checks identity claims, compliance modules, and amount/volume limits without spending gas. If simulation reverts, the failure surfaces immediately.

  3. Unified signer interface --- The Transaction Signer delegates to a provider-agnostic layer abstracting over DFNS, Fireblocks, and local key backends. Switching providers requires only configuration.

  4. Custody provider MPC signing --- The active provider evaluates its own policy rules before combining MPC key shares. If policy requires approval, the transaction enters a pending state until actioned out-of-band.

  5. Broadcast and on-chain execution --- The signed transaction is submitted via eth_sendRawTransaction. The compliance engine enforces canTransfer again on-chain. If compliance state changed between simulation and broadcast, the transaction reverts.

Two-layer policy model

LayerWhere enforcedWhat it controlsConfigured by
On-chain complianceSMART Protocol contractsIdentity/KYC claims, country restrictions, blocklists, supply caps, investor counts, time locks, volume modulesIssuer / compliance manager via DALP API
Custodian policiesDFNS policy engine or Fireblocks TAPPer-transaction amount limits, rolling spend limits, approver workflows, IP/time restrictions, destination allowlistsOperations team in provider dashboard

Key invariants:

  • Layer 1 (on-chain) enforces regulatory compliance at protocol level and cannot be bypassed off-chain
  • Layer 2 (custodian) provides operational controls and approval workflows at infrastructure level
  • Both layers must pass for a transaction to complete
  • On-chain amount limits (via custom compliance modules) are auditable on-chain; custodian limits are off-chain operational controls

Failure modes

Failure pointCauseResolution
Simulation revertOn-chain compliance module blocked the transactionCheck compliance status, claims, and module configuration
Custodian policy blockTransaction exceeds custodian amount limit or ruleAdjust policy thresholds or request approval
Pending approval timeoutApprovers have not actioned the requestEscalate or configure auto-reject after timeout
MPC signing failureNetwork or provider issueAutomatic retry with exponential backoff
Broadcast failureGas underpricing or nonce conflictTransaction Signer resubmits with increased gas
On-chain revertCompliance state changed between simulation and broadcastSurface revert reason; re-evaluate compliance

See also

On this page