By Changhao Jiang (Co-founder and CTO of Cobo)

With the trust in centralized institutions at all-time lows after FTX’s collapse, CZ’s post on Twitter called for exchanges to adopt Merkle Tree proof-of-reserves method to prove that they have not misappropriated user assets. So far, many exchanges are scrambling to prepare proof-of-reserves to reassure clients that their funds are safe. However, the popular Merkle Tree proof-of-reserves method has some fundamental flaws. Specifically, ill-intentioned centralized institutions can easily circumvent the checks that this method is intended to enforce.

I’d like to share the two fundamental flaws of the existing Merkle Tree proof-of-reserves method and suggest ideas on how it can be improved.

How does existing proof-of-reserves method work

To mitigate the information asymmetry between users and centralized institutions, existing proof-of-reserves often adopt traditional audit approaches. That is, relying on a trusted third-party audit company to issue an audit report to certify that the amount of assets held on-chain by the centralized institution matches the total sum of user balances.

For proof-of-liabilities, centralized organizations need to generate a Merkle Tree with user account information and asset balances. The Merkle Tree is essentially an anonymized, tamper-proof snapshot of all user balances held. Each user can independently calculate the hash value of their account and ascertain whether their account is included in the Merkle Tree.

For proof-of-reserves, centralized organizations need to provide the on-chain addresses that they own and have them verified and audited. A common practice is to require the centralized organization to produce digital signatures to prove ownership of their on-chain addresses.

After the Merkle Tree and the confirmation of ownership of the on-chain addresses are completed, the audit agency reconciles the total amount of assets of both sides, and then determines whether the centralized organization has misappropriated user funds.

Flaws of the existing proof-of-reserves method

1. Possibili_t_y of using borrowed funds for audit

One problem with the proof-of-reserves method is that most of them are point-in-time audits and more often than not, it is only done once every few months or even years. That is, centralized exchanges can still misappropriate user funds and simply borrow funds to fill the gap during the audit period.

2. Possibility of conspiring with funders

Ability to provide signed messages does not equal owning the assets on corresponding addresses. It is possible for centralized institutions to conspire with funders to provide on-chain proof of funds. These funders can even help multiple institutions with their proof of funds using the same capital. Such fraudulent behavior is very difficult to detect by current methods of audit.

Thoughts on improvements

An ideal proof-of-reserves system would offer the capability of live checks on liabilities and reserves by auditors and end users. However, it comes with exorbitant costs and/or might unnecessarily leak users’ account information to third party audit companies. Third party audit companies can even infer user account position information from anonymized data if enough data is obtained.

To prevent falsified proof-of-reserves during audit without risking leakage of user information, I propose two key ideas.

1. Random audit at unpredictable time intervals

Random audit at unpredictable time intervals would make it very difficult for centralized institutions to manipulate account balances and on-chain assets. Such an approach also serves as a deterrence of misbehavior by increasing the perception of the certainty of being caught.

How this can be practiced: Requests for audit can be sent out by trusted third-party auditors to centralized institutions randomly. Upon receiving the instructions, the centralized institution would be required to generate the Merkle Tree with users’ balances (proof-of-liabilities) that are tagged at that specific point in time, e.g. by block height number, as well as a report of their on-chain assets (proof-of-reserves).

2. Using MPC-TSS solution to expedite proof-of-reserves

During random audits, a centralized institution needs to provide proof of reserves at very short notice. This would be challenging for centralized institutions which manage a large number of on-chain addresses on behalf of users, such as exchanges. Even though institutions may store most of their assets in a fixed number of addresses, e.g. warm or cold wallets, the aggregated amount of funds stored across a large number of on-chain addresses is still significant. To consolidate the funds in all of these addresses during an audit into a smaller number of publicly-known addresses can be a time-consuming exercise. This precludes an immediate response and also inadvertently gives bad actors the opportunity to borrow funds to fill the gap temporarily.

Is it possible for centralized institutions to prove reserves without having to consolidate on-chain assets into a small number of addresses? One possible approach would be to leverage on the MPC-Threshold Signature Scheme (MPC-TSS) technology.

On a high level, MPC-TSS is an advanced cryptographic technology that splits a private key into two or more key-shares, encrypted and distributed among multiple parties. These parties jointly cooperate to sign a transaction when required without ever revealing their individual key-share to one another or reproducing the private key in full. Plugging that Cobo also recently launched our MPC-TSS custody technology.

The third-party audit party (law firms, audit firms, custodians, trustees and even regulators themselves) can take one key-share while the centralized institutions hold the remaining key-shares. As long as “threshold” is set as a number greater than one, all of the assets will continue to be under the centralized institution’s control. In order to allow the centralized institutions to generate a large number of addresses that are co-managed by the audit party, the MPC-TSS co-management solution needs to support the BIP32 protocol.