How to Verify Multi-Party Approval for Tokenized Vault Withdrawals

TL;DR

• Multi-party withdrawal approval means that the required number of eligible approvers authorized a specific withdrawal under the applicable mandate.
• Before funds move, a pre-execution gate must check approver identity, delegation, the approval threshold, the policy version, and any emergency route against the withdrawal details.
• After settlement, an outside reviewer can check signed approvals, the settlement record, and any reviewable policy-evaluation receipt. Signatures establish who agreed. They do not establish that a committed policy produced the decision. Evidence from an enforced path cannot establish the truth of every external input or account for actions outside that path.

What counts as multi-party approval for a vault withdrawal

A vault withdrawal has multi-party approval when the applicable mandate requires a defined number of eligible parties to authorize it before funds move. The mandate should record the approval threshold, the people or roles allowed to approve, and the scope and expiry of any delegated authority. It should also identify when each policy version takes effect and who may use an emergency route.

ERC-4626 (opens in a new tab) defines how a vault withdraws assets or redeems shares. Its caller rules recognize the share owner or a caller with an allowance over the owner’s shares. ERC-7540 (opens in a new tab) adds withdrawal requests and lets a controller or its approved operator claim assets. Neither standard requires multiple approvers. A vault-specific contract or wallet layer must enforce any approval threshold.

Asynchronous withdrawals need rules for approvals that remain pending. ERC-7540 separates the request from the later claim, and it does not standardize request cancellation. The mandate should state whether approval applies at request, claim, or both. It should also say what happens to an in-flight request when an approver’s authority or the policy version changes. Emergency provisions need the same clarity, including which actions an authorized party may take while a request waits.

Authenticating approvers and binding approval to the exact withdrawal

An approval must identify both an eligible signer and the exact withdrawal that signer authorized. Before funds move, the withdrawal gate should verify each signature against the mandate’s approver list, account for revoked or delegated authority, and count distinct eligible signers against the required threshold. A valid signature from a former approver should not count under a newer mandate.

EIP-712 (opens in a new tab) lets an approver sign named withdrawal fields rather than an opaque message. The signed fields should identify the vault, asset, amount or shares, recipient, and mandate version or identifier. If the request authorizes a later claim, the mandate should specify how that approval applies to the claim. Where a request identifier already exists, the signed fields should include it. The EIP-712 domain can bind the signature to a chain and verifying contract, but its domain version does not automatically identify the governing mandate.

Replay protection needs a separate check. EIP-712 does not provide it, so the signed withdrawal should carry a nonce that the withdrawal gate rejects after use. The gate should also reject an approval whose signed mandate version no longer governs the request, unless the mandate expressly permits an in-flight request to proceed under the earlier version.

ERC-7540 (opens in a new tab) provides a separate authority check for asynchronous vault requests. Its controller owns the request, and an approved operator can act on the controller’s behalf. The on-chain controller and operator checks establish who was entitled to make the claim call. They do not establish which approvers signed off on the withdrawal. An outside reviewer therefore needs both the signed approvals and the on-chain request and claim records to test whether the authorized action matched the approved withdrawal.

Comparing the four kinds of withdrawal evidence

These records answer different questions about authorization and enforcement. A reviewer should compare what each records, what can be checked independently, and whether it shows that the mandate constrained the withdrawal before execution.

• Custody multisig and MPC. Custody records show how a withdrawal received signing authorization. An onchain multisig contract can show that its required signing threshold was met. MPC distributes signing across key shares, although the chain may show only one signature. Neither record alone establishes that the business approval mandate was evaluated.
• Operator logs. Logs record the requests, decisions, and timestamps entered in the operator’s systems. A reviewer can compare those entries with withdrawal and settlement records. The logs do not independently establish who controlled an approver account or whether a committed policy produced the decision.
• Signed approval records. Authenticated signatures establish who approved the withdrawal details included in the signed request. Safeheron describes (opens in a new tab) a workflow that includes policy selection, independent approval, signing, broadcast, and reconciliation against an order and ledger. Safeheron distinguishes the approval record of who agreed from the business record of why the request was authorized. Neither record alone proves that committed policy rules produced the approval decision.
• Independently verifiable policy evidence. Inherence’s vault approach (opens in a new tab) enforces the committed mandate before a covered withdrawal executes and produces a receipt that lets an outside reviewer verify the defined approval conditions were met. Where protected strategy or position data is encoded as private proof inputs, the reviewer can verify the receipt without receiving those inputs. Public withdrawal details remain visible. The receipt’s scope depends on the enforced path and evaluated inputs. A separate settlement record must show whether funds moved.

