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.
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.
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.
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:
Each path covers signing, broadcasting, nonce handling and approval polling for that provider's model. The asset surface stays identical across them.
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.
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.
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.
Want to discuss how custody and signing fit your digital asset program?
Book a call with our team ↗
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.