How to Evaluate Dual-Control MPC Custody and Verifiable Attestations

For a corporate treasury, custody due diligence should answer two separate questions: who can move the assets, and how can finance verify that the assets exist? Multi-party computation, or MPC, can distribute signing authority, but MPC alone does not guarantee dual approval. Likewise, a published wallet balance does not establish that a custodian can meet all customer liabilities.

A credible evaluation therefore needs to cover transaction policies, wallet ownership, onchain balances, liability reporting, signed data, audit logs and independent assurance. This guide explains how to test those capabilities without treating proof of reserves as a substitute for a financial audit.

Start with the custody model

The word “custody” covers materially different arrangements. Identify who controls the cryptographic keys, whether assets are segregated, and whether the provider can move funds without your company’s approval.

Stablerail uses self-custodial MPC vaults with quorum signing for corporate USDC and USDT treasury operations. Approval limits, destination allowlists, wallet screening and an audit log support the operating workflow. When comparing this model with a third-party custodian, confirm which controls are cryptographically enforced and which depend on the provider’s internal procedures.

What dual control MPC should mean

Dual control MPC should require at least two independent approvals before a transaction can be signed or released. Ask the vendor to demonstrate the policy rather than relying on the product label.

• Quorum: Is the rule 2-of-3, 3-of-5 or another threshold? Can one administrator quietly reduce it?
• Separation of roles: Can the person who creates a payment also approve it? Are policy changes subject to a separate quorum?
• Approval scope: Does the policy cover transfers, swaps, new wallet addresses, smart-contract interactions and recovery events?
• Limits: Can approval requirements vary by amount, asset, network, destination or time period?
• Failure handling: What happens if a signer leaves, loses a device or becomes unavailable?

Request a controlled test. Create a payment, attempt release with one approver, add the required second approval, and export the resulting event log. Repeat the exercise for a policy change and recovery request. This reveals whether dual approval protects only routine payments or also the administrative paths that could bypass them.

Requirements for a verifiable attestation

A PDF statement is useful for filing, but it is not automatically machine-verifiable. An attestation API or downloadable signed record should return enough information for your treasury system to reproduce the verification independently.

At minimum, each record should contain:

• A unique attestation ID and schema version.
• The legal entity and account or vault identifier.
• Asset, token contract, network and wallet addresses.
• Raw token quantities and their decimal precision.
• Block number or slot, block hash and observation timestamp.
• Liability amount, if the claim includes customer coverage.
• Any excluded, pledged, borrowed or encumbered assets.
• The signing algorithm, signer identity, key ID and digital signature.
• A link to the applicable methodology and independent assurance report.

Prefer an API that supports historical snapshots rather than returning only the latest value. Historical records let finance reproduce month-end evidence even if wallets or balances subsequently change.

How to validate the signed data

1. Verify the attestation signature

Obtain the provider’s public verification key through a trusted channel. Check its fingerprint, owner, validity period and revocation process. Your verifier should serialize the attestation exactly as specified, calculate the required hash, and validate the signature using the declared algorithm.

Reject an attestation if the signature fails, the key is expired or revoked, the schema is unsupported, or required fields are missing. Also test key rotation: a new key should be announced through an authenticated channel, not merely included in the payload it signs.

2. Establish wallet ownership or control

A wallet address is not evidence of ownership by itself. The provider can prove control by signing a fresh challenge containing your nonce, entity identifier and expiry time, or by sending a specified transaction from the wallet.

MPC and smart-contract wallets may not support ordinary message signatures in the same way as a single-key wallet. In that case, validate the wallet contract, signer set or onchain transaction defined by the provider’s methodology. For omnibus arrangements, also obtain evidence connecting the controlled wallets to the custodian’s legal entity.

3. Recalculate asset balances

Query an independent blockchain node or data provider at the stated block height. Verify the token contract as well as the ticker: “USDC” or “USDT” labels alone are insufficient because unrelated tokens can use the same symbol.

For EVM networks such as Ethereum, Base, Arbitrum, Polygon, BNB Chain and Optimism, check the token contract and balance at the recorded block. Tron and Solana require network-specific address and token-account handling. Account for assets held in smart contracts, bridges or pending transactions instead of assuming every balance sits in a standard wallet.

4. Check timestamps and confirmations

The attestation should identify the exact block or slot used, not only a wall-clock timestamp. Confirm that the block hash remains canonical and that the provider’s required finality threshold was reached. Confirmation policies should be documented by network because reorganisation and finality characteristics differ.

For month-end reporting, define a cutoff rule in advance—for example, the first finalized block after 23:59:59 UTC—and apply the same rule to assets and liabilities. A mismatch of even a few minutes can materially distort coverage during high transaction volumes.

Validate liabilities, not just reserves

Proof of reserves demonstrates control of specified assets at a point in time. It does not necessarily prove that all customer liabilities were included, that assets are unencumbered, or that the business was solvent before and after the snapshot.

If a custodian publishes a Merkle-tree liability commitment, customers may be able to verify that their own balance was included without seeing other customers’ balances. That inclusion test still cannot establish that omitted accounts do not exist. Ask an independent assurance provider to test the completeness of the source ledger, treatment of negative balances, related-party accounts and reconciliation to the legal entity’s books.

Calculate coverage using consistent units and timestamps: verified eligible assets divided by included customer liabilities. Review asset-by-asset coverage as well as the aggregate ratio. A surplus in one volatile asset should not automatically cover a shortfall in USDC or USDT.

Proof of reserves versus a financial audit

The phrase onchain audits is often used for automated wallet monitoring. Treat it as monitoring unless an independent audit firm has issued a report with a defined scope, criteria, period and conclusion.

A practical vendor-selection checklist

• Map every supported USDC and USDT network, token contract and wallet model.
• Demonstrate dual approval for payments, policy changes and recovery.
• Export a complete audit log and confirm timestamps use a documented standard.
• Retrieve an attestation, validate its signature and reproduce the balance independently.
• Test historical snapshots, API authentication, rate limits and version changes.
• Review how liabilities are generated, reconciled and tested for completeness.
• Confirm whether reserve assets are segregated, pledged, lent or otherwise encumbered.
• Read the independent assurance report, including exceptions and subsequent events.
• Document incident, withdrawal and key-recovery procedures before funding the account.

Finance teams should retain the signed payload, public-key fingerprint, chain query results, liability evidence and assurance report together as an evidence pack. Wallet screening can be performed separately using tools such as Stablerail’s wallet checker. For operating payments from an MPC treasury, review the supported workflow for stablecoin payouts and confirm current network, eligibility and onboarding requirements through Stablerail help.

The strongest arrangement combines enforceable quorum signing with evidence that can be independently reproduced. Neither MPC nor proof of reserves is sufficient in isolation: one controls movement, while the other supports verification. Corporate treasury teams need both, plus a reliable link between onchain assets, customer liabilities and the relevant legal entity.