Custody provider integration for tokenization platforms

DALP custody provider integrations route EVM signing requests through one configured signer model while the custody provider keeps control of keys, vaults, approvals, and provider-side evidence. DALP builds or records the platform transaction request, applies its own authorization and idempotency controls, sends the signing request to the active signer, and tracks the on-chain outcome after signing or provider broadcast.

Use this hub to design four custody decisions:

• where signing happens;
• which custody policy approves the key operation;
• how pending approvals resume;
• which evidence belongs in DALP versus the external custody or HSM control plane.

The current documented signer backends are local signing, DFNS, Fireblocks, and Luna HSM. Smart-wallet multisig is a separate DALP approval mode for UserOperation approvals.

The integration decision is operational before it is technical:

• choose local signing only when the deployment accepts platform-managed key material;
• choose DFNS or Fireblocks when MPC custody and provider policy should control the key operation;
• choose Luna HSM when signing must happen inside a hardware partition;
• use smart-wallet multisig approvals for DALP smart-wallet operations, not as a replacement for custody-provider policy.

Related pages: Signing flow, Supported networks, Transaction signer, Operator wallets, Account abstraction control center, Compliance and security, Operational integration patterns, and Runbooks.

Support levels at a glance

DALP supports custody providers at the signer-adapter layer. DALP keeps transaction construction, authorization, idempotency, and on-chain tracking in the platform workflow. The signer adapter routes the key operation to the configured backend.

The named options on this page are the current documented signer options. Treat any other custodian name as an integration question.

Before claiming DALP support, validate:

• provider model;
• wallet model;
• approval flow;
• network coverage.

Use this table to answer provider-support questions before reading the provider-specific sections.

DALP can route and track supported EVM signing requests through the current signer modes listed here. DALP does not replace a provider console, custody-policy engine, vault operating model, or HSM operating process.

Choose the signing mode

Start with the operational control you need, then map it to a signer model:

Local signing is the simplest operational model. DFNS and Fireblocks can use provider-native broadcast when the provider supports the selected EVM network. DFNS can also run as sign-only approval for networks where DALP must broadcast the signed transaction. Luna HSM uses sign-only approval because the HSM signs inside the partition and DALP sends the signed transaction to the configured EVM network.

Use this quick check before selecting a provider configuration:

• If the institution accepts platform-managed signing and broadcast, select local signing and keep the key-management decision inside the DALP deployment controls.
• If the custody provider must submit the transaction from its own control plane, use provider-native broadcast and make sure the selected provider supports the target EVM network for that wallet.
• If the provider or HSM must approve and sign but DALP must broadcast, use sign-only approval. Keep the client request idempotent so a pending approval can resume without creating a duplicate transaction.
• If the approval is a smart-wallet multisig approval, use the smart-wallet approval flow. Custody-provider approvals and Luna quorum activation do not use those endpoints.

Policy setup before tokenization

Before tokenization actions use an external signer, configure provider policy for every expected signing intent. A missing policy path is not a DALP bypass.

The provider or hardware control plane holds the key operation until an approver, rule, or quorum allows it.

DALP keeps the platform request pending or returns a conflict that the caller can retry with the same idempotency key.

Before issuing, minting, burning, transferring, or deploying assets through an external signer, configure the custody policy and wallet mapping that the signer needs.

Read this section with Signing Flow for the transaction sequence, Mint replay, idempotency, and supply controls for retry semantics, and Supported Networks for EVM network scope. For tokenization actions that may reach the signer, see Create asset, Mint assets, and Burn assets.

The setup has six operating decisions:

• Map each DALP wallet reference to the active signer's wallet, vault wallet, or hardware-backed key label. The external control plane owns the key material and approval decision.
• Define the lowest-risk DALP intents that may pass provider policy without manual approval. DALP can receive a signed transaction or provider transaction id immediately and continue the platform workflow.
• Add provider policy rules for higher-risk tokenization actions, amount thresholds, destination restrictions, or quorum requirements. DALP observes the pending provider state and waits, polls, or asks the caller to retry after approval.
• Keep a catch-all denial or manual-review rule in the provider policy. Unknown or misrouted signing intents stop in the provider control plane instead of silently signing.
• Order provider rules so the most specific deny or approval rule takes precedence over broader allow rules. Operators can explain why a request signed, waited, or failed during audit review.
• Review provider-side decisions in the active signer's audit logs, policy history, approval history, or hardware partition logs. DALP records platform request state, transaction identifiers, and on-chain outcome, but provider approval evidence stays with the provider.

