research(contracts): reduce accounting overheads

[mfw78]

Problem

With the advent of fee collection, accounting is increasing in complexity and workload requirements. Accounting requirements are being handled off-chain, in opaque processes and require human intervention / fund transfers on multi-sig wallets, amplifying human labour cost.

Acceptance criteria

• Central accounting contract, simplifying financial audit requirements.
• Vouching / bonding handled in contract.
• Partner fees handled in contract.
• Solver fees handled in contract.
• MEV Blocker fees handled in contract.
• Treasury auto-buyback module.
• Eliminate slippage accounting.

Details

Broadly the accounting requirements can be broken down into:

1. Bonding requirements + fees to be collected (such as block builders, or solvers). Fees are due payable at a regular billing cadence.
2. Fees to be distributed (such as partner fees) at a regular cadence.

Possible Solutions

• MakerDAO-style vat central accounting contract, adding accounting domain-specific contracts as authed on the vat to manage accounting.

  1. Fees due payable are automatically deducted from the bond, and if the bond falls below a threshold, automatically suspend the builder and/or solver.
  2. Fees to be distributed to partners are placed into a claim contract and retrievable by merkle proof.
  3. Auto-buyback module is able to pull from system surplus and support ERC-1271 to automatically buy COW (as an example).

• Maintain current Safes.

Research track

• Automation
• Protocol Security
• Decentralisation

[blacktieaccountant]

In my view, it should be an accounting module and a single contract, to ensure that new processes / payouts could be added as the Protocol continues to expand its products.

Solver bond - Would also see each individual solver bond being in a sub-address. This would first separate risk. It would allow for better reporting / accounting (e.g. what are actual DAO funds and what are "guarantees"). Would allow for transactions between the solver bond address and the settlement contract, making it easier to know what / why that transaction is being paid by the bond.

Automatic payout - This would be interesting, but the main painpoint today is "ensuring that the calculations off chain / Dune are what we are transfering to the solvers". Hence, either the calculations are done onchain and then a "payout" function can be called, or don't see how this would improve the process.

[mfw78]

In my view, it should be an accounting module and a single contract, to ensure that new processes / payouts could be added as the Protocol continues to expand its products.

This is what the vat is, in that it is essentially just a very simple ledger that allocates a type of collateral (read: ERC20 token type) to an address. Critically here, the address can be an EOA, a smart contract, or whatever. The vat also contains functions that allow for moving collateral (permissioned) between addresses, so that a permissioned contract that contains audited logic can fine a solver, or take payments etc, and the process that is executed is guaranteed by smart contract, emitted events that are easily able to be digested / understood.

Solver bond - Would also see each individual solver bond being in a sub-address. This would first separate risk. It would allow for better reporting / accounting (e.g. what are actual DAO funds and what are "guarantees"). Would allow for transactions between the solver bond address and the settlement contract, making it easier to know what / why that transaction is being paid by the bond.

Somewhat this is how it would work - there would be a "bonding pool factory", which allows users to create bonding pools - but these pools must be funded with a DAO-specified amount of collateral. Each of these pools then gets an address within the vat - meaning that fining / slashing modules would be able to then reach into their accounts and take actions if need be.

Automatic payout - This would be interesting, but the main painpoint today is "ensuring that the calculations off chain / Dune are what we are transfering to the solvers". Hence, either the calculations are done onchain and then a "payout" function can be called, or don't see how this would improve the process.

I think automatic payout is fundamentally wrong. This is very expensive to do (transfer costs) and really does not scale. Instead, off-chain accounting mechanisms are fair so long as they can be verified, so we should provide the queries that are required to execute them, and then verify them. Then from this, the accounting script would generate a merkle root (summary of all the payments to be done), with this merkle root being set in a payment distributor module that is attached to the vat. When the merkle root is updated, at the same time, with the increase in the payouts, it can automatically pull in the funds required from a "system" (read: DAO) address within the vat, so it can be sure to have the tokens to be able to pay creditors (solvers, integrators, etc).

What's extremely clear is the process of maintaining multiple safes per network, and increasing complexity with fee structures is overly burdensome and error prone, requiring far too much human interaction. It simply just doesn't scale and should be avoided.

[fleupold]

If I understand @harisang correctly, the main burden of the current accounting is the slippage calculation, which is brittle and needs frequent corrections/outlier cleaning. For this I hope v2 will move to per-solver trade handler contracts, so that solvers will be responsible for their internal buffers (further reducing the necessity of a high bond).

What remains is the accounting of how much rewards/protocol fees each solver is owed/owes. I agree that this computation should be off-chain (it may change relatively frequently and storing information on every settlement is gas inefficient). We already provide the queries for solvers to verify their rewards, but can probably package this up more nicely as part of general off-chain monitoring software.

As to whether accounting should be unified to a single chain, I'm not so sure. Some solvers may only operate on the chain they are solving (e.g. some cheap L2) and might not want to bridge back and forth their rewards from mainnet. Also, given that payouts have to be manually sanity checked individually per chain anyways, sending out 1 tx per chain doesn't seem to me like the main bottleneck (this would also mean accounting issues on one chain hold back payouts across all chains).
My hunch is that having a chain specific accounting module that together with a chain specific off-chain calculator can compute/expose everything needed to run CoW Protocol on the specific chain might be sufficient. This would also allow the DAO to outsource operation of the protocol sub-chain specifically.

[blacktieaccountant]

Multichain approach

After talking with @mfw78 , I think there is an understanding that mechanism should be on a per chain approach - as we need to be able to calculate performance on a per chain level.

Payment / calculation
Also think it is aligned that off chain calculation is valid, and that the output can be pushed onchain as a "bill statement" (e.g. MEV Blocker billing contract). The topic is, events with the "individual bill" needs to be visible on-chain (debt to party A, of amount X, of asset Y).
If we move from the current "push" method (team initiated) to a "pull" method (solver or partner initiated) of payouts, we should also have the distinction of "assets allocated" and of "free assets", so that we know at any moment what are the assets that are already commited to a third party.

[fleupold]

Potentially related to cowprotocol/contracts#85

[fleupold]

Discussed this with @mfw78 1:1 last week, but I think any single accounting contract architecture can be translated to a multi contract architecture which may allow for easier integration into existing infrastructure (read etherscan, cryptio, etc.).

I'd at least want us to explore the two isomorphic designs before making a decision on whether a single accounting contract is useful for our purposes.