Settlement Contract Buffers

Technical
1

Context

On November 8th, 2024, the GlueX Protocol suffered an exploit via one of the contracts onboarded to lower the execution cost of swaps against a specific type of DEX. The attack vector allowed any address to transfer collected fees out of the settlement contract. This exploit resulted in a substantial loss over the span of one hour, which is how long the attack vector remained open. The size of the losses would have been catastrophic to the solver involved if the attack vector would have remained open for a longer period of time.

This is not the first time solvers have faced the reality of the risks involved with the CoW Protocol holding fees in the settlement contract(see Barter’s Exploit).

While in both cases the exploit resulted from smart contracts deployed by the solvers, the reality is that every liquidity source integrated by a solver increases their risk of being liable for a similar attack. To date, most liquidity sources that can be integrated by solvers have been heavily audited and battle-tested. However, as more diverse liquidity sources emerge (e.g., with Uniswap V4 pools) and DeFi evolves, the risk of integrating an exploitable liquidity source increases.

In theory, it is the responsibility of solvers to audit every contract of new liquidity sources to which they will be granting allowances; however, the reality is that solver teams may not have the knowledge, funds, or resources to execute such audits at the same pace at which DeFi evolves. On the other hand, it is in the protocol’s best interest to have solvers onboard new sources of liquidity as soon as possible to attract new business and support partnerships with other protocols (as was the case with the Maker-Sky migration).

Purpose of Post

With this post, we would like to hear the opinions of the core team and other solver teams:

  • Is this a risk that everyone is willing to continue taking?
  • What can be done immediately to fully or partially mitigate this risk?

The result of this discussion should ideally be a CIP to address this issue moving forward.

Preliminary High-level CIP

CoW DAO should limit the amount of funds available in the settlement contract to a maximum of $5,000 worth of any collection of tokens. Any funds exceeding this threshold should be transferred to a fee collection contract within the same CowSwap settlement transaction in which the fees are generated.

Note

We are very thankful with the CowSwap team for having recognized the attack vector as promptly as they did. Without their support at the time, GlueX Protocol would have experienced losses multiple factors larger than the losses incured.

4 Likes
2

I think there’s room for CoW DAO to explore a whitelist of audited and battle tested contracts that will be excluded from solver’s liability and be taken direct liability by CoW DAO.
Having said that, since launch there has been only two incidents and those were cause by flaws in SC deployed by solver teams themselves.
I don’t think there’s a way for CoW DAO to remove solver’s liability in similar cases or even WRT new and experimental liquidity sources.

The aspect of settlement contract buffers is also not completely straight forward and involves tradeoffs. Settlement contract buffers are useful for a number of reasons including mitigating tx reversions, and matching small user orders therefore saving on gas costs for the protocol and penalties for solvers.
Also with more frequent collection of fees there’s additional gas cost overhead, which again eventually makes CoW Protocol slightly less competitive.

All in all I think this is an important discussion to have, and looking forward to hearing more opinions.

3

Thank you @Filius for the post.

I want to first recap why these buffers exist in the first place: Users pay for their swaps in the sell token instead of requiring native ETH. This is a main selling point of CoW Protocol, but means that on every trade a fairly small amounts of random tokens are accrued in the settlement contract. Requiring this amount to be transferred into a “fee collection contract” would cause significant gas overhead and increase the cost of trades for users. Moreover, by growing the buffer of each token over time (ie many users selling USDC) the protocol can allow solvers to “internalise” certain smaller trades (pay the proceeds from buffer inventory) creating the most gas effective type of swap.

Now, I also understand that a large size of the buffers creates a big risk for teams operating a solver.

One thing we are envisioning for a v2 of the contracts is to have per-solver settlement contracts (and thus buffers) in a way that doesn’t cause any gas overheads. Note, that even today, solvers can mimic this approach by creating their own “trade handling contract”, which doesn’t have any allowance from the settlement contract, but instead receives funds via direct transfers (which again causes a gas overhead). This would fully remove the risk of bad allowances from a solver.

At the same time, I think it would be good to more formally define the process with which the DAO should harvest and withdraw fees. One thing to keep in mind is that this operation is rather costly (gas fees for placing the order, settlement fees + solver rewards). Currently this cost is born by the protocol and executed twice a week.

If we were to require harvests whenever a single token balances reached $5k (which may also be short lived given that buffers could be used for internal trades) we may look at very significant harvesting costs. At the same time having $5k of buffers in many different tokens can create similar total losses if an attack is executed strategically.

Looking forward to hearing more thoughts and I generally support formalizing this process in a sensible way.

4

I suppose we all agree that having a settlement contract per solver would be the best solution to this problem.

While this is not ready, I wonder if it could be emulated. Currently each solver receives a list of buffer amounts. Perhaps it would be possible to keep a list of fractions each solver holds of each token across the week, and send them only these fractions in the json.

Advantages:

  • Since each solver is now fully responsible to any loss in its own buffers, the protocol does not have to do additional conversion math at the end of the week.
  • Each solver can use the buffers as it see fit, no longer restricted to mimicking AMMs. This might allow the solver to sell a buffer “at discount” to minimize losses on a token quickly depreciating.

Disadvantages:

  • Maintaining the (token,solver) buffer balances sounds like a pain. Not sure if it is even feasible given the colocated infra?
  • Since the use of buffers is partitioned, I guess its overall use will be less efficient, compared to everyone pooling from the same place.
  • This sounds better for the protocol than for the solvers, at least because it creates another challenge for the solvers.

The last two disadvantages would also occur when each solver has its own contract, so we would be only anticipating the problems.

Apologies if I am missing some obvious drawback/impossibility.

1 Like