User fees are collected at the settlement contract. In some cases, solvers are allowed to use this “buffers” of internal liquidity to avoid routing the order to a DEX or MM. Settlements with internal liquidity are beneficial to the protocol in the sense that they would cost significanlty less gas to excute. An example of a settlement that used internal liquidity can be seen here.
Currently, solvers are only allowed to use internal liquidity if the sell token is present in the following list of whilisted tokens. At the moment, there seems to be no specific rules to onboard or drop tokens from this list. This could lead to a situation in which the protocol accrues undesirable tokens. Fruthermore, solvers may be forced to settle orders via DEXs or MMs; which may be better served with internal buffers. For example, in this settlement the solver had to ping an AMM to settle the order of a blue chip token with very small trade size. In that specific example, the solver had to make use of external liquidity because the token is not whitelisted.
Proposal
The proposal is to draft a set of rules to onboard new tokens on the list (e.g. total market cap, reputation, stable coins, …). The list could be updated periodically (weekly, biweekly, monthly) according to the newly defined set of rules.
Topics of Discussion
What are the requirements for a token to be included in the list?
Thanks for taking initiative on this! The ENS name that defines the trade-able buffer list is currently owned by the the same Safe that is doing the solver payouts.
I see two possible ways of curating this list
based on some criteria as you suggested (could be intrinsic, e.g. based on previous trading volume on CoW Swap, or extrinsic, e.g. based on some other token list or Coingecko top N tokens )
The ownership could be deferred to a committee that is trusted with curating an appropriate list
While two is maybe more “vague” and requires trust, it would allow to react to events faster (e.g. the fall of UST) than some more “algorithmic” criteria.
Thanks for raising this topic! Indeed, how to manage internal buffers is a huge topic that, if treated properly, could potentially lead to significant savings. We definitely have to be careful with this, as increasing either the size or diversity of buffers introduces significant risk.
One first step, in my opinion, would be to do an extensive analysis of all the data we have these last few months, and compute concrete numbers to show how much the protocol would save if the list of buffers was larger.
Having an algorithmic way of dealing with this would be very elegant, but also risky, as there are times (not often) where one has to react quite fast.
I have thought about this in the past but haven’t been able to come up with any reasonable solution.
Two things that come to mind. First, even if we decide on a dynamic list, i would still like this list to always be a subset of a closed set X (e.g., some set containing, say, 500-1000 tokens). This set X would only be updated via a vote or a committee, following Felix’s idea. And say that our current list is L. L is a fixed list that is the standard safe-tokens list of the 50 tokens we now allow, and is a strict subset of X. Given that, a toy rule could be to allow for internal buffer trading for tokens from X - L, only when gas price is larger than some number to be decided (which could be dynamic, e.g., compared to the last 24h avg price). The rationale being that we are willing to introduce some additional risk only if this leads to significant cost reduction per batch.
The above is just one thought. Would be interested to see what people think about buffers in general!