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

Choosing a crypto custody provider requires more than confirming that it uses multi-party computation, or MPC. Finance and security teams need to establish who can authorize a transaction, what evidence the provider produces, and whether balances and attestations can be verified without relying on a dashboard screenshot.

The strongest selection process tests four separate areas: transaction control, wallet ownership, asset and liability reporting, and independent assurance. These controls answer different questions and should not be treated as interchangeable.

Start with the custody and approval model

MPC divides the cryptographic process required to sign a transaction among multiple parties or devices. No single party needs to reconstruct the complete private key. However, MPC does not automatically provide dual approval.

A provider may use MPC internally while still allowing one authorized user to initiate and approve a transfer. For effective dual control MPC, the policy layer must require at least two independent approvals before the signing quorum can complete a transaction.

Ask vendors to demonstrate the full approval path using a test transaction. One employee should create the payment, another should approve it, and the system should reject attempts to bypass the second approver. Test changes to allowlists and approval policies as well as payments; an administrator who can quietly weaken a policy may be able to defeat dual control.

For each policy, document:

• Required approvers and signing quorum.
• Per-transaction and daily limits.
• Network, asset and destination allowlists.
• Cooling-off periods for new addresses.
• Who can change policies and how those changes are approved.
• Recovery procedures if an approver or provider is unavailable.

Companies that prefer direct control can also compare custody against a self-custodial USDC business account using MPC vaults and quorum signing. The key comparison is not the label but which parties can ultimately authorize an onchain transfer.

Define what the attestation must prove

An attestation is a statement about assets or controls at a specified time. A programmatically verifiable attestation should be available through an attestation API, signed file or both. It should contain enough structured data for your systems to verify the statement independently.

At minimum, request these fields:

• A unique report or attestation ID.
• Wallet addresses, networks, assets and token contract addresses.
• Block number or block hash used for each balance.
• Observation time and report-generation time, preferably in UTC.
• Balance units and token decimal conventions.
• Scope, exclusions and whether assets are segregated or pooled.
• Reported customer liabilities and the calculation method.
• Signer identity, signature algorithm and public-key reference.
• Independent assurance provider and report date, where applicable.

A JSON response delivered over HTTPS is not inherently trustworthy. It becomes independently testable when the payload is digitally signed and the public verification key is obtained through a separate, authenticated channel.

How to verify a signed attestation

1. Validate the digital signature

Obtain the provider's public key from a documented source rather than from the same API response. Confirm the signature algorithm, canonical serialization rules and key version. Canonicalization matters because different spacing or field ordering can produce a different message hash even when the visible data is equivalent.

Your verification process should reject an attestation if the signature is invalid, the key has been revoked, the key ID is unknown, or required fields are missing. Retain the original payload, signature, public-key fingerprint and verification result in the treasury evidence pack.

2. Prove wallet ownership or control

Seeing a balance at an address does not prove that the custodian controls it. Request evidence such as a signed challenge message, a pre-agreed onchain transaction, or another chain-specific ownership proof.

A signed challenge should include your company name, a random nonce and an expiry time to prevent reuse. Verify the signature against the claimed address where the network supports it. For smart-contract wallets, validation may require contract-specific signature logic rather than a standard externally owned account signature.

3. Recalculate onchain balances

Use an independent node or blockchain data provider to query each address at the disclosed block. Verify the token contract, network and decimal precision; a ticker such as USDC or USDT is not sufficient because unrelated tokens can use the same symbol.

Set a confirmation policy for each chain. The attestation should identify a block that your policy considers final enough for reporting, rather than simply using the latest observed block. Record both the block number and hash so a later chain reorganization can be detected.

These checks are sometimes described as onchain audits, but they establish only what selected addresses held at a particular block. They do not establish ownership rights, undisclosed borrowing, offchain assets or the completeness of customer liabilities.

4. Test liabilities coverage

Proof of reserves compares disclosed assets with some measure of customer obligations. The basic coverage calculation is:

reserve coverage = eligible verified assets ÷ included customer liabilities

A ratio of at least 1.00 only has meaning if the liability population is complete and the assets are available to meet those liabilities. Ask whether the calculation excludes pending withdrawals, negative customer balances, pledged collateral, borrowed assets or affiliated-party positions.

If liabilities are represented through a Merkle tree, customers should be able to verify that their balance is included without seeing other customers' balances. This proves inclusion, not completeness: an operator could omit accounts unless an independent party validates the full source ledger and reconciliation process.

Proof of reserves is not a financial audit

A full financial audit considers a broader set of records, assertions and accounting policies. Proof of reserves is narrower and usually point-in-time. Review the exact wording of any independent assurance report: identify the responsible entity, procedures performed, reporting period, exceptions, and whether the practitioner expresses an opinion or only reports agreed-upon procedures.

Evaluate audit logs and API operations

The custody platform should produce immutable or tamper-evident records for transaction creation, approvals, rejections, policy changes, user administration, API-key changes and recovery events. Each record should include the actor, timestamp, action, affected object and before-and-after values where relevant.

For APIs, test authentication, permission scopes, pagination, rate limits, idempotency and webhook retries. A read-only attestation credential should not be able to initiate payments. Confirm how long records remain available and whether complete exports can be generated for auditors.

Freshness also matters. Define an internal threshold appropriate to your reporting cycle—for example, rejecting a daily treasury attestation if its observation time is more than 24 hours old. This is your policy, not a substitute for understanding how frequently the provider updates its data.

A practical vendor test

Before signing a contract, run a controlled proof of concept:

• Create a low-value transaction and confirm two independent approvals are enforced.
• Attempt to exceed a limit and send to a non-allowlisted address.
• Change an approval policy and inspect the resulting audit records.
• Download an attestation and verify its signature offline.
• Prove control of at least one disclosed wallet.
• Recalculate balances at the stated blocks through an independent data source.
• Reconcile your balance to the liability proof.
• Review the scope and date of independent assurance.
• Export the evidence in a format your finance and audit teams can retain.

Finally, put evidence requirements into the service agreement: reporting frequency, delivery format, retention period, incident notification and access to historical attestations. For implementation questions covering treasury workflows and evidence exports, finance teams can consult the Stablerail help centre.

The best custody decision is based on demonstrable authority and reproducible evidence. Dual approval should be enforced rather than merely documented, and every reserve claim should be tied to signed data, identified wallets, specific blocks, scoped liabilities and clearly described independent assurance.