No. Teams will already have to figure out how to perform revenue share for L2s and it can be fully automated.
Do they not bridge back the 10% of revenues owned by the multisig anyway? is it an issue of frequency?
I agree automation would be a more ideal resolution, but it does present other risks. Have we thought about how to manage JIT attacks, price slippage and cross chain arbs if buy backs and distro’s are all automated?
Consider a smal liquidity pool on ‘L2 X’. A big copper sale concludes and it’s revenue is used to auto buy back mist and drop it into the rewards pool. a well capitalised actor drops a large amount of liquidity before the distro, diluting all other holders and taking a significant chunk of rewards, and then removes liquidity after claiming.
another scenario is that no new liquidity is added to the pool and the buy back is done with significant slippage. if the L2 pool is arbed compared to L1 prices before LPs claim their rewards, the benefit of that buy back goes back to arb bot operators, not LPs. LPs are unlikely to claim their rewards quickly due to the crucible multiplier so this is a significant risk IMO.
You end up with liquidity that is proportionate to revenues on those chains, so it won’t be a big deal. Our community won’t be dropping 10 million worth of liquidity provision if there’s only 20K a month worth of revenue on Polygon for example. That’s actually the other really nice benefit of establishing a reflexive relationship between revenues on new chains/L2 and the community. Everything will auto scale and incentives will align.
I agree with the points on reflexivity, it’s a pretty cool mechanic. Assuming that liquidity provision is efficient enough to respond to scale of rewards I think may not be realistic, especially given the fact that copper revenues in particular are much more event based than continuous. I think the risk of JIT and slippage could be significant if we have strong auction revenue on an L2 that hasn’t got much attention from LPs as mentioned above. non sophisticated LPs are unlikely to react quickly enough to these events to reduce JIT, slippage and arb risks.
This breaks the reflexive relationship between our products on a particular chain and the community with skin in the game on those chains. It favors incumbents, and would discourage liquidity provision to new chains that have revenue because majority of that revenue will just go back to L1 whales.
Fair points, I think it favours new participants vs incumbents in terms of reward split, but this is mitigated if inflation rewards are only provided to L1.
I would point out that an automated system on many L2s probably benefits more sophisticated and well capitalised liquidity providers than your standard user. Having a simple way to participate and ensure you gain rewards is much more manageable than constantly monitoring where your LP would produce more revenue and moving it around accordingly. As mentioned above sophisticated actors can probably game the system especially as it gains more prominence.
Alchemist having to manage LPs across chains is more inefficient. How does one decide how much LP to provide. When does it make sense to reduce. When to increase it. What if the bet is wrong. Then that LP needs to be removed. The proposed solution w/ community participating in this regulates itself and auto-adjusts based on conditions. Is there revenue on that chain? What’s the opportunity like relative to other chains? What are market conditions like and what is the narrative? Etc. Alchemist “strategically deploying new pools” would only centralize control, decision making, and the administrative burden for a decision which the Alchemist community, through its actions, is more well equipped to make. Free markets always make the best decisions when compared to a central authority. By outsourcing these decisions to the community we’re building a resiliency into the system that auto-scales with demand, our presence, and our success on new chains.
True it does introduce an element of treasury management and multi-sig centralization. I think this is a trade off that is worth considering especially if there is not alternative method to reducing JIT, slippage and arb risks.
Ultimately I think whatever is decided should be tested out on one chain before being expanded to others. The automated approach does have positives but this proposal needs to consider some of the risks I’ve mentioned in more detail here, before it goes live. Otherwise they will only be addressed when these risks are actualised.