Custody Providers
Architecture overview of DALP's custody provider integrations covering browser-wallet verification boundaries, DFNS and Fireblocks MPC signing, Luna HSM partition signing, policy engines, configuration requirements, and the unified signer boundary that keeps DALP signing workflows consistent while provider-specific approval and wallet behavior stays behind the adapter.
DALP separates application-user browser-wallet verification from institutional custody provider integrations. DFNS and Fireblocks provide MPC custody. Luna HSM provides hardware-backed partition signing. Provider approvals stay inside the configured custody or HSM control plane, while DALP uses a common signer boundary for EVM transaction requests.
This explanation answers four custody integration questions:
- Where DALP builds the EVM transaction
- Where the key operation happens
- Which system owns provider policy
- Where the provider user interface, wallet inventory, and approval evidence live
It also lists the configuration inputs your team must provide for local keys, DFNS, Fireblocks, or Luna HSM.
Choose the signing mode
Start with the operational control you need, then map it to a signer model:
| Need | Mode | DALP role | Provider role |
|---|---|---|---|
| Keep signing inside the platform runtime | Local signing | Prepare, sign, broadcast, and track the transaction | No external custody policy decision |
| Let the custody provider submit the transaction | Provider-native broadcast | Record request state, poll provider status, and track the on-chain outcome | Apply policy and own the provider transaction and broadcast path |
| Separate approval from broadcast | Sign-only approval | Prepare the transaction, reserve nonce, broadcast the signed transaction, and track lifecycle | Release the signature after provider policy approval or Luna quorum activation |
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.
Use this setup checklist before issuing, minting, burning, transferring, or deploying assets through an external signer.
Read this checklist with:
- Signing Flow for the transaction sequence.
- Mint replay, idempotency, and supply controls for retry semantics.
- Supported Networks for EVM network scope.
For tokenization actions that may reach the signer, see Create asset, Mint assets, and Burn assets.
| Setup question | Required decision | Operational effect |
|---|---|---|
| Which wallets can sign DALP transactions? | Map the DALP wallet reference to the active signer's wallet, vault wallet, or hardware-backed key label. | DALP routes the transaction to the configured signer. The external control plane owns the key material and approval decision. |
| Which transactions should auto-sign? | 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. |
| Which transactions need approval? | 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. |
| What rejects everything else? | 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. |
| Which rule wins when more than one matches? | 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. |
| Where is approval evidence reviewed? | Use the active signer's audit logs, policy history, approval history, or hardware partition logs for provider-side decisions. | 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:
- 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.
- 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.
- 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.
- 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 provider in the signer configuration: local, dfns, fireblocks, or luna. The platform can keep configuration blocks for the supported providers, but the active signer.provider value is the runtime boundary used by the signer loader for that deployment. 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:
| Review question | DALP answer | Provider or HSM answer |
|---|---|---|
| Who builds the regulated asset transaction? | 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. |
| Who approves the key operation? | 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. |
| Where is custody evidence reviewed? | 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. |
| Can DALP clear a provider hold? | 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 boundary
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.
| Boundary question | DALP owns | Provider or customer owns |
|---|---|---|
| Which transaction should be signed? | Transaction intent, tenant scope, EVM target, calldata, value, request idempotency, and platform transaction state | Provider policy rules that decide whether the key operation may proceed |
| Which key or wallet is used? | The configured wallet reference passed to the active signer adapter | Wallet creation, vault hierarchy, custody workspace structure, HSM key labels, and provider-side wallet lifecycle |
| How is approval collected? | Polling or resuming 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 |
| Where is approval evidence exported? | DALP transaction records, request 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 |
| How are operator accounts managed? | DALP 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 |
Use this boundary 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
| Capability | Local signer | DFNS | Fireblocks | Luna HSM |
|---|---|---|---|---|
| Custody model | Tenant-scoped local EVM key material | Threshold MPC | MPC-CMP with continuous key refresh | Thales Luna 7 HSM partition signing |
| Policy engine | DALP platform controls | DFNS Policy Engine | Transaction Authorization Policy (TAP) | HSM quorum controls |
| Mobile approval | No external approval app | No | Yes (Fireblocks app) | No DALP-managed mobile approval path |
| Provider policy decision flow | No provider-owned decision flow | Provider-owned status flow | Console / Co-Signer only | Out-of-band quorum activation |
| API model | Local signer interface | REST API | REST API | PKCS#11 library integration |
| Wallet model | DALP wallet key reference | Flat wallet list | Vault account hierarchy | HSM key labels scoped by organization/wallet |
| DALP signing use | Development or controlled operator setups | Configured EVM wallets | Fireblocks vault wallets for EVM transactions | Hardware-backed EVM signing |
Fit and responsibility matrix
| Signer model | Native or configuration path | Typical integration effort | Customer responsibility |
|---|---|---|---|
| Local | Built-in signer provider selected by configuration | Low. Configure the local signer and wallet key reference. | Decide whether local signing is acceptable for the environment and protect the key material accordingly. |
| DFNS | Built-in custody adapter using DFNS API credentials and organization settings | Medium. Configure DFNS service credentials, wallets, policies, and network support. | Own DFNS workspace policy, approval users, wallet lifecycle, and provider audit evidence. |
| Fireblocks | Built-in custody adapter using Fireblocks API credentials and vault wallets | Medium. Configure Fireblocks API access, vault accounts, asset wallets, TAP rules, and Co-Signer or console approval operations. | Own Fireblocks vault design, TAP policy, approvers, Co-Signer operations, and provider audit evidence. |
| Luna HSM | Built-in HSM adapter using a PKCS#11 library, token label, and secret-backed partition PIN reference | Higher. Install and operate the Luna client stack, configure partition access, provide secret references, and validate quorum operations. | Own HSM partition lifecycle, M-of-N quorum process, PIN/certificate handling, hardware availability, and HSM audit evidence. |
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.
| Setting | Description |
|---|---|
| API URL | DFNS service endpoint |
| Organization ID | Tenant identifier |
| Auth token | Service account authentication |
| Credential ID | Identifies the signing credential |
| EC private key | API authentication key for the DFNS service account |
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 boundary
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.
| Setting | Description |
|---|---|
| API key | From the Fireblocks Console |
| RSA private key | PEM format, for API authentication |
| API endpoint | Production or sandbox URL (auto-detected) |
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.
| Setting | Description |
|---|---|
| PKCS#11 library | Local library path used to communicate with the Luna module |
| Token label | HSM partition label; blank labels are rejected at config load |
| PIN reference | Secret reference for the partition Crypto User PIN |
| Client cert/key | Optional secret references for client certificate material |
| Quorum retry | Window used while waiting for M-of-N quorum activation |
| Operation timeout | Per-operation timeout for blocking PKCS#11 calls |
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.
| Approval type | Who owns the decision | What DALP records | What the operator must do |
|---|---|---|---|
| Provider policy approval | DFNS policy, Fireblocks TAP, or the Luna HSM quorum process | The platform transaction remains pending while DALP polls or resumes the provider-specific signing path. | Complete, reject, or investigate the approval in the provider or HSM control plane. |
| Smart-wallet multisig approval | DALP smart-wallet co-signers | The transaction can enter DALP's pending-approval state before UserOperation submission. | Use the DALP smart-wallet approval flow for the required co-signers. |
| User-session wallet verification | DALP request controls | The request is accepted only after the configured PIN, one-time password, or recovery-code check passes. | Provide the required wallet-verification evidence before the signing request starts. |
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.
| Mode | Who owns nonce, gas, and broadcast | Who owns approval or key policy | Used by |
|---|---|---|---|
| DALP-managed sign and broadcast | DALP prepares the transaction, coordinates nonce and gas, signs, and broadcasts through the configured EVM network connection. | DALP platform controls and the configured local key-management tier. | Local signing |
| Provider-native broadcast | DFNS or Fireblocks prepares the provider transaction, handles provider-side nonce and gas, signs, broadcasts, and returns a provider transaction id or hash. | The custody provider evaluates its policy before or during the provider broadcast. DALP polls for the provider outcome. | DFNS and Fireblocks when provider network support is used |
| Sign-only approval | DALP prepares the transaction, reserves the nonce, receives the signed transaction, and broadcasts through the configured EVM network connection. | The provider or HSM control plane approves the key operation before releasing the signature. DALP owns EVM broadcast and confirmation. | Luna HSM and DFNS configurations that sign without provider broadcast |
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
| Mode | Immediate caller outcome | Follow-up path |
|---|---|---|
| DALP-managed sign and broadcast | The request returns the platform transaction result after DALP signs and broadcasts, or a terminal error if signing or broadcast fails. | Poll the DALP transaction status when the client used an asynchronous workflow. |
| Provider-native broadcast | The request can return a pending provider result while DFNS or Fireblocks evaluates policy, signs, broadcasts, or confirms the provider transaction. | DALP polls the active provider adapter and records the provider transaction identifier, final transaction hash, or provider failure. |
| Sign-only approval | The request can return an accepted pending-policy result while DFNS approval or Luna quorum activation is still in progress. | DALP resumes after the provider or HSM releases the signature, then broadcasts through the configured EVM network connection. |
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:
| Tier | Protection | Use case |
|---|---|---|
| Encrypted database | Application-level encryption | Development and low-value assets |
| Cloud secret manager | Platform-managed encryption | Standard production deployments |
| Hardware security module (Luna HSM) | Partition-backed PKCS#11 signing with quorum activation | Regulated financial services that keep keys inside an HSM |
| Third-party custody (DFNS / Fireblocks) | Delegated institutional MPC | Provider-managed custody policy and external approval flows |
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
- DFNS developer documentation
- Fireblocks developer documentation
- Thales Luna HSM documentation
Integration overview
Overview of DALP's integration architecture covering documented provider surfaces and configurable project-specific integrations across custody, compliance, networks, market data, storage, secrets, payments, wallets, ERP, and security controls.
Compliance Providers
Architecture reference for compliance-provider intake across identity, business, AML, and wallet-monitoring providers. Explains how provider events become tenant-scoped on-chain claims and where per-transfer decisions belong instead.