Using proofs to improve risk transparency in centralized entities
What are we talking about:
Ensuring that anyone dealing with a centralized entity such as an exchange can understand what their risk is, through disclosures about the net risk in the entity’s balance sheet. And therefore avoiding the next FTX.
What are we not talking about:
KYC/AML, DeFi.
What statements about an entity’s balance sheet allow us to assess risk?
Assertion:
There is nothing new from FTX and other collapses in the market that has not already been addressed for decades in tradfi risk management controls. We’d like to apply those existing metrics and controls in Web3-focused companies through transparency and proofs, rather than entirely through human oversight.
Key Concepts
Proof of solvency (NOW)
Are assets greater than liabilities?
- Need complete capture of assets and liabilities:
— On chain
— Off chain but on web 2 balance sheet (e.g. a traditional loan)
— Off balance sheet (e.g. an OTC option)
—All accounts in all categories must be declared and included - Need fair valuation:
(which for assets is non-trivial…were FTX’s holdings of FTT worth $22 per token when they eclipsed traded volume on the open market? If not, what were they worth?).
Proof of solvency (FUTURE)
Is the asset portfolio low enough in risk that it won’t put depositors’ funds at risk? (i.e. any loss can be absorbed by the CEX’ own capital)? In addition to all of the points above:
- Need a way to capture, categorize and weight risk:
— Credit risk is one factor ($10 at the Federal Reserve is worth $100 in junk bonds).
— Market risk is another ($10 at the Federal reserve won’t help you completely repay an Eth deposit if the value of Eth doubles while with the CEX). - Need to identify concentrations of risk:
— Depositors are likely safer if the CEX has its assets widely diversified across medium-risk assets than if all in a single large exposure to one asset. - Need to track related party exposure as a special factor (and potentially assume 100% loss):
— High potential for subjective investment and lending decisions.
Proof of Liquidity
- This one’s pretty straightforward — if there’s a run on deposits, or other liabilities, can you recall loans, sell assets quickly enough to meet the withdrawals (or do you have sufficient lines of credit that will work even in extreme adverse circumstances)?
Using proofs and ZKPs Requires
1. Ensuring everything is captured:
Full capture of liabilities can be an anchor for assets too. If the liability picture is complete, the CEX has an incentive to disclose enough assets to provide proof of solvency. Three potential approaches:
- Fraud proof-type approach: Per the VB paper, record every new liability in a Merkle tree, that creditors / depositors can query at any time to prove that their item is included. Can be done with or without ZKPs, but ZKPs allow with less information leakage. Downside: Requires a reasonable amount of proactive checking by creditors / depositors to enforce and a mechanism to raise the alarm if the proof fails (although some could be automated into the customer account log in process?) . Requires a mechanism for tracking all new liabilities, and changes to existing liabilities.
- Manual audits of liabilities that are attested to onchain. Sounds ‘lite’ but note that misstatement of liabilities has not been an issue for any of the recent CEX problems.
- A corporate DID that is designated as the only way in which the CEX can legally contract itself into new assets and liabilities. With this in place, the DID can act as a register of all balance sheet items and underpin the collection and valuation of the items for the solvency calculation.
Assets could be proved in a range of ways:
- The CEX could reveal wallet addresses and prove it knows the private keys. It could also use a zkApp to prove that it controlled a wallet with x, y and z tokens in it without disclosing the wallet address.
- Offchain assets could be verified by an auditor and sent onchain using a zkOracle. Or a DID that controlled authority for all legal commitments by the CEX could be invoked as the source of data.
- It could go further and prove that it controlled a wallet with specific amounts of tokens that are either named, or shown to be within a certain class of liquidity or market cap range without disclosing the exact tokens.
2. Obfuscation:
- Use ZKPs for the Merkle tree of liabilities to reduce the potential for information leakage.
- Use ZKPs to prove wallet control without revealing the underlying wallet address, also obfuscate the token holdings and simply prove that they are in a certain category (e.g. market cap over $500M, with holdings less than 5% of circulating supply), allowing attribution of a risk weighting. Requires a data oracles for the context.
- How would you actually go about doing this proof of liabilities in practice with SnarkyJS? Let’s split this into implementation details and operational details. We’ll make some design choices arbitrarily (and not necessarily the most efficient ones) to be more concrete and straightforward when describing things for the purposes of these notes.
Implementation details:
Let’s assume we’re implementing a proof of liabilities where we want account holders’ account balances to stay private. We’ll use a tree of recursive proofs so that we can incrementally update the data more efficiently.
- We create a simple Merkle tree (not a Merkle sum tree) with salted hashes at the leaves as Vitalik described in his post. However, we’ll include a group of salted-hashed entries AND include a hash of the contents of the entry (thus obfuscating the entry details). This group will be large enough to be an anonymity set, but small enough that we don’t take too long to generate a proof. We’re going to accompany this with a recursive zkSNARK tree that proves the following:
- Base case (at the bottom of the tree): There exists a series of balance entries with contents that hash to that which is present here AND none of the entries have negative numbers AND these entries only include valid tokens (etc), such that the sum of the balance for tokens A, B, and C is X_a, X_b, and X_.
- Inductive case (at nodes within the tree): There exist two valid proofs with balances that sum to X_1a, X_1b, X_1c and X_2a, X_2b, X_2c — whose sum is Y_a=X_1a+X_2a, etc for Y_b, Y_c.
- In this way at the top of the tree is a proof that sums all the contents of all the entries of liabilities.
Operational details:
- A CEX should periodically update this information. How often should depend on how much compute the exchange wishes to dedicate to it (which might be proportional to the number of active users). Something between once an hour and once a day should be sufficient since we’re using a recursive proof tree, which only requires updating a few recursive layers of proofs (in practice something between 10–20 layers assuming groups on the order of between 2⁶-2¹⁰ entries).
- The recursive proof tree makes this design sustainable in an incrementally updatable fashion, and SnarkyJS is the first and only general purpose zk toolkit that supports recursion, making it easier than ever to implement a proof of liabilities.
3. Sourcing data and valuations:
- Oracles and zkOracles are the likely answer. Valuations are potentially the most challenging issue.
Other: There’s a lot of detail to be worked out re. showing / proving asset quality, large exposures, connected lending but in theory all the same techniques should work. Valuations could be from oracles but in some cases might require manual attestation too.
Readiness: We can use SnarkyJS to build many components now. Data sources that use Poseidon-based cryptography are easy. Work is underway to enable SnarkyJS to work with ECDSA/ Ethereum signatures — near term published roadmap. In some scenarios, scale will be an issue for all ZKP technologies at this point.