For sign-only approval, a provider hold is a resumable transaction state. DALP reserves the nonce, starts the configured approval monitor, and surfaces CUSTODY_APPROVAL_PENDING when the caller must wait. After the external control plane approves, retry the same business request with the same idempotency key or let the workflow recovery path resume. Do not submit a new tokenization action just because provider approval is pending.

For provider-native broadcast, the active signer owns nonce, gas, signing, and broadcast. DALP records the provider transaction id, polls for the EVM transaction hash where available, and tracks the on-chain outcome after the provider broadcasts.

Signing responsibility model

DALP keeps transaction construction and custody policy as separate responsibilities:

1. DALP builds the EVM transaction intent. Platform workflows resolve the sender wallet, target contract, calldata, value, tenant scope, and request state before signing. DALP handles nonce and gas for local and sign-only paths; provider-native DFNS and Fireblocks broadcasts let the provider handle nonce, gas, signing, and broadcast.
2. The configured signer provider performs the key operation. The signer can use a local key, DFNS, Fireblocks, or Luna HSM. Provider configuration chooses the backend; the platform workflow stays the same.
3. The provider or HSM control plane owns approval policy. DFNS policy, Fireblocks TAP, or Luna quorum activation can pause signing until the external control plane allows the operation.
4. DALP resumes and tracks the platform transaction. After the provider returns a signed transaction or provider-native broadcast status, DALP records the transaction state and follows the on-chain outcome.

The custody split lets a bank map its custody model without assuming that DALP stores every private key. DALP stores provider configuration and workflow state. Provider-side approval history remains in the custody or HSM system of record.

A DALP deployment selects one active signer mode for the transaction workflow. The deployment can keep provider setup material for supported providers, but one signer mode handles a given platform signing path. Mixing DFNS, Fireblocks, and Luna as parallel active signers in one deployment is not the public operating model.

What DALP manages, and what stays with the provider

DALP manages the platform-side transaction workflow: request authorization, transaction construction, compliance simulation, signer routing, idempotent workflow state, broadcast when DALP owns broadcast, and final transaction tracking.

The custody provider or HSM manages the custody control plane: wallet or vault organization, key-policy approval, approver assignment, provider mobile or console actions, quorum activation, and provider audit evidence. DALP can poll and reflect the provider outcome. It does not replace DFNS policy administration, Fireblocks TAP administration, Fireblocks Console or Co-Signer approval, or Luna partition operations.

Use the split this way during architecture review:

• DALP builds or records the EVM transaction request in the platform workflow. The provider may own nonce, gas, and broadcast only in provider-native broadcast mode.
• DALP routes the request to the configured signer and records the returned status. DFNS policy, Fireblocks TAP, or Luna quorum decides whether the key operation can proceed.
• DALP records request state, signer route, transaction identifiers, and on-chain outcome. Provider approval logs, wallet lifecycle, vault design, and HSM partition evidence stay in the provider or HSM control plane.
• DALP can resume polling or retry the platform request with the same idempotency key. The provider or HSM operator must approve, reject, unblock, or activate the key operation outside DALP.

Provider audit logs, custody approval policy, and smart-wallet multisig approval collection stay outside this reference. Use the provider control plane for provider-side approval evidence. Use the Signing Flow for the full transaction sequence.

Custody user interface responsibilities

DALP does not replace the custody provider console, mobile approval app, vault dashboard, or HSM operator process. DALP routes signing requests to the configured signer, records the platform transaction state, and polls the provider where the adapter exposes status. Provider-side user management, approval rules, vault organization, quorum ceremonies, and provider audit exports stay in the provider or HSM control plane.

DALP owns the transaction intent, tenant scope, EVM target, calldata, value, request idempotency, and platform transaction state. The provider policy decides whether the key operation may proceed.

DALP passes a configured wallet reference to the active signer adapter. The provider or customer owns wallet creation, vault hierarchy, custody workspace structure, HSM key labels, and provider-side wallet lifecycle.

DALP polls or resumes the platform workflow when the adapter reports pending, approved, denied, expired, or blocked provider status. Fireblocks console or Co-Signer approval, DFNS policy approval, or Luna HSM quorum activation happens in the external control plane.

DALP records transaction metadata, provider transaction identifiers, and on-chain outcome tracking. Provider audit logs, policy decision history, custody-user actions, HSM partition logs, and regulator-ready custody evidence packs stay with the provider or customer.

DALP manages application users, API keys, roles, wallet-verification checks, and smart-wallet signer records. Custody-provider users, approvers, API clients, mobile devices, HSM operators, and provider access policy stay in the provider control plane.

