feat: On-Chain Bonding Pool Accounting

Problem

The current way of creating a bonding pool is very basic. Solvers have to create a Safe which is owned by CoW DAO and deposit the required funds into it. The address that deposited the funds is then allowed to "vouch" for solver addressed, which consequently get added to the competition endpoint and are added to the authenticated allow list using a manual process.

This is not only cumbersome but may also create issues with regards to trust for these large amounts. A similar issue, with much smaller amounts, was faced during development of the MEV Blocker fee which lead to the creation of https://github.com/cowprotocol/mev-blocker-till

Suggested Solution

Introduce an accounting contract similar to the MEV Blocker fee till which allows bond providers to deposit a specified set of token/amounts into it. This set of allowed tokens and required amounts should be subject to change by CoW DAO or a delegated party. In order to be sufficiently bonded solvers require two components

1. A certain amount of "stable" asset (e.g. yield baring stable coin)
2. A certain amount of CoW tokens

Providers are allowed to vouch for a set of addresses which are then allowed to "solve" under their bond (replicating the concept of the bonding pool). It should be possible to efficiently check if a certain address is currently covered under a bonding provider (this check will be done by the settlement contract's authentication logic).

Bond providers can request withdrawal of their bonds with a specified time delay (e.g. 14 days) that should be long enough for the DAO to issue any bond seizure or penalty if necessary. Solvers operating under a bonding pool that is in the process of withdrawing funds should no longer be able to settle.

Acceptance Criteria

• Solvers feel comfortable depositing the bonded requirements into the proposed smart contract
• GPv2 Settlement contract's allow list check is based on the state of this contract

Discussion Items

It might be desirable to also map additional accounting details (e.g. payment of rewards, protocol fees) via this contract, although this functionality would be out of scope for the attached EPIC.

No implementation files or tests are named. Start by reading the proposed accounting contract requirements and the GPv2 Settlement contract's authentication logic, then determine how deposits, vouching, withdrawal delays, and coverage checks should interact. Done means the contract state drives the allow-list check and satisfies the listed acceptance criteria.