I know most of us who worked on ATOM 2.0 feel very exhausted and discouraged after prop 82. It’s shaken my confidence as to whether the Hub community is capable of constructive dialogue, or whether we’ve created a system where thoughtful people with good intentions are met with threats of violence. So while I appreciate AIB coming to the table, I’d recommend starting even smaller than what’s proposed here to begin rebuilding trust. My suggestions:
- Hold off on any conversation about forks of Tendermint or the SDK as they pertain to the Hub. If AIB wants to develop forks that’s their prerogative, but better to separate that discussion from any immediate next steps for the Hub as it will only serve to complicate matters at this stage.
- I can no longer speak to ICF spending on work related to the Hub, however given market conditions my expectation is very little will receive funding apart from the continuation of Interchain Security software development. Maintenance of the core software stack will constitute the majority of ICF’s 2023 budget.
- Let’s avoid any gov discussion whatsoever on Telegram/Discord for the next few months. Keep discourse to the forum and more tightly moderate this space for productive, civil discourse.
- Scope the discussion down to a single go to market motion for Interchain Security, which will necessarily touch on Interchain Security, Liquid Staking, and the constrained use of Community Pool funds, which will likely necessitate simple utilities for capital allocation.
- Interchain Security - Focus should be on a smooth upgrade process, a clearer SLA between the Hub and consumer chains, and a discussion with validators about the real costs of validation and how to ensure a significant excess of >2/3 of validators by stake remain profitable. I continue to have doubts about the viability of ICS alone for generating sustainable cashflows, security will be sufficiently commoditised to push margins to near zero. That said, I have very little interest in relitigating this thesis at the moment. Others can revisit at a later date.
- Liquid Staking - Because the strongest demand for Interchain Security currently comes from Liquid Staking protocols, liquid staking security will inevitably be a key aspect of the discussion. Everyone is in agreement that liquid staking brings risks, so the emphasis should be on practical mitigation given wider market forces.
- Community Pool - If the proposal to increase the Community Pool tax to 10% passes there needs to be a more coherent plan for how these resources will be deployed + further social and architectural constrains to do so. As evidenced by prop 89 (no matter your feelings about the merit of the prop), it’s clear the community has no coherent framework for evaluating spending or negotiating price. I believe working backwards from projected yearly aggregate flows into the community pool and dividing into percentages dedicated to engineering, consumer chain partnerships, ATOM liquidity, marketing, etc. is the correct approach. Prior to putting prop 82 up I had a number of very constructive conversations with DAODAO and would highly recommend inviting their involvement in the deployment of any capital management system.
- (Minimal) Allocator - Fund the development of smart contract components necessary for Hub governance to perform simple escrowed trustless swaps with consumer chains, interconvert between native and liquid staking tokens, LP, and unwind IBC paths before settlement. Allocation can be done trustlessly via message-based governance and utilised to align ICS consumer chains while deploying ATOM more widely.