My thoughts on Proof-of-reserves

The FTX saga is unfolding in front of our eyes. Publishing Merkle tree based proof-of-reserves is expected from digital asset service providers ever more often.

Let’s discuss what this means, where it falls short and one alternative idea. We want to build trust and move that trust from trust in organisations to trust in a verifiable system.

A nice explanation of proof-of-reserve is available on Kraken’s website. In short, the three main statements obtained are these:

• An auditor has checked the availability and accessibility of the assets on- and off-chain.
• Every account holder (individually) can check whether their assets are included in the liabilities.
• An auditor has checked that the assets exceed the liabilities of the company (for one moment in time).

The imperfections are well understood, in particular:

• The check relies on the competence and integrity of a third party (the auditor).
• Sufficiently many account holders need to check their accounts. Together they must form a meaningful sample size. And they need to be able to sound an alarm in case they detect any inconsistencies.

This does not create the full transparency that is available for DeFi protocols. Yet, it is a step in the right direction. We should like to make more steps in that direction.

The best idea for a digital asset service providers to move from an audit based system to a more verifiable system is with a product like this:

1) Separated and segregated accounts

The assets on the blockchain are kept on an address which is dedicated to the client exclusively.

In many jurisdiction this creates a bankruptcy protected off-balance sheet position.

This allows to move from a trust equation of “the company has more assets than liabilities, hence all assets are safe” to more simply “the company owes me my assets even in case of bankruptcy hence I need to only check my own assets are safe”. The latter is much easier to check because it involves less data dependencies. Also it’s incentive structure is simpler. I’m checking on my behalf rather than organising or assuming that there is an enough large sample size of checks by others.

2) Disclosure of blockchain addresses to clients

Disclosing these addresses to the client provides full transparency. It also allows the client to be independently alerted of any movements. With existing monitoring services the hurdle to setting this up is very low.

3) Availability of private keys

Now we have established that the assets are visible on the blockchain. And that unexpected movements can be detected. We further need assurance that the private key to the address is available to the digital asset service provider. Micro-transactions are a mechanism to proof access to the private key without revealing it. More elegant is a web or API based service allowing the signing of an arbitrary text (not transaction). With the public key of the blockchain address the client can verify whether the provided text was signed with the private key. This proves that the private key is available.

A product along these lines combined with individual responsibility to check the system rather than trust the institution will bring us closer to a secure storage of assets while enjoying the services and positive attributes of (centralised) digital asset service providers.

Post scriptum (21.11.22): The proof of reserve process as described by Kraken makes use of Merkle trees. To my understanding this data structure is not necessary at all. The data structure could equally be a list that can be searched linearly for the hash of a particular account by the holder of that account. Important is that the data is provided by the auditor who included that account in the overall process. Personally I would rather not use a complex data structure which is usually associated with the trust-creating properties of blockchain but not needed by the process because it confuses and deters people from truly understanding what is going on.

(Disclaimer: All views and opinions are mine; I work for Bitcoin Suisse as Head of Innovation)