Proof of reserves AND liabilities, a proposal for centralized exchanges

Our proposal addresses the issue of proof of solvency. The balance sheet has two sides and solvency is assured as sum of reserves > sum of liabilities. In case of an exchange, the considered liabilities are made of user deposits. Assets in declared wallets and in transparent bank accounts can be considered reserves, however, for the sake of clarity, we leave out the explanation of transparent bank accounts.
BitMEX published a study of how proof of liabilities could be approached, naming a single exchange-Coinfloor-using a similar solution. The study mainly concerns with privacy of the depositors. Also, Coinfloor provides monthly attestations. The exchange still can steal users’ funds, however, such misconduct would be exposed not later than in a month’s time. We leave privacy out for now and we focus on how to increase the users’ funds’ protection. The proposal introduces a quasi-DAO over the reserves.

Clients of an exchange receive tokens indicating their deposits. I deposit 1 BTC → I receive a claim against 1 BTC. I deposit 1,000 EUR → I receive a claim against 1,000 EUR. All these deposit token transfers are documented in a blockchain → the sum of deposits is known and public, and can be compared to the sum of reserves. Also, the structure of the reserves and deposits is known. The overall sum can be calculated in a decentralized way using for example Chainlink to get exchange rates.
Holders of deposit tokens form a quasi-DAO. Based on the value of their deposit token holdings, they can elect a reserve manager. Also, they can limit the reserve manager’s right to transfer the reserves out of the selected wallets, e.g. they limit the weekly amount of reserves to be moved to 10% of the value of the reserves at the beginning of the week (snapshot). Every token holder can indicate the % → the weighted median value of participating voters will be chosen. In case the DAO manager wants to exceed the limit (to withdraw more money from the reserves within the week), the transaction will be postponed by a week. Within the week, token holders can veto the transaction. 50+% of voting power is needed to stop the transaction from happening. In case the threshold is not reached, the transaction will be executed and entered into the blockchain.
Note: The deposit tokens represent something like a decentralized key to the reserves. The idea is to prevent the tunneling of the exchange’s funds. The exchange’s user’s account must be attributed to their address. The private key to the user’s address lies in a plug-in wallet in their internet browser. The wallet communicates with the exchange (just like e.g. Metamask communicates with DeFi exchanges). Each time the user connects to the exchange, their balance of deposit tokens is compared to their actual holdings. In case the actual holding surpasses the deposit tokens (because they traded successfully), the user shall automatically receive more deposit tokens from the Pool. In case the actual holdings do not cover the deposit tokens (because they made losses), the user will be asked to sign a transaction for sending the excess deposit tokens to the Pool. Shall the user not sign the transaction, they will not be allowed to trade at the exchange before they do.

In case the user refrains from signing the transaction and using the exchange, all their deposit tokens will be automatically sent to the Pool after a certain period of time (Expiry). This functionality of the tokens is embedded in them and is known to the users. The measure is meant to prevent hoarding of the deposit tokens to monetize them or to obstruct the exchange.

In case a user wants to withdraw their tokens or fiat money from the exchange, they must burn their deposit tokens. In case the user loses access to their wallet with deposit tokens, they must ask the reserve manager to proceed with the withdrawal. The token’s address will be labeled so that the remaining deposit tokens do not confuse with the actual deposits. When they should move to the Pool after the Expiry, these labeled deposit tokens will be burnt instead.