Use this split when answering wallet-provider questions. A client portal or wallet provider can integrate with DALP through the public API and indexed events. DALP does not publish a generic wallet-provider marketplace or manage an external provider's account UI. Custody-provider UI remains the place to operate provider wallets, approvers, vaults, and HSM ceremonies.

Browser-wallet verification

Browser wallets serve application-user onboarding and transaction-verification flows.

For wallet transactions that use the DAPI signing gate, DALP verifies the operator with a configured PIN, one-time password, or confirmed recovery secret code.

Account passkeys remain separate from this wallet-verification gate.

Browser-wallet verification remains a platform-managed authorization step.

DFNS and Fireblocks provide provider-managed custody, wallet organization, and policy approval flows for higher-control signing setups.

Provider comparison

Fit and responsibility matrix

DFNS and Fireblocks use MPC signing so that no single private key ever exists in one place.

Luna HSM signs inside a configured hardware partition. Luna can surface pending approval while M-of-N quorum activation completes.

Custody provider support does not change DALP network compatibility. DALP signing workflows target the EVM-compatible networks documented in Supported Networks.

The fundamental difference is operational.

Custody providers own their policy or quorum decision flows.

DALP's signer contract uses pending, approved, denied, expired, or blocked status vocabulary.

Each provider adapter exposes the subset that provider can observe.

DFNS integration

DFNS provides delegated MPC custody where key shards distribute across DFNS infrastructure. DALP connects through a service account with the following configuration. The API authentication key identifies that service account, separate from DFNS-managed wallet key material.

Policy enforcement

The DFNS policy engine evaluates transaction rules before MPC signing proceeds. Policies support auto-sign rules, amount thresholds, IP/time restrictions, and multi-party approval requirements. When a DFNS policy requires approval, DFNS owns the decision flow; DALP signer approval surfaces use the canonical pending, approved, denied, or expired statuses, while provider-native broadcast failure, provider denial, or polling timeout are treated as errors rather than extra status strings.

Audit responsibilities

DALP records its own signing workflow state, transaction identifiers, provider status, and operator activity. DFNS keeps the provider audit trail for custody-policy decisions in the DFNS control plane. Treat the two records as complementary evidence: DALP shows how the platform routed and observed the request, while DFNS remains the source for provider-side approval history.

Fireblocks integration

Fireblocks provides institutional MPC-CMP custody through vault accounts. Wallet key material distributes across Fireblocks infrastructure and the customer's co-signer node. Continuous key refresh eliminates static key shares. The RSA private key in DALP configuration authenticates the Fireblocks API client, not the vault wallet private key.

Vault-based wallet model

Fireblocks organizes keys into vault accounts, each containing one or more asset wallets. DALP supports creating vault accounts, activating asset wallets, and querying vaults across the organization.

Transaction authorization policy (TAP)

Fireblocks enforces custodian-level policies through TAP rules that evaluate before signing. Rules cover transaction amount thresholds, whitelisted destination addresses, velocity limits, and multi-approver requirements.

When a TAP rule blocks a transaction, DALP can reflect a pending or blocked provider status while polling Fireblocks for the provider outcome. Fireblocks does not support programmatic approval resolution through external APIs, so blocked transactions must be approved through the Fireblocks Console or a Co-Signer appliance; DALP then reflects approved or denied provider results, while provider expiry and polling timeout are treated as error paths instead of extra status literals.

Luna HSM integration

Luna HSM support uses a configured Thales Luna 7 partition for hardware-backed EVM signing. DALP loads the Luna signer through the same signer configuration surface as the other providers, but the Luna adapter requires a PKCS#11 library path, a non-empty token label, and a secret reference for the partition PIN. Optional client certificate and key references can also be supplied through the secrets backend.

Quorum and pending approval

Luna signing runs in sign-only approval mode. When the partition is waiting for M-of-N quorum activation, DALP records a provider pending state and keeps polling until the signing attempt succeeds, expires, or is classified as blocked. The approval is completed out of band through the Luna control process; DALP does not provide a browser or API approval button for the HSM quorum itself.

Signer approval and polling behavior

Custody-provider approval is separate from DALP smart-wallet multisig approval.

Provider approvals and smart-wallet approvals are not interchangeable. A Fireblocks TAP hold, DFNS policy hold, or Luna quorum wait cannot be cleared through DALP smart-wallet multisig endpoints. A smart-wallet multisig request does not approve provider custody policy.

Synchronous API callers can receive an accepted asynchronous response while provider approval is pending. Poll the transaction status until DALP records a transaction hash, a terminal provider outcome, or a failed platform transaction.

