Skip to content

feat: On-Chain Bonding Pool Accounting #85

@fleupold

Description

@fleupold

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions