Protocol Flow
Last updated
Last updated
First, the Custodian must prove ownership of specific addresses and, therefore, of the assets controlled by those addresses. To do that, the Custodian groups its wallets and signs a particular message (it's up to the Custodian to choose the message) with each of them.
The proof of address ownership is a batch of signatures. The contract stores the proof optimistically. This means that no cryptographic verification is performed on submission. The signatures must be subject to off-chain verification starting from the data publicly stored on the contract. Everyone can perform this verification.
This phase doesn't need to be run before every Proof of Solvency round. Instead, it can be run once and updated only if the Custodian moves their assets to a new address.
To kick off a Proof of Solvency round, the Custodian must provide a timestamped snapshot of its liabilities.
This is done by aggregating all the users' data, interpolating them into polynomials and committing to these polynomials. The commitment effectively binds the information about the user identity, individual balances and the total sum of the users' balances (liabilities sum) denominated in different cryptocurrencies.
When receiving the proof, the contract doesn't automatically verify that the assets controlled by the addresses claimed in Step 1 are greater than the liabilities sum published as part of the commitment. This verification must be performed off-chain by:
Fetching the addresses of the Custodian from the Smart Contract (as claimed in step 1)
For each cryptocurrency, summing the assets together
For each cryptocurrency, verify that the asset sum is greater than the liabilities sum
Everyone can perform this verification.
The cryptographic proofs, associated with a specific timestamp, are valid.
The values, public input of the proof, must match the actual balance of the user at the timestamp.
If verified by the user, the proof guarantees that they have been accounted for correctly (with the right balance!) in the polynomials and that polynomials were interpolated correctly, namely without any balance overflow during the summation.
The data containing the blockchain name, addresses, signatures, and messages are submitted to .
The commitment is to , which stores it optimistically.
Fetch the controlled by these at the timestamp. These can be done using any block explorer and querying for the balance at the next available block at the timestamp
Even if all the previous steps are verified correctly, there's still a risk that the Custodian has maliciously manipulated the liabilities. For example, excluding "whales" from the polynomials, understating user balances, or adding negative balances would result in fake liabilities sums. , you can find other common attack vectors on the liabilities side.
The only way to ensure this is not the case is to ask individual users to verify their correct accounting in the liabilities. Practically speaking, the Custodian, when queried by users, provides them with a zero-knowledge into the polynomials.
The proof is verified through a . It involves verifying that:
The rule is simple: if enough users request a Proof of Inclusion and they can all verify it correctly, it becomes increasingly likely that the Liabilities Commitment is valid. A more thorough analysis of how the number of users performing the verification influences the probability that the Custodian is cheating is performed in the paper .
