Uphold - a follow-up

Uphold - a follow-up

Bitcoin Factom Proof of Liabilities Proof of Reseves Proof of Solvency Uphold

Two weeks ago, I wrote a blog post about Uphold's proof of solvency. Since then, I was in contact with Rebecca Geller, a PR, and by her proxy, with Jorge Pereira, chief product & engineering officer at Uphold to discuss the recent concerns with their platform and the perceived insolvency. Having exchanged a few lengthy emails, I would like to present what I learned about the situation and give a more informed opinion on the matter.

Voxels

While Voxels appeared to be an important part of the insolvency claim early on, they don't seem to play an important part anymore. As they are currently held separate from the main currencies and not counted towards the solvency anymore, it should be impossible for them to be used as an asset to cover the liabilities of currencies other than itself.

It is very unfortunate there isn't much publicly available historical data to draw on in trying to evaluate whether the Voxel balance was consistently counted towards the solvency proof when other assets were not enough to cover the difference, or was 2016-02-14 an anomaly. While archive.org does have some records of that page from before February, it doesn't render correctly. Retrieval of the data would be possible, but would take a skilled web developer to decipher. Perhaps in the future, we could see the transparency data being regularly exported to say, Factom, where it could be used for analysis in the future (disclaimer - I work at Factom).

Beyond that, Uphold handling Voxels appears to be a simple deal - Voxelus paying Uphold to list and handle their currency, handle the currency conversion, etc. As long as the currency itself is handled separately from everything else, I personally see nothing wrong or shady in the arrangement.

$38k deficit into a $57k surplus

While the Voxels can be ignored, we are still left with probably the main problem that needs addressing - the $38k deficit turning into a $57k surplus.

On 2016-02-14, Uphold's total obligations to their members was $115M, and assets - $116M. Subtracting the value of Voxels ($109M, $110M), the totals were $5.7M and $5.6M, with a deficit of $38'145.29. On 2016-03-27 Uphold's total reserves were $5'359'978.76 in obligations and $5'417'435.54 in assets, with a surplus of $57'456.78.

In other words, $95k worth of assets appeared seemingly out of nowhere in a span of a month and a bit. This either meant that either:

1. Voxels were indeed counted towards the solvency in February
2. The transparency website misreported some numbers
3. The balances were mismatched due to some recent trades or money movement
4. The numbers were fabricated

Either one of the four outcomes would show the platform in an unfavourable light, but some would be more damning than the others. 

Uphold explained the issue with option number 3 - the money was in transit between bank accounts and exchanges, and thus wasn't taken into account by the automated system tallying everything and publishing the numbers onto the transparency page. When asked for a proof that the funds were indeed in transit at the time, instead I received an a reply of

"To some extent, that’s a fair request, but if you trust the data illustrating what is perceived as a shortage of $38k, it’d stand to reason you’d trust the same source presenting an additional explanation, particularly seeing as the issue resolved itself within hours. The explanation we have provided rests on the same logic and transparency as the data you believed that illustrated the shortage."

Shorting Bitcoin, speculating with customers' funds

Another important accusation levelled against Uphold was the issue of their Bitcoin balances being short in favour of fiat currencies.

On 2016-02-14 Uphold's BTC obligations were listed as 5'834.056BTC, and their assets as 4'594.390BTC, short 1'239.666BTC, or 21.25%. On 2016-03-27, their BTC obligations were listed at 4'944.479BTC and assets at 3'652.980BTC, short 1'291.499BTC or 26.12%.

This raises a few questions - why was this done in the first place, what was the contingency plan in case of a price swing (with their $57k surplus, a 44.5BTC/USD price swing would turn the website insolvent again) as well as whether the company is speculating using their customer funds.

The reasoning behind the short balance was stated as trading sideways to save on exchange fees. As Uphold doesn't charge a conversion fee, they focus on lowering their operational costs by not immediately covering their customers' trades. In a perfect system, the trades would be going back and forth, allowing Uphold to only correct a fraction of the total trade amount on an external exchange, thus lowering the fees they pay. However, when the trades are more one-sided, the balance discrepancy grows further and further apart and needs to be corrected eventually.

Second question had a fairly straightforward answer - stop-loss mechanism. When the price swings too wildly, automatic trades are executed to protect the reserves.

Lastly, the company stated it does not condone the practice of speculating with one's customers' funds without an explicit permission from them. As such, Uphold is claiming not to engage in such a practice, and does not aim to make a profit by being over-exposed to one currency or another.

All in all, we seem to be running into the main trade-off that might have been the cause of this BTC shortage - whether one should prioritize keeping the fees low, or the reserves rigid. Neither one is a wrong answer - they both have their merits and drawbacks, but they do send a message about the company's priorities and values.

