Protocol Flow

1. Liabilities Commitment

The Custodian must provide the commitment proof that based on snapshot of its liabilities to users.

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.

The Custodian must publicly share the commitment, which becomes immutable once published. In previous versions of Summa, we provided a Summa contract for this purpose. However, in V3, the Summa contract has been removed due to the absence of a verifier for the commitment proof. Therefore, the Custodian needs to find an alternative method to publish the commitment transparently, similar to the on-chain method used previously. One possible solution could be to upload the commitment proof on IPFS, which is often described as having immutable characteristics because once data is uploaded to IPFS, it cannot be changed.

Upon receiving the commitment proof, users should verify the total sum included in the commitment proof. However, this relies on an optimistic approach to validate the total sum provided with the commitment proof. More specifically, as was done in Summa V2, users should fetch the Custodian's account information from on-chain and then check its balances at the snapshot time. While this may seem to require professional expertise, we believe that users can compare the total balance through several third-party on-chain data providers that serve this total sum of balance information, even if the user is not a professional.

Thus, at the end of the commitment phase, the user should be able to view the commitment proof in a public space prior to receiving their individual inclusion proof

2. Inclusion Proof

Even if the previous step is 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. Here, 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 proof of their inclusion into the polynomials.

3. Proof Verification

The proof is verified through a verifier. It involves verifying that:

• The cryptographic proofs, which is publicly commitment, 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 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 Generalized Proof of Liabilities - Ji and Chalkias - Section 5.