I’d like to share some thoughts on this issue, as it touches multiple domains.
In terms of goals, we need to remember that the primary goal is to reduce the v3 deficit.
Secondary goals should be far behind IMO.
In terms of implementation, I would prefer to have a less complex/involved implementation, as always.
I would also really prefer a permissionless implementation as it’s the most fair/decentralized option and I think we should stick to that.
In addition, I don’t think we should make a “gamble” for any token, as it might contradict with the #1 goal. I much more prefer a predictable execution.
My suggestion is to use a variation of Option 3 that @foxsteven outlined above:
- Function that trades each TKN for ETH on another exchange, based on a decentralized oracle such as Uni v2/3.
- Function that creates a Carbon ETH-BNT strategy (limit order) at current market price, based on the same oracle.
The reason for trading for ETH is to prevent lots of smaller (and less efficient) strategies on Carbon that might not get executed, plus it keeps things simpler, with a single pair that can be adjusted later on if needed.
This meets the following goals:
- Reduce the v3 deficit
- Simpler implementation
- Minimal gambling on one token or another
- Predictability
Remember one of Carbon’s main goals is to reduce v3’s deficit and most time/resources should be spent on that as opposed to on a previous iteration of Bancor - we should go with a simple approach that helps with the deficit and move on.