Performance-wise Summa only offers nominal improvements over its most similar product, Binance’s PoR system. Summa v1 improved the commitment generation time at the expense of a significantly longer user inclusion proof time. Summa v2 reduced the user inclusion proof generation time, but that tradeoff was a significantly increased commitment generation time and cost. Benchmark results can be found here.
We are hoping Summa v3 improves the time and cost of the commitment and proof generation.
In order to prove ownership of assets Custodians must reveal their onchain accounts. While many of these accounts can be conjectured through chain analysis, it is not common practice for exchanges to publish them themselves.
In order to truly cryptographically prove ownership of an onchain account a Custodian must generate a signature from that account. Summa requires signatures from every onchain account owned by the Custodian. For risk and security reasons exchanges often limit internal access to some wallets (”cold storage”) while keeping other funds more accessible (”hot wallets”). Publishing signatures from each new onchain accounts is not common practice for exchanges and would most likely require significant changes to internal key management protocols.
Implementing a product like Summa into an existing exchange platform requires upfront and ongoing resources from the Custodian. Besides users demanding it or government regulation (ie losing money by not implementing it) there is little incentive to adopt something like Summa. Post-FTX there was a movement for exchanges to say they were going to implement a PoR system, but most have yet to roll something out.
In order for a fully implemented Proof of Reserves system to work, users are required to actively check that their funds were included in the liabilities commitment. It is not sufficient for a Custodian to simply implement the system.
From an accounting perspective margin loans increase both assets and liabilities on paper. Summa operates on the basic assumption that users balances are static and should equal the exact amount they deposited. In reality user accounts can fluctuate above or below their deposit through margin and collateral services often offered by exchanges. Additionally, collateral positions, interest charges, futures trading, staking payouts and NFT’s all create more complexity not accounted for by Summa.
Custodians keep their assets in both onchain and offchain accounts. Because Summa can only account for onchain assets, it’s not possible to cryptographically prove a Custodians entire financial picture, because you’re always missing fiat balances.
In traditional PoR systems auditors perform a role of assessing multiple types of assets (onchain & offchain) and taking into account complex accounting practices commonly used by large international firms. By removing them, these complexities are moved onto Summa. In its current implementation Summa is not designed to account for these additional components.
Because it’s not technically possible to generate user proofs en masse, they must be generated upon request of the user. Because of this, the Custodian is able to see exactly which of its customers do or do not request proofs over time. That data, alongside other data it collects on its users, can be used to create a profile of users that may be far less likely to ever request a proof. This opens up an attack vector whereby the Custodian can choose not to include certain users funds in the commitment proof, thus lowering its liabilities. Summa tried to solve for this (making the incl proof faster to generate) but wasn’t able to find a solution.