Full Proof of Solvency - pondering Tether

Tether (currently in beta) is a fiat gateway allowing its users to transact in USD IOUs on Omni and internally in Tether's shared wallet. One of the core features the platform advertises is its 100% backing of the issued assets, coupled with frequent solvency reports. This used to be a big issue in the Bitcoin world a few years back, when MtGox, once biggest Bitcoin exchange in the world, became insolvent and shut down. After that incident, a few exchanges (1, 2, 3) started looking into creating proof of solvency to bolster consumer confidence in their platforms. Today I would like to talk about what constitutes a full proof of solvency, how Tether approaches it in a multi-platform system, as well as some potential pitfalls one might face while designing proof of solvency.

Proof of Solvency

A quick recap of what is a Proof of Solvency. In simple terms, its a way for exchanges and other companies holding their customer funds to prove their liabilities to their customers never exceed their cash and crypto reserves. It stands in stark contrast to fractional reserve banking, where by definition, there isn't enough cash or precious metals to cover all of the outstanding deposits. Historically, this is an important concept for Bitcoin - the Genesis Block created by Satoshi quotes a newspaper headline talking about a bank bailout.

Since we're dealing with cryptocurrencies, the modus operandi is always "trust but verify" - claiming that you have a certain amount of money but not having a strong, verifiable and falsifiable proof usually raises red flags.

Proof of Solvency can be broken down into two parts - Proof of Liabilities, wherein the company proves how much they owe their customers, and Proof of Reserves, where they prove how much liquid fiat and crypto they have to cover those deposits.

Proof of Reserves

Proof of Reserves is usually quite tricky for the Bitcoin exchanges as it often involves interacting with "the old financial world" - banks and their banking system. To prove they are solvent, an exchange would publish statements from their banks indicating how much money they have in a segregated account. As banks usually don't focus on creating cryptographically authenticated documents or balances, this is usually the hardest part of the proof to verify outside of a full audit.

However, when we get into the cryptographic world, things get a lot easier. An exchange needs only to state which addresses they own, what is their current balance, and sign the message with those stated addresses. This proves they have access to those addresses, and anyone can go onto the blockchain and verify how much money is really in them at all times.

The last part can also be very important - being able to verify the reserve balance at all times, or at least very frequently, is a lot more reassuring than one-off statements. After all, one could borrow the money for a day to create the proof, therefore misleading everyone.

In the Bitcoin world, one might try to similarly falsify the reserves by asking someone else with deep pockets to sign the proof of reserves statements, creating a false belief that those coins form the reserves. However, this problem can be mitigated with Voting Pools.

All in all, Proof of Reserves is fairly straightforward, at least when it comes to cryptocurrencies. Banks still need to catch up.

Proof of Liabilities

Proof of Liabilities can be tricky for the Bitcoin companies as it often touches on their customer records and databases.

If we're dealing with cryptographic IOUs, things are fairly simple - one only needs to point to the issuing address, count the total number of outstanding liabilities, and sign the statement. Anyone can verify it in real time, just like in the Proof of Reserves for cryptocurrencies.

When it comes to shared wallets and private databases, as is usually the case for many exchanges, the things get a bit more complicated. The companies usually don't want to reveal the balances of every individual account, and the dumps could get quite sizeable (back in 2011, MtGox's database leak was said to contain 61'016 user accounts).

There are a few ways of compressing the data, but the most popular one appears to be creating a merkle tree consisting of account IDs and balances. A single account-balance pair would be a tree leaf. One would then combine the two balances together and pair that with a hash combination of the IDs to form a node higher up the tree. This would continue until we would get one hash and one balance at the very end.

This merkle tree would be hard to fully verify without access to the full account list, but it would also be combined with another interesting trick - every user would be able to request an SPV-like balance branch connecting their account to the merkle root of the tree. If the exchange would fail to provide the branch, the balances would not add up, there would be some negative balances or the branch would not match the latest published root - one would have a cryptographic evidence of foul-play. Now if we only had something like this for the banks...

All in all, Proof of Liabilities is a bit harder than Proof of Reserves, unless we're dealing with pure cryptos once more. Combined with Proof of Reserves, we create a Full Proof of Solvency - the company in question is completely liquid, at least for the time being. Now, lets take a look at how Tether does this...

Tether

A good chunk of this discussion is based on a few conversations I had with the company last year. Since the product is in beta and some time has passed since I spoke with them last, this description might not be indicative of the final product if and when it launches. I bring this example up mainly because it raises some insights into a few important design choices for gateway design.

Tether at the moment is a gateway focused on issuing USD-backed IOUs. Those IOUs can be transferred both on the Omni network, as well as from inside of the Tether shared wallet. In the future, it would be possible to see Tether issuing similar assets on other Crypto 2.0 networks, such as Ripple or Ethereum.

We can see their outstanding balances on their transparency page. Here we come to the first design question - what does this number represent? Is it the balance on Omni, in the shared wallet, a sum of both or something else?

In case of Tether, the number corresponds to the assets issued on Omni. Their shared wallet balance is then a subset of that amount, and as I understand, balances on any other network like Ethereum would also have their own separate balances on the Omni network.

Since we're dealing with multiple networks, the Full Proof of Solvency would be dependent on all of them. In case of Tether, we would start with Proof of Reserves to figure out how much the company has in deposits. The number would be compared with Proof of Liabilities from the Omni network. If that passes, our job is still not done. Now we would use the Omni balance of the shared wallet as a PoR to compare against the PoL of that wallet, and use similar methods for any other connected networks.

The Proofs are valid top-down. If any part is invalid, anything relying on those Proofs are also invalid (which might be more relevant for bigger constructs, like exchanges relying on Tether).

Another interesting issue to consider would be the transaction lag when moving between the different networks. As Tether's top-level settlement network is Omni, which in turn is sitting on Bitcoin, the transactions that move assets between network would have to go over one of the slowest cryptocurrency network (at least in comparison to things like Ethereum or Ripple), which might not be ideal. Since Tether as a company already needs to provide Proofs for all of the network as well as its own wallet, it would make the most sense to make the fastest element be the top level, which in this case would be the wallet.

Conclusions

Full Proof of Solvency is an interesting concept that came out of the Bitcoin world in reaction to shoddy business practices of using fractional reserves at an exchange. It can be tricky to implement when dealing with non-cryptocurrency systems, but becomes trivial on publicly auditable blockchains. It would be interesting to see something similar implemented in a traditional bank...