GM. Thanks for the quick reply.
I agree it’s important for the process to be open. I welcome anyone in the ecosystem to post other avenues for delegates to consider for both the frontend or the reward system.
Regarding the Merkl compensation. The one-time setup fee of €20k for going to an entirely new chain and €10k for a new Uniswap v3 instance on a chain they support were based on $250k of incentives. Since we’re discussing increasing the incentives, I spoke with Merkl about updating their pricing. They have offered a 25% discount on their base 3% fee for incentives distributed between $2.5m-$5m, a 50% discount on incentives distributed between $5m-$10m, and a 75% discount on all incentives above $10m in a 365-day period.
For the pools to direct incentives toward, ETH-USDC 0.30%, WBTC-USDC 0.30%, and USDC-USDT 0.01% would be the three anchor pools; then, a fourth pool could be considered if there is a popular chain-specific asset. For example, if we were to deploy this program on Polygon, a MATIC-USDC pair would be a good idea. Generally, we should stick with blue chips.
As for the Merkl configuration, I’ve been trying to gather some data points as there doesn’t seem to be a “best” configuration. Currently, the Uniswap Arbitrum Merkl incentives use a 1%-1%-98% (token0-token1-fees), which heavily directs liquidity toward the most actively contributing liquidity positions. That may be good for blue-chip pairs like the ones I’m suggesting. If you or other delegates have thoughts on the configuration, it would be great to exchange notes.
Now, for amounts, when in doubt, we should default to less rather than more for the program’s inception, but then, in exchange, we should be liberal in deploying the program. If we default with a lower amount, like $250k or $500k, but then decide for a specific chain to go with a higher number, it’s easier to go up rather than down.
You’re right that creating a new chain has never been easier. So, it will be key that delegates decide which chains make sense to deploy this onboarding package and which do not. Although, we should be hesitant to set hard rules like a TVL requirement. I suggest we leave it to chains to make their pitch to the DAO and for delegates to conduct their due diligence. Ultimately, this package is meant to be easily deployable to new chains, but changes could be made on a chain-by-chain basis.