Keep signing inside your own custody

Sign through your own custody provider while we prepare, broadcast, and track every transaction to confirmation. The keys never leave your vault.

Custody & Signing

Your vault signs. We do everything else.

A regulated deployment cannot hand keys to a platform to act on them. In DALP 3.0, it does not have to. Your custody provider signs each transaction inside its own vault. DALP constructs the request, routes it to the configured signer, and owns the full lifecycle from submission to final confirmation.

Providers

Five, one model

Keys

Never leave the vault

Approvals

Quorum and manual

Separation

By construction

The question a custody team asks is not whether a platform can sign. The real question is whether their vault signs while the platform handles everything else. The answer, in 3.0, is yes.

The custody problem

Most regulated institutions already have a custody decision. They chose MPC, an HSM, or a managed custody service for good reasons: risk policy, regulatory mandate, existing investment, or audit requirements. The question is whether their tokenization platform forces them to revisit that decision.

The two dominant approaches address different risks. An HSM is a physical cryptographic device: a tamper-resistant appliance that stores keys in hardware and performs signing inside a certified boundary. HSMs are well understood by auditors and regulators: the key never leaves the chip, and tamper detection erases material if the device is breached. MPC takes a different approach. It distributes a signing operation across multiple parties so that no single device or party ever holds a complete private key. A quorum must participate for any signature to be produced. HSM is about physical isolation; MPC is about eliminating single points of failure across parties or geographies.

Both are valid, and both are supported. The point is that the choice belongs to the institution, not to the platform. When a platform holds its own copy of key material to operate, it forces that choice back onto itself. The institution then carries two custody risks instead of one: its own, and the platform's.

One provider-neutral integration model covers local signing, DFNS, Fireblocks, Ripple Custody (Metaco), and Luna HSM. The asset lifecycle and the API surface look the same across all of them.

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.

Nothing in the platform layer needs to know whether it is speaking to a hardware partition, an MPC cluster, or a managed API with its own access controls. That abstraction is not just a code convenience. As an architectural guarantee, it means a regulated institution can swap providers without the change surfacing anywhere in their asset or workflow configuration.

Keeping that model consistent across integrations took deliberate work. Each had to cover signing, broadcasting, nonce management, and approval-state polling. The asset and workflow surface stays identical throughout. A provider change touches configuration, not code.

How the signing separation works

1. 1
   Prepare

   DALP constructs the transaction, applies its own authorization and idempotency controls, and builds the signing request. No key material is needed at this stage.

2. 2
   Sign

   The signing request routes to your configured custody provider. Signing happens inside the provider's vault, under its own approval policy. Keys never leave.

3. 3
   Broadcast

   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.

4. 4
   Track

   DALP follows every transaction through to on-chain confirmation, manages resubmission if needed, and surfaces final state through the Platform API and Workflow Engine.

The strict boundary 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.

In practice, DALP never holds key material. It builds the transaction payload, packages the signing request, and hands that to the configured provider. The vault performs the cryptographic operation in isolation: whether that is an MPC service, a hardware security module accessed over PKCS#11, or a managed API with its own access controls. The signed bytes return to the platform for broadcast. At no point can DALP produce a valid signature on its own, which means no code path, and no operator, can bypass the vault's authorization logic.

Why it matters for a regulated deployment

For a regulated institution, where keys live is not a preference. Key custody is a control. Most regulatory frameworks governing digital asset custody (from MiCAR to state trust charters) require that signing authority reside with the custodian and that the asset lifecycle system cannot unilaterally produce a valid transaction. When a system holds keys alongside business logic, those two requirements are in tension: any deployment or access-control failure becomes a custody failure as well.

The DALP model eliminates that tension by construction. The platform never holds key material, so a platform-layer incident cannot produce an unauthorized transfer. The provider's own authorization rules, including quorum, policy controls, and travel-rule checks, are enforced before the signature is returned, not as a step the platform is trusted to invoke. If an auditor, regulator, or board-level governance committee asks "who can initiate a transfer without going through the vault?", the answer is no one.

For a risk officer reviewing this architecture, the question is whether the separation is enforced by construction or by policy. A policy boundary ("the platform promises not to use the keys") is not an audit primitive. A design boundary ("the platform cannot sign because it does not hold key material") is. That is the model DALP uses.

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.

Quorum and manual approval flows

When a provider policy requires a quorum or a manual sign-off, DALP does not time out or drop the transaction. It holds the workflow in a pending state, tracking the provider's approval status, resuming broadcast the moment the decision completes, 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.

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.

This design reflects one conviction: a platform that handles transaction construction, full lifecycle tracking, and compliance enforcement can do all of that without ever holding a key. We handle everything up to the vault boundary and everything after it. We do not cross it.

Connect a custody provider → · Signing flow architecture →