How to Evaluate Custodians With Dual-Control MPC and Verifiable Attestations

Start with authority, not the MPC label

Multi-party computation divides the cryptographic process required to sign a transaction among multiple parties, devices or services. The full private key does not need to be reconstructed in one place. That can reduce key-compromise risk, but it does not automatically create dual control.

A provider may use MPC behind the scenes while allowing one customer administrator to create and approve a transfer. It may also retain a recovery path that lets the provider move assets without the customer’s normal approval flow. Finance teams therefore need to distinguish the cryptographic signing quorum from the business approval policy.

Effective dual-control MPC requires at least two independent approvals before the signing quorum can complete a transaction. The same principle should protect destination allowlists, transaction limits, user roles, recovery settings and approval-policy changes. Otherwise, a privileged administrator could weaken the policy before initiating a payment.

Ask the vendor to demonstrate the complete path with a low-value test transaction. One employee should create it, another should approve it, and the platform should reject attempts to bypass the second approver. Repeat the test for a new destination, a limit increase and a role change.

Document the required approvers, signing threshold, per-transaction and aggregate limits, supported networks, permitted assets, destination allowlists, cooling-off periods and recovery process. Record who can change each rule and whether the change itself needs independent approval.

The deciding factor is not whether the product is called custody, a vault or an MPC account. It is which parties can ultimately authorize an onchain transfer. Companies considering direct operational control can also compare custody with a stablecoin business account such as Stablerail, which supports approvals and signing quorum, sanctions and address screening before send, global payouts, fiat off-ramp and exportable audit evidence.

Define exactly what an attestation must prove

An attestation is a statement about assets, liabilities or controls at a specified time. A dashboard balance is not an independently verifiable attestation. A stronger design provides a signed file, an attestation API or both, with enough structured data for the customer to reproduce the relevant checks.

At minimum, request a unique attestation ID; wallet addresses; networks; assets and token contract addresses; block numbers and hashes; observation and generation times in UTC; balance units and decimal conventions; scope and exclusions; segregation or pooling status; included liabilities and their calculation method; signer identity; signature algorithm; key identifier; and the date and scope of any independent assurance.

A JSON response delivered over HTTPS is not independently trustworthy merely because it came from an authenticated endpoint. It becomes independently testable when the payload is digitally signed and the verification key is obtained through a separate authenticated source.

1. Validate the digital signature

Obtain the provider’s public key or certificate from documented material rather than trusting a key embedded in the same API response. Confirm the signature algorithm, key ID, key version and canonical serialization method. Canonicalization is important because changes in field ordering, whitespace or number formatting can alter the message hash.

The verifier should reject the payload when the signature is invalid, a required field is absent, the key is unknown or revoked, or the attestation falls outside the accepted reporting window. Retain the original payload, signature, verification key fingerprint, verification software version and result in the period’s treasury evidence pack.

2. Prove wallet ownership or control

Finding assets at a disclosed address does not prove that the custodian controls the address or that the assets belong to the customer population. Request a signed challenge, a pre-agreed onchain transaction or another chain-specific proof of control.

A challenge should contain the customer’s legal name, a random nonce, the relevant address and an expiry time so it cannot be reused. Verify the signature against the claimed address where the network supports that method. Smart-contract wallets may require contract-specific validation rather than the signature procedure used for an externally owned account.

If the custodian uses omnibus wallets and will not disclose every address, require a clear explanation of the allocation ledger, reconciliation process, legal ownership structure and controls governing transfers between omnibus, settlement and operational wallets.

3. Recalculate balances independently

Query each disclosed address using an independent node or blockchain data provider at the stated block. Verify the network, token contract and decimal precision. A ticker such as USDC or USDT is insufficient because unrelated contracts can use the same symbol.

Set a confirmation or finality policy appropriate to each network. Record both the block number and block hash so the process can identify a later reorganization. Also define how bridged assets, wrapped tokens, staking positions or unsupported networks are treated in the calculation.

These procedures are sometimes described as onchain audits, but they prove only that selected addresses held specific assets at a particular block. They do not establish legal ownership, freedom from liens, completeness of the address population, offchain assets or customer liabilities.

4. Test reserve coverage and liabilities

The basic calculation is reserve coverage = eligible verified assets divided by included customer liabilities. A result of at least 1.00 is meaningful only when the liability population is complete and the assets are available to satisfy those obligations.

Ask whether pending withdrawals, negative customer balances, borrowed assets, pledged collateral, affiliated-party positions or assets in transit are included. Review how the provider handles cut-off differences between the customer ledger and onchain observation time.

A Merkle-tree liability proof can let a customer verify that its balance was included without exposing other customers’ balances. That proves inclusion, not completeness. The operator could omit accounts unless an independent party validates the full source ledger, population and reconciliation process.

Do not treat proof of reserves as a financial audit

Review the exact wording of independent work. Identify the responsible legal entity, procedures performed, reporting date or period, exceptions, subservice organizations and whether the practitioner expresses an opinion or reports only agreed-upon procedures. Confirm that the entity and product covered are the ones your company will actually use.

Evaluate logs, APIs and recovery operations

The platform should produce tamper-evident records for transaction creation, approval, rejection and execution, as well as policy changes, user administration, API-key changes, wallet recovery and failed access attempts. Each event should identify the actor, timestamp, affected object and before-and-after values where relevant.

Test whether logs use a consistent time standard and whether exports preserve stable event IDs. Confirm retention periods and the ability to export complete records without screenshots or manual copying. Treasury, security and internal audit should be able to reconcile a transaction from request through approval, signing, broadcast and final onchain status.

For APIs, test authentication, permission scopes, key rotation, pagination, idempotency, rate-limit behavior and webhook retries. A read-only attestation credential must not be able to create payments or modify policies. Webhooks should expose unique event identifiers so your systems can recognize duplicates instead of processing the same event twice.

Define internal freshness rules. For example, a daily close process may reject an attestation once its observation time exceeds the company’s approved reporting window. This is a customer control, not a substitute for understanding the provider’s actual update frequency and incident procedures.

Run a controlled vendor proof of concept

Complete the following tests before contract approval and retain the results:

1. Create a low-value transaction and confirm that two independent approvals are technically enforced.
2. Attempt to exceed a limit and send to a destination that is not allowlisted.
3. Change an approval rule, role and allowlist entry; inspect who approved each change and what the audit log retained.
4. Download an attestation, validate its signature offline and test rejection with an altered payload.
5. Prove control of at least one disclosed wallet using a fresh challenge or agreed onchain action.
6. Recalculate token balances at the stated blocks through an independent source.
7. Reconcile the company’s balance to the liability proof and investigate cut-off differences.
8. Review recovery steps for a lost approver, unavailable provider or compromised administrator.
9. Export the complete evidence package in a format finance and auditors can retain.

Convert every material claim into a test, document or contract term. A strong custodian evaluation does not rely on an MPC label, a dashboard reserve ratio or a single assurance report. It establishes who can move assets, how that authority can change, whether reported balances and liabilities can be independently checked, and whether the resulting evidence supports treasury close, audit and incident response.