Transaction Signer
The Transaction Signer prepares, signs, broadcasts, and confirms EVM contract transactions through EOA, smart-wallet, custody-provider, and HSM-backed signing paths.
Overview
The Transaction Signer turns a validated DALP contract operation into an EVM transaction or ERC-4337 user operation. It chooses the execution route, appends DALP attribution to the call data, selects the configured signer, and records the transaction state until confirmation or failure.
Provider-specific custody setup, smart-wallet signer management, and contract business rules stay outside what the Transaction Signer controls.
Transaction lifecycle
The EOA path serializes broadcast work by organization, signer address, and chain ID. That partition keeps nonce allocation exclusive for one signing address on one chain while unrelated signers continue processing.
Execution routes
| Route | When DALP uses it | Signing responsibility | Completion responsibility |
|---|---|---|---|
| EOA transaction | The operation resolves to an externally owned account or smart-wallet routing is disabled for the request. | The configured signer prepares and signs an EVM transaction for the resolved wallet. | The transaction reaches a receipt and the state store records completion or failure. |
| Provider-native broadcast | The configured custody provider supports its own transaction broadcast flow. | The provider handles nonce, gas, signing, and broadcast internally. | DALP polls the provider for the on-chain hash, then confirms the transaction on-chain. |
| Sign-only approval | DFNS or Luna returns a signature only after policy or quorum approval. | DALP waits for the approved signed transaction, then broadcasts and confirms it. | Rejection, timeout, or listener failures move the transaction to a failed state with an approval sub-status. |
| ERC-4337 smart wallet | The participant resolves to a smart wallet and the request does not force EOA routing. | DALP signs the user operation with the controlling EOA. | The bundler lifecycle returns a confirmed transaction or a failed user operation. |
| ERC-4337 multisig | The smart wallet has a threshold that requires co-signer approval. | DALP creates a pending approval before on-chain submission. | The approval workflow owns submission and final transaction state updates after the caller receives the pending marker. |
The smart-wallet route can use paymaster sponsorship when the organization setting enables it. When sponsorship is not enabled, the account-abstraction path still runs and the user pays gas.
Nonce, replay, and idempotency controls
DALP prevents duplicate EVM submissions through three layers: request idempotency, wallet-route binding, and serialized nonce allocation. An integration retry should reuse the same idempotency key only for the same intended operation and executor route. If the original transaction already completed, DALP returns the existing transaction result instead of queueing another broadcast.
EOA broadcast uses an exclusive processor key made from the organization, signing address, and chain ID. This prevents two requests for the same signer on the same chain from receiving the same nonce. The workflow validates malformed or missing contract inputs before it takes that exclusive lock, so bad payloads do not block the signer queue.
Idempotency is scoped to the submitting wallet, chain ID, and idempotency key for a 24-hour window. A retry that reuses the same idempotency key with a different executor selection is rejected instead of attaching to the earlier transaction. This matters for account-abstraction deployments because the same participant may be able to submit through a direct EOA path or a smart-wallet path, and those routes must not collapse into the same retry identity.
EVM replay protection also depends on the chain ID in the signed transaction. DALP keeps nonce state and transaction queue state chain-specific, so a nonce reserved for one chain is not reused as a valid signing sequence for another chain. Cross-chain replay protection still depends on the target network and contract design; DALP does not make a transaction submitted on one EVM network executable on another network.
Nonce recovery compares DALP nonce state with on-chain transaction count. When signing is interrupted before broadcast, cancellation syncs nonce state with the chain before the caller retries. When a transaction already has an on-chain hash and the caller cancels it, DALP uses a replacement transaction instead of reusing the nonce for a different contract call.
Payload integrity between construction and broadcast
DALP stores the prepared operation and request metadata before signing starts. The operation records the sender wallet, target contract address, encoded call data, optional value, operation kind, and optional wallet selection. The transaction request row stores the chain ID separately.
The execution workflow reads the stored operation, validates the operation shape, resolves the execution route from the current wallet-routing configuration, validates that the target contract has code for direct EOA and provider-broadcast routes, and appends DALP attribution. The workflow then passes the prepared to, data, value, wallet, and resolved route to the signer.
The integrity check depends on the execution route:
| Route | Payload binding before signing | Broadcast and completion check |
|---|---|---|
| EOA transaction | The transaction processor signs and broadcasts the prepared target address, call data, value, signer wallet, nonce, and chain ID through the configured signer path. The exclusive organization, signer address, and chain partition prevents concurrent payloads from sharing a nonce. | DALP records the returned transaction hash, confirms the receipt, and completes the queue entry only after confirmation succeeds. |
| Provider-native broadcast | DALP sends the prepared target address, call data, value, wallet, and tenant scope to the custody provider's broadcast interface. The custody provider owns policy review and broadcast for that route. | DALP stores the provider-returned hash when one is available, then uses that hash for on-chain confirmation. If the provider keeps the request pending without a hash, completion waits until the provider returns a hash or the request fails. |
| Sign-only approval | DALP creates the signing request from the prepared transaction and holds the nonce reservation while the provider policy review is pending. Before broadcast, the approval monitor parses the signed transaction and rejects it if nonce, target address, call data, chain ID, signer, or value differs from the original signing request. | DALP broadcasts only the validated signed bytes, records the hash returned by the network, waits for a receipt, and then finalizes the nonce reservation. |
| ERC-4337 smart wallet | DALP builds the user operation from the prepared target address, call data, wallet route, and sponsorship setting. Multisig wallets create a pending approval before submission. | The bundler lifecycle returns the confirmed transaction hash or a failed user operation, and DALP updates the transaction request state from that result. |
A completed transaction request with an on-chain hash links the stored DALP operation to the confirmed on-chain transaction hash. Route reconstruction also needs execution-time route evidence from the signer or custody provider, because DALP resolves that route when the workflow executes.
For sign-only custody flows, DALP also performs a signed-payload comparison before broadcast. For provider-native custody flows, the external custody provider owns approval, signing, and payload review; DALP only claims on-chain confirmation for provider-native requests once a transaction hash is available.
Custody and approval modes
DALP uses one signer interface across local keys, custody providers, and HSM-backed signing. The provider configured for the environment determines where the private-key operation happens and whether a human or policy approval step can delay the transaction.
| Provider mode | Current behavior | Approval behavior | Retry or timeout behaviour |
|---|---|---|---|
| Local | Signs with the configured local signer provider. | No external approval workflow. | Transient signer errors retry with exponential backoff. |
| DFNS provider-native | DFNS signs and broadcasts through its provider flow. | DALP polls DFNS until the provider reports broadcast or confirmation. | The approval poll runs for about 24 hours before timeout. |
| DFNS sign-only approval | DFNS signs but DALP performs broadcast after approval. | The HTTP caller can receive a pending policy marker while the workflow waits durably. | Approval timeout, rejection, or listener setup failure is recorded as an approval failure. |
| Fireblocks | Fireblocks signs and broadcasts through the provider flow. | DALP polls Fireblocks TAP approval status for approved, blocked, or expired outcomes. | The approval poll runs for about 1 hour, matching Fireblocks policy expiry behavior. |
| Luna HSM | Luna signs through a Thales Luna partition. | M-of-N quorum can return a pending approval state until enough approvers activate the partition. | The signer configuration defines the quorum retry window. |
Only DFNS exposes programmatic approval resolution through the signer interface. Fireblocks approval follows TAP policy state. Luna approval follows the HSM quorum flow.
Cancellation and stuck transaction handling
Cancellation depends on the recorded transaction state.
| Transaction state | Behavior |
|---|---|
| Before broadcast | DALP moves the transaction to CANCELLED without an on-chain transaction. |
| During signing | DALP rejects cancellation because nonce allocation and broadcast may already be in flight. If a nonce was recorded, DALP syncs nonce state with the chain before the caller retries cancellation. |
| Broadcast or confirming without a hash | DALP cancels the local record because no on-chain hash exists yet. |
| Broadcast or confirming with a hash | DALP creates a zero-value self-transfer replacement using the same nonce and bumped EIP-1559 fees. |
| Already terminal | DALP rejects cancellation because completed, failed, cancelled, and dead-letter transactions are no longer active. |
Replacement broadcast treats nonce, underpriced, and already-known errors as deterministic. The original transaction may already be confirmed, or the replacement may be too cheap. The caller should retry cancellation so DALP re-estimates fees.
Failure handling
| Failure class | What DALP does | Caller guidance |
|---|---|---|
| Missing target contract code | Stops the transaction before broadcast. | Check the chain ID and contract address. This is terminal for flows that require the contract to already exist. |
| Policy approval denied or expired | Moves the transaction to failed state with an approval sub-status. | Review the provider policy decision, then submit a new transaction if the requested contract call is still valid. |
| Provider or network rate limit | Retries when the signer error is rate-limited, timed out, refused, reset, unavailable, or a 5xx provider response. | Wait for the retry or resubmit only after the original transaction reaches a terminal state. |
| Contract revert | Records a failed transaction with revert context when available. | Fix the contract input or prerequisite state before retrying. |
| Confirmation unavailable | Keeps confirmation checks separate from signing and broadcast. | Use the transaction hash to inspect chain state while DALP continues confirmation monitoring. |
Confirmation and indexer catch-up
After broadcast, DALP starts confirmation monitoring for the chain and checks the transaction receipt. When a confirmed receipt includes a block number, DALP can wait briefly for indexer catch-up as a best-effort step. Integrations should treat transaction confirmation and indexed-data availability as separate signals when they need freshly indexed state.
See also
- Signing Flow for the end-to-end transaction signing sequence across local, DFNS, Fireblocks, and Luna HSM backends
- Custody Providers for DFNS, Fireblocks, and Luna HSM signing responsibilities
- Key Guardian for key storage and signing-provider responsibilities
- Contract Runtime for transaction construction
- Chain Gateway for network access
Key Guardian
The Key Guardian service manages cryptographic key material with defense-in-depth security across local signing, DFNS, Fireblocks, and Luna HSM backends. Secret managers store local keys and Luna authentication material for those supported signer providers.
Contract Runtime
The Contract Runtime provides a secure abstraction for smart contract interactions, managing ABI encoding, call execution, and state queries with automatic retry and error classification.