You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
A certain amount of "stable" asset (e.g. yield baring stable coin)
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.
The text was updated successfully, but these errors were encountered:
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
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
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.
The text was updated successfully, but these errors were encountered: