This proposal and the research prior to it was funded by the AADAO. Although the design has changed significantly, the initial post outlining the long term vision of the ATOM Alignment Treasury is here.
This post was first published on the Cosmos Forum. Be sure to join in on the conversation on the forum.
This is a signal proposal requesting approval for the development of the first version of the ATOM Alignment Treasury (AAT) into the Cosmos Hub’s software known as “Gaia”. It is a sentiment check to see whether ATOM holders believe time and resources should be allocated to this project. AADAO has signaled their willingness to fund development of the AAT.
The AAT is an infrastructural solution to two problems we’ve observed in the wild already:
- Liquidity deployment in the AEZ such as the 450k ATOM in prop 800 can help bootstrap new protocols in the AEZ. These are not investments where money is spent, but rather a relatively safe borrowing of liquidity where the Hub maintains control and is always able to clawback its funds to the Community Pool. However, these proposals still have to be manually executed and managed by a multi-signature wallet. This imposes friction and unnecessary risks that can be avoided when automating the process.
- Alignment between Consumer Chains and the Hub is being formalized through measures such as Neutron’s airdrop to the Hub’s Community Pool. However, we have no mechanism in place that enables the Hub to vote on critical proposals on Consumer Chains. Ideally, ATOM Holders would be able to optionally vote on those networks with the full voting power the Hub has in the AAT.
The core logic of the AAT will be distributed in three independent and reusable modules. This is purely an infrastructural change to facilitate alignment within the AEZ and the use of Protocol Owned Liquidity (POL) in Liquidity-as-a-Service. This proposal does not favor any specific POL strategies to be deployed, nor does it request funds to be directed to the module at this point. Further requests for seeding the AAT through a community spend proposal or a tax rate will follow after the deployment of the module.
A final governance proposal requesting approval of deployment will be submitted once development work has been completed in the first half of 2024.
Governance Votes
The following items summarize the voting options and their significance for this proposal:
- YES – You agree that the ATOM Alignment Treasury should be developed by Binary Builders and that the problems outlined above require an infrastructural solution.
- NO – You do not agree with the development of the ATOM Alignment Treasury, or do not believe that LaaS or alignment between Consumer Chains and the Hub require changes to the Gaia codebase.
- NO WITH VETO – You consider this proposal (1) to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.
- ABSTAIN – You wish to contribute to quorum but you formally decline to vote either for or against the proposal.
What does the ATOM Alignment Treasury do?
At its core, the AAT holds funds to be deployed within the AEZ and any other protocol the Hub deems aligned with ATOM. It acts as a separation of accounting so that Protocol Owned Liquidity can be deployed and maintained separately from the Community Pool (CP). This healthy accounting separation will reduce the risk that the CP will be drained by multiple requests for liquidity deployment, and will guarantee funds remain available for grants and other required spendings.
As a core value, we believe the Hub should maintain direct access to its assets. We do not believe there is a future where a small group of individuals are managing assets that belong to the Cosmos Hub. There will be no committees or multi-signature wallets in control of the AAT.
The AAT module performs the following functions in three separate modules:
- Interchain Account Management: the AAT can create and maintain accounts on Consumer Chains so that it can perform transactions on these chains. Account creations will occur in one bulk governance proposal after deployment.
- Governance on Consumer Chains: the AAT periodically checks for active proposals on Consumer Chains using Interchain Queries and will maintain a list of props in the AAT. It will allow ATOM holders to “clone” critical proposals to the Hub, so that the Hub can vote on Consumer Chains with its POL.
- ICA Queue System: in case the Hub wants to perform relatively simple POL actions such as bonding tokens on a Consumer Chain, a queue system is needed so that we can batch non-atomic transactions in one governance proposal. The staking process would require an IBC-transfer and a staking transaction. This would currently require two governance proposals because the IBC-transfer needs a few blocks to complete. A queue system can handle these confirmations and dramatically simplify the governance process.
Version 1 of the AAT does not include any logic that actively maintains position sizes. As DeFi protocols change over time, embedding this logic inside the Gaia binary would be difficult. If any API-breaking changes occur on a Consumer Chain, it would take weeks before the Hub can make the required changes. As such, we believe this logic should sit on Neutron. Timewave Labs is building out a covenant system 4 that can be leveraged for this, which has been funded by the AADAO.
Additionally, this requires the enabling of the Interchain Accounts Controller module in the Gaia binary so that the Hub can create Interchain Accounts on Consumer Chains.
You can find a high level technical specification of the AAT here.
How does voting on Consumer Chains work?
If a consumer chain faces a contentious vote that would impact ATOM holders, it would be essential that we have the infrastructure in place to use the Hub’s voting power to cast a vote.
We cannot expect ATOM holders to be required to vote on every CC’s proposal, but for critical votes such as inflation rate or revenue share changes, the full force of the Hub’s voting power should be used.
The voting process would work as follows:
- A consumer chain has a proposal up in the voting period
- The Cosmos Hub uses Interchain Queries to periodically update it’s list of currently active CC proposals
- Any ATOM holder can create a transaction to clone a CC’s prop on the Hub. This should only be done for critical proposals as we do not want to burden the Hub’s governance system with unnecessary cloned proposals. As such, the deposit for these types of proposals could potentially be set to be much higher.
- The CC’s prop’s will automatically be copied in a new prop on the Hub and will have a voting period end-date one day prior to the end-date on the CC
- ATOM holders vote
- If quorum is reached, the Hub casts a weighted vote on the CC over IBC. This means that if the outcome on the Hub is 70% Yes and 30% No, the Hub uses its full voting power to vote 70% Yes and 30% No on the consumer chain
Counting voting power
In order to bootstrap liquidity, ATOM holders and Consumer Chains like Neutron might prefer to have the Hub’s POL deployed on liquidity pools such as NTRN / ATOM. This creates the problem that the Hub essentially loses its voting power. A mutually beneficial solution would entail changes on the Consumer Chain so that LP tokens can be bonded to the network and counted as voting power.
It’s important to note that there is no one-size-fits-all solution for this problem because governance systems will likely vary between CCs, as will liquidity deployments. As Interchain / Replicated Security matures, we expect individual use cases and their solutions to become more apparent. At the very minimum, the following vote casting mechanism should enable the Hub to successfully cast a vote, given a Consumer Chain’s willingness to customize the tallying of the Hub’s voting power.
The vote will be cast as a transaction embedded into an Interchain Accounts package, sent over IBC. This requires the submitter of the cloned proposal to include a tailored voting transaction as part of the ‘clone proposal’ message. This allows the AAT to remain agnostic to whichever governance implementation a Consumer Chain chooses to use. A future specification will explain how we handle cases where Consumer Chains have not enabled weighted voting, or have voting options that differ from the Hub.
Making sure we don’t affect quorum on Consumer Chains
In cases where the Hub holds significant voting power, not voting would negatively impact reaching the quorum on Consumer Chains’ proposals. As such, when an active proposal reaches the Hub through Interchain Queries, the Hub will automatically vote Abstain on each proposal, unless overridden by a cloned proposal. A default abstain proposal transaction would live as a parameter for each consumer chain.
Funding the Development
Binary Builders is committed to build out the AAT for the Cosmos Hub. We think the AADAO is the most suitable venue to fund this work and they have expressed willingness to continue funding the project. However, considering their mandate is up for renewal, we will wait to seek funding until after the outcome of their upcoming governance proposal. Alternatively we would request funds from the community pool through an additional prop at a later stage.
We will include an updated and detailed specification and supporting documentation upon completion of the first version of the AAT.
About the ATOM Tokenomics RFP
This post and research are part of the ATOM Tokenomics RFP by the Atom Accelerator DAO (AADAO). Binary Builders, author of this post, was one of three teams commissioned by AADAO to research potential tokenomic & decentralization tooling that can help improve the state of the Cosmos Hub. Learn more about the motivations for the ATOM Tokenomics RFP and a recap of the ideas generated.
