Custody Approval
Custody Approval lets you require a decision from your own approvers before a key signs, enforced by the party holding the key, not the platform.
The approval decides on one prepared payload, and the signature that follows covers that payload and nothing else.
One approval covers one exact payload: sender, destination, call, amount, and sequence number (the wallet's own per-transaction ordering counter). Change any one and the approval lapses.
The key holder enforces the decision, not the platform: the custody system, hardware module, or wallet contract will not sign what the policy has not cleared.
A waiting transaction is a visible state with four exits: approved, declined, expired, or cancelled.
Why a signature needs a decision first
Custody Approval lets you require a decision from your own named approvers before a key signs a payload. That decision belongs to people your organization chose, under a policy your organization set.
Banks already run this maker-checkerMaker-checker keeps a single mistaken instruction or a single compromised account from moving money, filing a report, or approving a corporate action alone.Read the concept discipline, the rule that the person who prepares a payment cannot be the one who authorizes it, over payment instructions. Custody Approval moves the same discipline onto the step where a private key turns an instruction into an irreversible on-chain transfer. A conventional payment can sometimes be reversed after it leaves the bank. A signed on-chain transfer cannot: once it is broadcast, nothing undoes it.
The platform enforces this control from the requesting side, not the signing side. It resolves the sender, builds the call, and asks the key holder to sign, and on every custody path it never holds the key material. The approval policy lives with the party that holds the key instead: a custody provider, a hardware security module (HSM) in your own data center, or the wallet contract itself on chain. The platform cannot obtain a signature that policy has not cleared. A control review checks first whether the platform could bypass this decision, and here it cannot.
For a financial institution, this is what lets signature release pass that review. The organization reuses a discipline it already runs for payments, and it names its own approvers or its own signer threshold. That gets it the record an auditor expects around an irreversible movement of assets: who prepared the instruction, who cleared it, and when.
Custody Approval is not tied to one stage of a tokenized instrument's Asset Lifecycle. It gates a signature wherever one is needed across that life, from a wallet's first funding to a service-stage payout years later.
Approval limits who can authorize a signature
An approval policy requires a decision beyond the instruction itself. A request subject to that policy waits for the configured approvers before signing can proceed. Role permissions still govern who may submit the request.
The approval is bounded in two ways. It authorizes one prepared payload, not a standing mandate, so it grants no ongoing permission to move assets. It is also not a settlement guarantee: the signed transaction still has to reach the chain and still has to satisfy the asset's own transfer restrictions, a separate control described under Transfer-Path ComplianceTransfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.Read the concept.
Working a pending approval
Day to day, Custody Approval is a queue. A transaction that meets an approval rule stops in a pending-approval state, appears in the organization's work queue with the operation it is waiting to perform, and moves nowhere until someone decides. The platform records the pending state. A multi-signature approval can already contain signatures while it waits for the remaining weight.
Where the decision is taken depends on the wallet. On a platform multi-signature wallet, the approval is a record you work inside the platform. It shows the weight required, the weight collected (each signer holds a weightMultisig lets a tenant put a wallet under several signers, weighted so authority follows who must actually agree, before any of them can act alone.Read the concept, a share of signing authority counted toward the wallet's threshold), and every signature so far, and each signer co-signs from the pending item. On a wallet held at a custody provider or inside a hardware security module, the platform shows the transaction as waiting, and the decision belongs to the provider's own console, approval app, or hardware quorum ceremony.
Your approvers do not read raw transaction bytes. Where the provider supports it, the approval screen names the operation and its arguments, decoded from the same prepared call the approver is authorizing. It therefore cannot describe something the payload does not do, and an undecodable call falls back to the contract and the function selector.
A pending approval ends in exactly one of four ways. An approver approves it and the key holder releases the signature. An approver declines it, and the platform records a failure with a rejected-signature reason. Nobody decides in time, and the platform records a failure with an expired-approval reason. Or someone withdraws the request: a transaction still waiting has never been broadcast, so cancelling takes effect at once. A decline or a lapse is an outcome, not an error to retry blindly: nothing reopens a declined, expired, or cancelled approval, so prepare and submit a fresh instruction if the movement is still needed.
A prepared transaction either signs directly or waits for a decision. Approved work continues to broadcast and confirmation; a decline, a lapse, or a withdrawal is a recorded end.
One habit matters more than any other: do not resubmit the instruction while it waits. The platform is holding that wallet's next sequence number for the payload under review, so a second submission could queue a second movement of assets rather than hurry the first. Follow the original operation's status or let the platform's own recovery resume it. Repeat an API request only when its route documents replay safety.
Plan the wait in. Another write from the same wallet cannot take that wallet's sequence number while an approval is pending, so it waits for the slot before giving up. That ceiling is up to 24 hours, shortened to about an hour when the custody provider's own approval window is tighter than that. A slow approver therefore delays that wallet's other work. Route routine high-volume work and approval-bearing work through different wallets when both have to keep moving.
Where the boundary sits
Custody Approval is a gate on signature release, and the platform sits on the requesting side of it. The platform resolves the sender, builds the call, reserves the sequence number, simulates the asset's compliance rules, and then asks the key holder to sign. An external custody policy decides provider-side approvals. A weighted wallet enforces its own signature threshold. Platform-managed signing has a different trust boundary.
Two approval planes exist, and neither substitutes for the other. The custody-provider plane gates one external signature: the provider's policy engine or the hardware module's quorum holds the key operation until a rule, an approver, or a quorum of key custodians clears it. On the multi-signature wallet plane the approval is the signature, because several signers each contribute weight to one operation. The threshold is enforced by the wallet contract itself. It validates the collected weight when the operation reaches the chain and rejects an operation whose weight falls short, so the platform holding submission is convenience rather than the control. A provider hold does not clear through the wallet's approval calls, and a wallet threshold does not stand in for provider policy. Use that split to place a new rule. One that is naturally a threshold over the platform's own signers belongs on the wallet plane, where the contract enforces it on chain. One that needs a named individual, an external amount or destination check, or a hardware quorum belongs on the provider plane, where its policy engine or the module enforces it.
The split, plane by plane:
| What differs | Custody provider or hardware module | Multi-signature wallet |
|---|---|---|
| What is approved | Release of one signature over the prepared payload. | Each signer's own signature over the operation. |
| Who enforces | The provider's policy engine or the module's quorum. | The wallet contract's validation rules, on chain. |
| Where the decision is taken | The provider console, approval app, or hardware ceremony. | The platform, as a co-signing step in the work queue. |
| Rule shape | Amount limits, destination rules, named approvers, a quorum of key custodians. | Per-signer weights against a threshold. |
| Where the evidence lives | The provider's or module's own audit log. | The approval record and the chain. |
| Key material | Never leaves the provider or the module. | Each signer holds their own key. |
An approval binds to one payload, and the platform checks that binding instead of trusting it. Where the provider signs but the platform broadcasts, the platform parses the returned signed bytes and compares them against the prepared request. A difference in any one of the six fields below stops the transaction before broadcast, and the platform releases that wallet's reserved sequence number the same way it would for a declined or expired approval. An approval is therefore permission to sign one specific payload, not permission to broadcast whatever bytes come back.
The six fields that must match:
- Sequence number
- Destination address
- Call data
- Chain identifier
- Native value
- The recovered signer address
The platform trusts no provider notification on its own. An inbound message announcing an approval must carry the provider's signature over the raw bytes, and even then it only wakes the waiting workflow: the platform reads the provider's status endpoint for the authoritative answer.
The sequence-number reservation makes the payload binding hold over human time. The prepared payload fixes a specific next sequence number for the sending wallet, and an approval can take hours. The platform keeps that slot reserved throughout, so a concurrent write waits instead of consuming the number and invalidating the approved payload. A decline, a lapse, or a cancellation releases the reservation.
The integration contract
On the platform application programming interface (API), Custody Approval appears in two shapes that match the two control planes. A provider-side hold is a state that a write can enter. A multi-signature approval is an object that you create, read, and sign until its policy reaches a decision.
A write that meets a provider policy does not fail. It stays in flight and reports a pending-approval state whose reason names a pending custody approval. Treat that as a wait, and let recovery resume the work when the provider clears it. The queue deduplicates a matching submission under the same key, but the API route may do work before queue admission. A rule that blocks rather than asks is different: it fails the transaction outright, and no approver decision reopens it. Fix what the rule objects to, such as the amount or the destination, and submit a new instruction; retrying the same one fails again against the same rule.
A multi-signature approval is a first-class record on the wallet. You create one by sending the operation's call data, and optionally the operation hash you expect. The call data must be executable by the wallet, because the platform simulates it to build the operation; a call the wallet reverts on is refused with DALP-9522. Creating it needs a wallet that already has a configured multisig threshold and an installed signer-weight validator; without either, creation is refused with DALP-9522 or DALP-0176. The platform builds a preview from the request and rejects a supplied hash that differs from the computed hash. If you omit the hash, the response returns the computed value. It stores that preview, which fixes the sequence number, the gas limits, the fees, and the call data, and it records the initiator's signature at once. Every signature after that, each co-signer's, is taken over the operation hash recomputed from the same stored preview, so no signer is asked to sign terms that drifted.
A co-signer who signs in the instant after creation can hit a narrow startup window. The initiator's request was accepted, but the platform has not finished setting up the approval's signature-collection workflow, so it is not yet visible to sign against. That call fails with DALP-0181. Retry it after a short backoff and it succeeds once the workflow finishes starting.
Reading the record gives you the required weight, the weight collected, the call data, an optional deadline, and every collected signature with its signer, the weight it added, and when. A co-signer signs with an empty body: the platform resolves the caller's signing address, checks that the caller is an active signer on the wallet, then adds that weight once. Signing against a user operation hash that matches no approval record fails with DALP-0181 instead of creating one implicitly.
Create the approval, collect co-signatures until the weight meets the threshold, then read the terminal status rather than inferring one.
Read the approval's status rather than inferring one. It stays pending while more weight is needed, turns submitted once the threshold is met and the operation goes out, then reaches executed on success. An approval that runs past its deadline ends expired; trouble in submission or execution ends it failed; and an approval closed before the threshold ends cancelled. Submitted is not executed: the operation is still on its way, and its own outcome is recorded as a Settlement Verdict. A sign call against an expired or no-longer-pending approval fails instead of reopening it, so a stale client cannot revive a decision that has already expired, failed, or been cancelled.
Controls and evidence
For a control function, Custody Approval is a preventive control at the point of signature release: an unapproved payload is never signed, so there is no unauthorized transaction to detect, reverse, or explain. The party holding the key enforces the decision before signing, so the platform is not the single point of trust for this control.
Keep it separate from transfer compliance, because the two answer different questions and both must pass. Transfer compliance decides whether an address, a claim, or a movement is permitted under the asset's own rules, and it is enforced on chain when the transfer executes. Custody Approval decides whether the key may sign the prepared transaction at all. An approval creates no eligibility claim and overrides no transfer restriction: an approved transfer that fails the asset's rules still reverts on chain.
Evidence is split by design, and an audit needs both pieces. The platform holds the request record: what was requested, by whom, when it entered pending approval, how long it waited, the terminal outcome with its reason, and the resulting on-chain transaction. The custody provider or hardware module holds the other piece: which approvers the policy named, who decided, and when. On the multi-signature wallet plane both pieces sit on the platform and on the chain, because the approval record names each signer, their weight, and their signing time, and the wallet contract enforced the threshold in public.
Two design points settle most control reviews. Approval policy lives in the provider or in the wallet, so a platform administrator cannot widen it. And the platform cannot sign around a gap in it, because the key operation always waits for the key holder's answer and the platform can never supply one of its own. What happens when no rule matches is therefore decided by the provider's default, not by the platform. Configure a catch-all deny or manual-review rule, so nothing is left to that default.
Frequently asked questions
Which happens first, the compliance check or the approval?
The compliance check. The platform simulates the asset's transfer rules against the prepared transaction before it asks anyone to approve, so an operation the asset would reject never reaches your approvers and never spends their attention. Those rules then run again for real when the transaction executes on chain, which is what catches an eligibility change that landed while the approval was pending.
Who are the approvers?
Whoever your policy names, and the policy is yours. On a custody provider, the approvers are the people and rules configured in that provider's own policy engine: named individuals, amount thresholds, destination restrictions, or a required quorum. On a hardware security module, they are the key custodians who must jointly activate the partition. On a platform multi-signature wallet, they are the signers on that wallet, each carrying a weight you set. The platform appoints approvers in none of these models.
Can we run both approval planes at once?
Yes. Clearing one plane never clears the other, because each is a separate authority: the wallet contract enforces its threshold on chain regardless of what the provider decided, and the provider's policy engine runs regardless of the wallet's collected signer weight. A movement that needs both keeps waiting until each has cleared on its own timeline, so the slower plane sets the pace for the whole request.
Does the platform hold our keys?
Only if you choose that model. With a custody provider or a hardware security module, the key material never leaves the provider or the module; the platform holds provider configuration and workflow state. A local signing mode exists for development and for deployments that accept platform-managed key material. That path has no external custody policy engine. Select it only when platform-managed key storage meets your deployment's signing requirements.
Can a platform administrator bypass the approval?
An external custody provider enforces its configured policy before releasing a signature. A weighted Smart Wallet checks its installed validators on chain. Review those controls and who can change them. Platform-managed key storage does not provide the same external approval boundary.
How long can an approval stay open?
On a platform multi-signature approval the deadline is optional: set one when you create the approval, or leave it open and the approval waits until the threshold is met or someone closes it. Whichever plane is waiting, the wait is durable, so a restart on either side does not lose a pending approval or the signatures already collected toward it.
Custody Provider
A Custody Provider decides who signs for an organization's accounts, a managed custodian or the holder's own wallet, without changing accounts or approvals.
Maker-checker
Maker-checker keeps a single mistaken instruction or a single compromised account from moving money, filing a report, or approving a corporate action alone.