For any regulated institution, custody is one of the first checks before a digital asset platform can move near production. The institution already has a custody model. The platform must respect it.
In practice that means a hard line: the platform can prepare the transaction, apply business logic and track the result, but the power to sign has to remain inside the custody setup the institution has already approved. Keys do not migrate into the platform so the platform can act.
DALP 3.0 is built around that separation. Signing stays inside your own custody provider or vault. DALP constructs the transaction, routes it to the configured signer, broadcasts it once signed, and tracks it through to confirmation. Key material never moves into the platform.
That model works across supported signing and custody setups, including Ripple Custody, Fireblocks, DFNS, Luna HSM and local signing. The asset lifecycle does not need to be redesigned around a specific provider.
Why institutions refuse to hand over keys
Most regulated institutions have already chosen MPC, an HSM, or a managed custody service. The reasons mix risk policy, regulatory mandate, prior investment and audit requirements. A digital asset platform that keeps its own copy of key material forces a second custody decision on top of the first. The institution then carries two custody risks instead of one: its own, and the platform's.
Many regulatory regimes that touch digital asset custody treat signing authority as a control that must sit with the custodian. The lifecycle system should not be able to produce a valid transfer on its own. When keys and business logic live in the same system, a platform incident becomes a custody incident as well.
For risk and audit teams, the distinction that matters is between a promise and a design. A promise says the platform will not use the keys. A design means the platform cannot sign because it does not hold key material. DALP 3.0 is built on the second reading.
How signing separation works in DALP 3.0
The path is the same shape for every supported provider.
DALP prepares the transaction first. It applies authorization and idempotency controls, then builds the signing request. No key material is needed at this stage.
The request is routed to the configured custody provider. Signing happens inside that provider's vault, under that provider's approval policy. Keys stay where they are.
Once signed, DALP submits the transaction to the network, or the provider does, depending on the integration. Nonce management stays in the platform so parallel work does not collide. DALP then tracks the transaction through to on-chain confirmation, handles resubmission when needed, and surfaces final state through the Platform API and Workflow Engine.
Because the platform never receives the keys, it also cannot bypass the vault. Quorum rules, manual sign-off and travel-rule checks configured inside the custody provider are enforced before a signature returns. They are not optional platform steps an operator can skip.
The product design is described in the DALP 3.0 custody and signing documentation.
One integration model across custody providers
Each integration implements the same contract: a named provider, wallet management and a signing path. Where the provider supports it, approval listing and resolution belong to the same contract. DALP uses that surface and nothing deeper. The request goes in; signed bytes come back; the vault executes under its own key-management and approval rules.
The platform layer does not need to know whether it is speaking to a hardware partition, an MPC cluster or a managed API with its own access controls. Provider changes stay in configuration. Asset definitions and workflows stay put.
Supported paths in DALP 3.0 include:
- Local signing, for deployments that accept in-process signing and do not require an external vault
- DFNS, with DFNS policy controls on each signing request
- Fireblocks, with Transaction Authorization Policy evaluation on the Fireblocks side while DALP waits for resolution
- Ripple Custody (Metaco), using Ripple Custody approval workflows and resume-on-approval behavior
- Luna HSM, with PKCS#11 partition signing and M-of-N quorum policies inside the hardware boundary
Each path covers signing, broadcasting, nonce handling and approval polling for that provider's model. The asset surface stays identical across them.
Approvals operators can actually defend
When a provider policy needs a quorum or a manual sign-off, DALP does not drop the transaction or fail quietly. That behavior holds across the supported custody paths. The workflow sits in a pending state while the provider says yes or no. Ops can watch that pending state through the Platform API. Broadcast resumes when approval completes.
Each provider keeps its own approval machine. Fireblocks evaluates Transaction Authorization Policy rules on the Fireblocks side while DALP waits for resolution. DFNS applies DFNS policy controls before it returns a signature. Ripple Custody runs its approval workflows and DALP resumes once approval lands. Luna HSM enforces M-of-N quorum inside the hardware partition over PKCS#11. Local signing is available when the deployment accepts in-process keys and no external vault is required. In every case the vault (or the local signer) owns the decision; DALP does not substitute its own approval in place of the provider's.
What the reviewer sees also matters. Where the integration supports it, including DFNS and Fireblocks today, DALP can hand the custody console a decoded, readable description of the request: the operation and its main arguments, not a bare hash. Approvers sign against intent they can read in their own tool. That signed record is a stronger audit artifact than a signature over opaque bytes reconstructed after the fact.
Some paths add controls in front of the vault as well. On DFNS deployments, for example, an organization-level AML/KYT screening policy via Chainalysis or GlobalLedger can block a flagged request before signing. Gas balances on managed custody wallets can be read through the Platform API and CLI, and gas can be routed through a DFNS fee-sponsor wallet without a separate refill scheduler. Other providers keep equivalent screening and funding decisions inside their own operating model; DALP routes to them under the same prepare-sign-broadcast-track contract.
Operators can act without holding native gas
Custody is only half of the daily pain. On most chains, every operator who needs to execute also has to hold and top up the chain's native token. Multiply that by operators and networks and you get a gas custody problem sitting next to the signing problem.
DALP 3.0 separates those as well. Operators can act through smart accounts while the platform sponsors gas under rules you set. The operator does not need a funded native balance on each network to perform asset operations. Sponsorship is conditional: role, permitted work, gas ceiling and expiry are checked before coverage is granted. The compliance system can resolve the smart wallet and the associated signing key to one identity before checks fire, so controls attach to the right party rather than to a bare hot key.
That advanced-accounts model is built on ERC-4337 and is covered separately in the advanced accounts documentation. Together with external custody signing, it gives institutions two controls they usually ask for at once: vaults keep the keys, operators keep doing work without each one running gas logistics.
Who this is for
Banks, issuers, market infrastructure teams and public-sector institutions all hit the same question during due diligence: if we adopt this platform, do we keep control of signing authority, or does the platform absorb it?
DALP 3.0 answers that on architecture, not on policy language. Custody remains where it already is. Authority stays under institutional control. The platform owns preparation, routing, broadcast and confirmation around that boundary. Local signing, DFNS, Fireblocks and Luna HSM are documented today. Ripple Custody needs a pre-configured API credential; the integration team has the setup checklist. Earlier DALP signing paths do not require a migration. The signer adapter model stays backward compatible.
To place this in the wider release, visit the DALP platform overview or read the DALP 3.0 custody and signing documentation. Architect-level detail is in the custody provider integrations and signing flow pages.
Frequently asked questions
DALP constructs the transaction, routes the signing request to the configured custody provider, broadcasts the signed transaction, and tracks it to confirmation. The custody provider performs the signature inside its own vault. Key material never moves into DALP.
The provider-neutral model covers local signing, DFNS, Fireblocks, Ripple Custody (Metaco) and Luna HSM. Asset lifecycle behaviour and the API surface stay the same across those paths. Provider changes stay in configuration.
Yes. The vault enforces its own rules before a signature is returned. Quorum policies, manual sign-off and travel-rule checks configured in the provider apply to every request. DALP cannot bypass them because it cannot produce a valid signature on its own.
DALP holds the workflow in a pending state, tracks the provider's approval status, and resumes broadcast once the decision completes. That pending state is visible through the Platform API for operations teams.
Yes. Operators can act through smart accounts while the platform sponsors gas under controlled rules. That model is based on ERC-4337 and is detailed in the advanced accounts documentation. Operators do not each need to hold and manage native gas balances to complete asset work.
No. Earlier DALP signing paths remain compatible. The signer adapter model is backward-compatible, so existing deployments do not need a forced migration to use the provider-neutral path.
Want to discuss how custody and signing fit your digital asset program?
Book a call with our team ↗
About SettleMint
SettleMint, headquartered in Leuven, Belgium, with offices in UAE, Singapore and Japan is the company behind DALP, the entirely composable Digital Asset Lifecycle Platform. DALP enables financial institutions, market infrastructure operators, and governments to build, deploy, and manage digital assets and blockchain applications at scale.