Broadcast modes

DALP supports three signing and broadcast patterns behind the same transaction workflow. Choose the mode by deciding which system should own nonce, gas, signing, broadcast, and provider approval for the request.

Across these modes DALP keeps the caller-facing transaction lifecycle consistent: queued, prepared, approval or signing work, broadcast, confirmation, and final outcome. The difference is whether DALP or the provider owns nonce, gas, and broadcast handling for that request.

Execution outcomes by mode

A pending provider or HSM result means the key operation is waiting outside DALP. It does not mean the request moved into the DALP smart-wallet multisig approval flow.

Choosing a signing mode

Use provider-native broadcast when the custody provider supports the target EVM network and the institution wants the custody control plane to own nonce, gas, signing, and broadcast as one provider transaction. DALP records the provider transaction identifier, polls the signer adapter, and follows the final on-chain outcome.

Use sign-only approval when the custody or HSM control plane should approve and sign but DALP must still own EVM broadcast. This is the normal Luna HSM model. It also applies to DFNS configurations where the provider can sign for a network but does not own broadcast for that request.

Use DALP-managed sign and broadcast when the signer is local and there is no external custody policy decision flow. That mode keeps nonce, gas, signing, and broadcast inside DALP's platform workflow.

If a provider-native broadcast returns pending, DALP keeps the transaction in the broadcast workflow. DALP polls the active signer adapter for provider status. DALP does not persist the smart-wallet pending approval transaction state for DFNS or Fireblocks custody-policy decisions.

DFNS broadcast polling treats broadcast or confirmation as approval. Provider failure, denial, and polling timeout are treated as errors rather than extra status strings.

Fireblocks polling checks pending or blocked approval status until the provider reports approval or denial. Provider expiry and polling timeout are treated as error paths rather than recorded as status literals.

Luna polling tracks HSM quorum activation until the partition signs, the request expires, or DALP classifies the pending state as blocked.

Smart-wallet multisig approvals use DALP's smart-wallet approval endpoints for UserOperation approval collection. Those endpoints do not approve or reject custody-provider policy decisions or Luna HSM quorum activation.

System setup and batch requests

For DFNS sign-only or nonce-reservation paths, approval-pending conflicts can pause setup operations that register token factories or add-on factories. DALP surfaces those approval-pending cases as retryable HTTP 409 conflicts for the setup request instead of converting the batch into a permanent validation failure.

Fireblocks setup requests do not use the same setup-conflict marker. Fireblocks follows its own pending-approval polling contract, so clients should not expect a retryable HTTP 409 setup-request conflict for Fireblocks TAP approval.

Safe setup retries require the client to send an Idempotency-Key header on the original request and reuse the same value on retry. If the client omits the header, DALP generates a per-request key for server-side tracking, but that generated value is not returned to the caller for later reuse. After the DFNS approval or nonce reservation clears, retry the same request with the original client-provided key so DALP resumes from the tracked transaction state rather than creating a duplicate setup operation.

Unified signer abstraction

The unified signer interface abstracts over the configured custody backend. For DALP consumers, signing requests follow the same platform workflow while provider-specific approval and wallet behavior remains behind the signer adapter.

This abstraction means:

• Platform workflows call the signer interface without knowing which provider handles the request
• Adding a new provider requires implementing the signer adapter, not changing platform flows
• Provider-specific behavior, such as approval model differences and vault hierarchies, stays behind the adapter

See the Signing Flow for the complete end-to-end sequence showing how the signer interface delegates to the active provider.

Storage tiers

Custody providers represent the highest tier in DALP's key storage hierarchy. Organizations select the appropriate tier based on asset value and regulatory requirements:

Luna HSM belongs to the hardware security module tier, not the third-party custody tier. DFNS and Fireblocks keep custody policy in the provider control plane, while Luna keeps signing inside the configured HSM partition. Luna quorum activation is completed out of band through the HSM control process, not through DALP smart-wallet multisig endpoints.

Each tier escalates protection. DALP routes signing requests to the appropriate backend based on key metadata, and the Signing Flow shows where that backend-specific signing step fits in the transaction sequence.

Related

• Signing Flow for the end-to-end transaction signing sequence
• Supported Networks for EVM network compatibility
• Authentication for API-level security controls
• Operator Wallets for platform wallet balance checks
• Account Abstraction Control Center for bundled and sponsored transaction infrastructure
• DFNS developer documentation
• Fireblocks developer documentation
• Thales Luna HSM documentation