Keep signing inside your own custody
Sign through your own custody provider while DALP prepares, broadcasts, and tracks every transaction to confirmation, with keys that never leave the vault.
DALP 3.0 supports external custody providers for transaction signing. The platform prepares and tracks the transaction; the selected provider holds the key and applies its signing policy. Local signing remains an alternative for deployments that accept platform-managed keys.
Your custody provider's vault signs; DALP builds the request, routes it there, and tracks it to confirmation.
External custody providers sign transactions under their own policies. DALP prepares the request and tracks its outcome. Local signing uses platform-managed keys.
- Providers
- Five, one model
- Keys
- Never leave the vault
- Approvals
- Quorum and manual
- Separation
- By construction
Choose the custody model before creating wallets. External providers and local signing place key custody in different systems.
Custody models
External providers can use a hardware security module, multi-party computation, or a managed signing service. Review each provider's key management and approval configuration. Local signing stores key material under platform management.
DALP 3.0 supports local signing, DFNS, Fireblocks, Ripple Custody, and Luna HSM. The asset APIs use a shared provider interface, while each provider defines its supported capabilities.
What the integration contract looks like
Every integration implements the same interface: a named provider, wallet management, and a signing path. Where the provider supports it, approval listing and resolution are part of the same contract. DALP uses only that surface. The request goes in, the signed bytes come back, and the provider's own vault executes the operation according to whatever key management and approval policy it enforces internally.
A common interface connects the platform to each provider. Changing providers does not move existing keys or remove the organization's custody constraints. Check the custody configuration before creating a wallet.
Provider capabilities determine signing, broadcast, and approval behavior. The platform tracks the outcome through the shared transaction lifecycle.
How the signing separation works
- 1Prepare
DALP constructs the transaction, applies its own authorization and idempotency controls, and builds the signing request. No key material is needed at this stage.
- 2Sign
The signing request routes to your configured custody provider. Signing happens inside the provider's vault, under its own approval policy. Keys never leave.
- 3Broadcast
DALP submits the signed transaction to the network (or the provider does, depending on the integration). Nonce management stays in the platform to prevent conflicts.
- 4Track
DALP follows every transaction through to on-chain confirmation, manages resubmission if needed, and surfaces final state through the Platform API (DALP's REST interface) and Workflow Engine (the durable process that carries a multi-step operation to completion).
The strict separation between those stages is what makes this model meaningful, not an implementation detail. When DALP constructs a payload but cannot sign it, the custody provider's own approval policy is the enforcing layer, not an advisory one the platform could bypass. A quorum rule, a manual sign-off requirement, or a travel-rule check configured inside the vault applies to every request, regardless of how it enters the signing queue.
With external custody, the platform sends a signing request to the configured provider and receives its result. The provider retains the key. With local signing, the platform manages the key and performs the signing operation.
Review the custody boundary
For external custody, review the provider credentials, permitted signing operations, and approval rules alongside platform access. A platform compromise can still send requests to the provider, so key isolation alone does not establish that every request is authorized.
Supported custody providers
Each integration covers the full path for that provider's wallet and approval model: signing, broadcasting, nonce management, and approval polling. The asset and workflow surface remains the same across all of them.
Platform-managed key material. Use when the deployment accepts in-process signing and no external provider is required.
MPC custody with DFNS policy controls. The signing request routes to a DFNS wallet; DFNS enforces its own approval rules before returning the signature.
MPC custody with Fireblocks Transaction Authorization Policy. TAP rules run server-side at Fireblocks; DALP waits for policy resolution before the transaction continues.
Institutional custody with Ripple Custody approval workflows. DALP routes requests through the Ripple Custody API and resumes on approval.
Hardware partition signing via PKCS#11. The Luna HSM supports M-of-N quorum policies: a configured number of authorized parties must approve before the partition releases the signature. Signing happens inside the Luna partition; the signed bytes return to DALP for broadcast.
Quorum and manual approval flows
When a provider policy requires approval, DALP tracks the pending decision. It holds the workflow in a pending state, tracking the provider's approval status, continuing after approval, and surfacing that pending state through the Platform API so your operations team can monitor it.
What an approver sees
An approval is only as good as what the reviewer can see. DALP now hands your custody console a decoded, human-readable description of each request: the operation and its key arguments, not a bare 32-byte hash. In DFNS and Fireblocks, the reviewer reads the operation in plain terms inside their own tool and signs against intent they can verify and later defend to an auditor, rather than rubber-stamping an opaque payload.
This matters beyond UX. A signed approval over a human-readable payload is a stronger audit artefact than a signature over an opaque hash. When an auditor asks what the approver authorized, the answer is in the record, not reconstructed from surrounding context.
Screen and fund before the chain
For DFNS deployments, DALP 3.0 adds two controls between the platform's authorization step and the vault. A flagged transaction is stopped at the screening layer; gas accounting is visible prior to broadcast, not reconciled after the fact.
Provision an organization-level screening policy, Chainalysis or GlobalLedger, that runs on every signing request. A flagged transaction is blocked before signing, never broadcast, and not caught afterward on-chain.
Read the live native-gas balance of a managed custody wallet through the Platform API and CLI, and route gas through a DFNS fee-sponsor wallet, with no separate gas-refill scheduler to run.
Availability
The provider-neutral model is generally available in DALP 3.0. Local signing, DFNS, Fireblocks, and Luna HSM are fully documented. Ripple Custody (Metaco) requires a pre-configured API credential; contact your integration team for the setup checklist.
No migration is required if you used an earlier DALP signing path. The signer adapter model is backward-compatible.
External signing keeps the key operation with the selected custodian. Local signing remains available when the deployment accepts platform-managed keys.
Compliance templates
Package a compliance policy (identity, jurisdictions, supply caps, approvals) once and apply it to every asset in a program, enforced at every transfer.
Advanced accounts
ERC-4337 smart wallets and a system paymaster remove the native-token balance requirement, so on-chain work runs under enforced role boundaries.