Chainlink’s tokenized-vault explainer (opens in a new tab) covers ERC-4626 mechanics and liquidity remedies. It does not document a multi-party withdrawal-approval capability.

What pre-execution enforcement adds that approval records cannot

An approval record shows that approvers signed a withdrawal request. The signatures alone do not show that the vault checked the applicable mandate before funds moved. Valid signatures do not rule out a withdrawal executed through a route that bypasses a separate policy check.

Pre-execution enforcement makes the mandate a condition of release, much like an escrow instruction. For covered withdrawals, Inherence evaluates the committed mandate before execution. Its enforcement path blocks a withdrawal that fails the defined rules. An allocator can apply that constraint after capital moves to a curator, provided the withdrawal passes through the defined enforcement path.

A withdrawal that passes the gate produces an independently verifiable receipt bound to the covered action and policy version. The receipt lets an outside reviewer check evidence that the committed policy was evaluated without receiving protected inputs encoded in the proof. Approval signatures and the receipt answer different questions. The signatures identify who approved the request. The receipt addresses whether the defined policy governed the covered withdrawal before execution.

Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path. An outside reviewer must therefore examine the source of any external approval or risk input and check settlement separately.

What an outside reviewer can and cannot verify after the fact

An outside reviewer must check approval, policy evaluation, and settlement as separate claims. A withdrawal record may support one claim without establishing the others.

• Approval. Check each signature against the exact withdrawal details and the mandate version in force at the time. Confirm that each signer was eligible, that any delegation was valid, and that the required threshold was met. An operator log can help reconstruct the decision, but the log alone cannot establish that the threshold was enforced before execution.
• Policy evaluation. Verify any receipt against the accepted policy version and verification key. Confirm that the receipt covers this withdrawal and that its verified statement includes the approval threshold. A valid receipt supports only the checks included in that statement. The receipt supports only the policy checks applied to covered actions on that enforcement path.
• Settlement. Match the approved withdrawal and receipt to the transaction that moved the assets. For an asynchronous vault, check both the request and the later claim. ERC-7540 (opens in a new tab) treats those as separate steps, so evidence of a request does not establish that assets were claimed.

The evidence trail stops at its documented boundaries. A receipt does not independently establish whether an external price or oracle input was true. An emergency withdrawal outside the enforced path needs its own authorization and settlement evidence. Actions outside that path do not gain policy-evaluation evidence from receipts for other actions.

The vault due-diligence checklist (opens in a new tab) covers broader operator review. The cumulative-risk guide (opens in a new tab) and hedge guide (opens in a new tab) address adjacent mandate checks.

Conclusion

A diligence standard should require authenticated approvals, policy-evaluation evidence, and settlement records linked to the same withdrawal. The reviewer can then test who approved it, whether the committed mandate governed the covered action before execution, and whether assets moved.

FAQs

Does ERC-4626 or ERC-7540 enforce multi-party approval?

No. ERC-4626 (opens in a new tab) specifies vault withdrawal and redemption functions. ERC-7540 (opens in a new tab) adds request and claim stages, plus controller and operator permissions. Neither standard defines an approval threshold. A vault-specific contract or separate custody control must enforce one.

How is an approval bound to one specific withdrawal?

The approver signs a structured message containing the vault, asset, amount, recipient, mandate version, and a unique nonce. The enforcing application must reject mismatched or reused approvals. EIP-712 (opens in a new tab) supports signatures over structured fields and chain-specific domains, but it does not provide replay protection by itself.

What is the difference between a multisig signature and policy-evaluation evidence?

A transaction executed by a multisig contract can show that its signing threshold was met under that contract’s rules. Policy-evaluation evidence shows whether a defined mandate was checked before execution. A reviewer must inspect the enforced rule and its policy version to determine whether the signature threshold matched the withdrawal mandate.

What can’t an outside reviewer confirm after settlement?

A settlement transaction shows that assets moved. It cannot establish why approvers agreed or whether a price supplied by an external source was accurate. Independently verifiable evidence covers actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path.

How do emergency withdrawal paths fit the mandate?

The mandate must name eligible emergency approvers, the applicable threshold, and the conditions for using the route. An emergency withdrawal needs a record of the mandate version, approvals, policy decision, and settlement. Without a defined and enforced emergency route, an exceptional withdrawal cannot be verified as compliant with the ordinary approval mandate.