At Albacore we develop tools to improve financial transparency. We believe that more can be done to provide users with information about the organisations they trust with their money
While crypto-assets have only been around for a short period of time, its history has been littered with incidents of theft and questionable actions by crypto-organisations that have sought to capitalise on its popularity while skirting regulations that have struggled to keep up. From the infamous Mt Gox bankruptcy filing in 2013–14, to the recent controversy surrounding Tether and their claim to be 100% USD-backed. Questions have been raised regarding the opaque operation of organisations that utilise crypto-assets or store them on behalf of users (e.g., Exchanges).
This is exacerbated by the concept of ownership when it comes to crypto-assets. The entity that controls the private key where the funds are stored, from the perspective of the blockchain, owns the funds. In other words the ones storing your crypto-assets, for all intents and purposes, own the assets. This is why retrieving stolen funds (e.g., the DAO hack, the Parity wallet bug, the CoinCheck exchange theft) has been difficult or close to impossible. Despite this, users (knowingly or otherwise) continue to trust third parties to store (and hopefully return!) their crypto-assets.
Positively, this has been product of crypto-assets becoming more and more mainstream. It is unrealistic to expect every user to be able to generate their own wallets, maintain their own nodes, and store their private keys safely. Instead, we have to think of new ways to mitigate the risk for new users who will always rely on external services to manage their crypto-assets. The solution will have to make the workings of these organisations more transparent to users, without compromising on privacy and security. After all, the current opaque operations of these crypto-organisations seem to be at odds with the open, trust-less and decentralised principles that blockchains were designed on.
What we need is a publicly verifiable, privacy preserving Proof of Solvency.
Let’s deconstruct exactly what we mean by this.
Any user should be able to audit and verify that this proof is correct and valid. Typically solvency proofs like these are conducted by (trusted) third parties accounting firms such as EY or PwC at pre-set times, taking the form of annual or quarterly reports. Being publicly verifiable will empower users to also act as auditors for their own funds at any time.
This is a no-brainer. User data needs to remain anonymous at all times. Validating the proof should not enable a user to learn anything about other users. Similarly, the proof should not compromise the security or privacy of an organisation’s secret.
Proof of Solvency
A Proof of Solvency is one where the organisation is able to prove that its total assets (all funds under its control) is equal to or exceeds its total liabilities (the sum of what is owes to its users).
The elegance of this Proof of Solvency is that, in addition to the properties above, it minimises the trust a user needs to have in the organisation. It leverages mathematical concepts which cannot be faked or forged, either in the construction or the validation of the proof. So what do we need to construct such a proof?
1) A Proof of Assets
A organisation must make a commitment to the total assets under its control. For companies utilising crypto-assets, this can be achieved by cryptographically signing a publicly verifiably random message that cannot be known by the organisation ahead of time (e.g., the headline of a newspaper on the day of the proof — à la Bitcoin’s Genesis block). This collection of addresses and signed messages can then be published on a public ledger such as IPFS or a blockchain for anyone to validate.
2) A Proof of Liabilities
The organisation needs to make a commitment to the total liabilities it owes to its users or customers. User balances are totalled into a modified Merkle Tree. This serves two purposes:
- User data is obfuscated as a result of the recursive hashing process in the tree’s construction
- It provides an efficient way for users to be able to prove they are included as part of the total liabilities.
At the very top of this tree is the Merkle Root, and contains two important pieces of information.
- The total sum of liabilities owed by the organisation to its users
- The “fingerprint” of the tree in the form of a hash. It is derived from both the content and construction of the tree. This makes the tree a “tamper-evident” structure as any changes to its content or construction will change this fingerprint
This fingerprint and balance can then be embedded in a publicly verifiable ledger (e.g. IPFS, blockchains)
The elegance of this Proof of Solvency is that, in addition to the properties above, it minimises the trust a user needs to have in the organisation.
How do we validate the proof?
We now have all the components for a publicly verifiable, privacy preserving Proof of Solvency. Users will be able to use a public ledger to retrieve 1) the list of signatures and addresses, and 2) the Merkle root and total liabilities.
They can validate 1) by verifying each signature with the public keys associated with each address. Simultaneously, they can check the balances contained by each address. This will give them the total assets.
2) is validated by requesting a Merkle proof for their user details. By entering their user details they are able to recreate the root hash and total liabilities that have been publicly committed to. As the hash is mathematically unforgeable, if they cannot recreate it this would raise suspicious of malicious behaviour by the organisation. This will give them the total liabilities
If the outcome of 1) is greater or equal to 2) then a user has validated that the organisation is indeed solvent!