Interestingly enough, between 2016-03-27 and 2016-04-01, during my email exchange with Uphold, their BTC reserves seem to have corrected themselves:

Uphold BTC balance, 2014-04-01

Whether this balance correction was coincidental after over a month of running on a BTC deficit, or it was a deliberate action by the company, it can be hard to prove. Despite asking about "What is the threshold before your company would consider itself over-exposed on Bitcoin?", no direct answer was provided. At least I can take comfort in Uphold's statement to consider their BTC reserves more closely:

"This is feedback we’ll incorporate, and in all likelihood will just result in us adding a bit more of our own funds to the reserve surplus on the asset side of Bitcoin, to ensure it’s always close to over-reserved. "

Proof vs claim

A few times during the email exchange the topic of proofs came up. As Uphold is focusing on providing "a public, real-time, traceable and verifiable proof of solvency", it is important to distinguish between what constitutes a proof, and what is just a claim.

A proof needs to be independently verifiable and falsifiable, while a claim does not. Whether you use a send-to-self transaction, use a set of addresses and balances, or do something else an independent third party (or better yet, the public) can verify and possibly disprove, that can constitute a proof. Self-reported balances as is the case with Uphold's current transparency page, do not constitute any proof, but are merely a claim of solvency.

While Uphold is claiming that their reserves are independently audited on a quarterly basis and are currently working on publishing those audits in the future, as of the time of writing, I have no evidence of this, despite Uphold being asked to provide "independent, verifiable, sources for the information" for this article. I would exercise caution until such proofs are provided, even if this might be erring on the side of overt caution.

All in all, in an ideal world, I would like to see the following proofs:

• Proof of liabilities - allowing anyone to verify that their assets are counted in Uphold's total liabilities and that everything adds up
• Proof of reserves - independently verifiable proof that Uphold does indeed own the stated currencies and assets, crypto or otherwise
• Proof of existence / records - Ideally, the other proofs would be timestamped or published on a platform like Factom to prove they weren't altered in the future
• Proof of exchange rate - while one is able to claim they are not charging an exchange fee, a crafty party could hide the fee in the exchange rate spread and charge it covertly. While I don't know of any company that incorporates such proof, shy of using an open ledger, it might be a mark of the highest standards of transparency

At the current time, one can only wait for the first two or three to be eventually published...

Everything else

During the email exchange, a few less important topics were discussed. Some of the statements make the company appear fragile to criticism:

When asked whether Uphold stands by their CEO's tweet labeling the first Reddit post about the company's possible insolvency as "ridiculous, untrue & libellous lies", I was reassured:

"Absolutely, and it’s unfortunate that people end up misinterpreting the information we make available in good faith, without offering us the chance to clarify it. I can understand the confusion regarding VOX, and I hope our updates  address that.

Our CEO Anthony Watson is an award winning social  advocate, who does a great deal of good in the world to support people's basic human rights. He’s got no interest engaging with an anonymous Reddit poster who set up an account up several hours before he made this post seemingly only to cast doubt upon Uphold, without making any effort to engage with us to clear up these questions. "

The middle part seems like an appeal to emotion. In their closing remark, another two quotes appear to be putting the company in a victim role:

"[...] while some people may see us as “just a corporation”, we instead see ourselves as a group of people on a mission. We want to do the right thing, and being so poorly perceived is damaging to the morale of those working hard to make Uphold a reality. "

 "[...] We’re building bridges, so we’re bound to find trolls, but we see no value in taking part of a conversation where the conclusion has been decided beforehand and there is no opportunity for open dialogue."

While I'm glad that despite that the company decided to address some of those criticism in their blog post as well as answer my doubts and questions on the matter, failing to address the criticism head on because they came from an anonymous user while taking that criticism to heart and letting it lower your morale might not be the healthiest approach to take on the Internet.

Conclusions

Having had the chance to discuss the insolvency accusations with Uphold, I remain cautiously optimistic for their platform and their customers.

While they failed to provide any verifiable proof of their platform's solvency or where the $95k of extra solvency came from between February and March, their promise of publishing audits in the future might address similar issues in the future. 

Uphold's changed commitment to maintaining a more rigid BTC balance should similarly keep that issue from cropping up again.

While the company might not wish to engage "trolls" raising criticisms of their platform, it is at least good to see them addressing the concerns raised and improving themselves based on that feedback. One could see it as either being wise enough to reconsider one's stance, or desperate enough to pander to critics however.

So here's for hoping we'll get our proof of solvency soon enough and Uphold will be a shining example of transparency, rather than turning into another cautionary tale in the Bitcoin world.

Full Proof of Solvency - pondering Tether

Full Proof of Solvency - pondering Tether

Crypto 2.0 Fiat IOU Omni Proof of Liabilities Proof of Reseves Proof of Solvency 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...