Proof of Solvency: Technical Overview

Miha Vidmar
ICONOMI
Published in
6 min readApr 20, 2018

On April 5, 2018, ICONOMI’s $133.6M of liabilities and $210.2M of reserves, distributed across 80 digital assets, were blockchain audited and verified by Deloitte.

Our goal for the blockchain audit was to prove our solvency and our digital asset holdings using best practices from the traditional financial industry merged with the transparency of the blockchain world. This is why we decided to work with Deloitte and to utilize the Merkle tree approach.

Transparency vs. Anonymity

A Merkle tree is a structure that allows for efficient and secure verification of content in a large body of data. Using Merkle trees, each individual user can verify his or her account balance and calculate all liabilities without disclosing any personal information.

Measuring Solvency

Solvency is defined as the ability of a company to meet its long-term financial commitments. Solvency is proved once the total reserve balance acquired using proof of reserves is shown to be sufficient to cover the total liabilities acquired using proof of liabilities. Using these two different methodologies, Deloitte proved that ICONOMI’s reserves are greater than its liabilities. As such, all of ICONOMI’s digital assets have now been verified.

Proof of solvency is built from two parts:

Proof of liabilities: We have established a procedure for putting all our user and DAA holdings into Merkle trees. Using Merkle trees enables each user to check that they were included in our liabilities without revealing any personal information. The more users who check that their balances were included in the tree, the more certainty the proof achieves, so we encourage as many people as possible to check their balances once the tools are made available.

Proof of liabilities has been split into two parts:

  • Assets held by users (such as ETH, BTC, and ICN held on the platform, as well as any DAA holdings)
  • Assets held by DAAs

Proof of reserves: Total reserves is defined as the sum of all ICONOMI’s digital assets and fiat holdings in bank accounts. Deloitte has received all our blockchain addresses, bank account information, and exchange account information. Along with our blockchain addresses, we prove ownership either by signing messages with private keys or by creating predefined transactions from those accounts.

All eighty assets currently held by ICONOMI have been blockchain audited.

Proof of Liabilities

The Merkle Tree Approach

By using the Merkle tree approach, we enable users to check that our liability/obligation toward them was included in Deloitte’s report.

Let’s say we have four users on our platform with the following balances. For each user, we generate a unique random identificator (salt) called the audit ID.

We take each user’s data and put it through a hash function. Hash functions are one-way functions that take input data and return a fixed-size result (a hash). Since they are one-way functions, you cannot get the original data used for the hash just by knowing the result. By using hash functions, we are able to provide transparency and make data publicly available for verification while still keeping user data private (i.e., nobody can see anyone else’s email addresses or balances).

Note: We used SHA256 for our hashing function. Data is separated by using the pipe character as a delimiter: SHA256(user email | balance of asset | audit id). Values are fixed formatted with trailing zeros stripped.

All user hashes with their balances are then inserted as leaves into a tree:

We then calculate each internal node by summing the balances of its two children, combining their hashes, and then hashing the result. For example, the highlighted node in the image below would be a hash of the following data:

  • Sum of balances: 3 BTC
  • Hash 1: a3j5
  • Hash 2: 49j3

Note: We used SHA256 for internal nodes and separated the data with the pipe character as a delimiter: SHA256( children_sum | left_hash | right_hash).

By using this procedure through all the tree levels up to the root node, we get a root node with the sum of all balances.

We ran the same procedure for all the assets on the ICONOMI platform and built a tree for every asset to get multiple root nodes. These root nodes are extremely important because they show the liabilities we have for each asset. Additionally, using hashes all the way up to the root node makes the data in the tree tamper-proof: we cannot change any of the data in the tree without also changing the hash of the root node.

Procedural Difference for Digital Asset Arrays

The same procedure is used for generating Merkle trees for DAAs except for the data used in the leaves. In the hashing function for DAA Merkle trees, we use DAA tickers instead of user emails. For example:

How to Verify Merkle Trees

How Deloitte Verified our Merkle Trees

Deloitte received the full Merkle trees (balances and hashes only, so no user data was shared) and checked all balances and hashes up to the root node. They were able to check that there were no negative balances and that all nodes were summed and hashed correctly. They also listed the root node hashes publicly, meaning if we ever tried to change any balances or add or remove users in these trees, it would be publicly known.

Coming Soon: Verify Your Branch from the User Dashboard!

Users will be given tools on our platform to verify their branch of the tree and make sure their assets were included in the tree sent to Deloitte. Users can only see their own partial tree, but liabilities are still fully verifiable.

All users who had assets on the ICONOMI platform at the time of the blockchain audit will see the following data on the platform blockchain audit page:

  • User email used at snapshot time
  • Audit ID generated for the user
  • For each asset they were holding at snapshot time: asset or Digital Asset Array ticker, balance, and a link to their partial tree

Here is an example of what a partial tree would look like for the user from the previous example:

Users can see the path from their leaf to the root node. By using any online SHA256 calculator, information on the user’s individual blockchain audit page, and the information provided in this blog post, users should be able to verify that all the hashes from their leaf node up to the root node are correct. Users should also verify that the hash of the root node matches the one listed by Deloitte for that asset. DAA managers will also be able to verify the holdings for their DAAs.

Once the user blockchain audit interface has been implemented, we will publish a dedicated blog post explaining how you can verify your own assets. More updates will follow.

Proof of Reserves

We provided Deloitte with all our exchange balances, all our bank account balances, and all our blockchain addresses holding assets.

Exchange and bank accounts were verified in person. We proved ownership of blockchain addresses either by generating signatures with the private key(s) for those addresses with random strings provided by Deloitte or by creating transactions with an amount and target address agreed on in advance.

Note: For the wallet involved in the Parity hack at address 0x376c3e5547c68bc26240d8dcc6729fff665a4448, we were able to prove ownership by signing messages with private keys, but we cannot access those assets at this time.

Proof of Solvency

All eighty assets were blockchain audited. We have $133.6M of liabilities and $210.2M of reserves. The full data is available on our website.

In conclusion, by proving we have more assets in our reserves than liabilities to our users, we have proved that we are solvent.

Follow our official channels for more updates and news:

Facebook / Twitter / Reddit / Medium

or log into our platform to explore more DAA strategies.

--

--