[PASSED] Development Approval Request for the ATOM Alignment Treasury

[Noam]

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 AAT is available on the forum here.

Authors: Noam Cohen & Facundo Medica / Binary Builders

Change log

• 2023-11-20 Created initial post
• 2023-12-08 Last Call. Added link to high level technical specification. Clarified that the deployment is contingent on a final governance proposal. Made it clear that the AAT is comprised of three individual modules.
• 2023-12-15 Proposal is on-chain here

Summary

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 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:

1. A consumer chain has a proposal up in the voting period
2. The Cosmos Hub uses Interchain Queries to periodically update it’s list of currently active CC proposals
3. 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.
4. 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
5. ATOM holders vote
6. 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.

[tanned]

Hello, up for it.

If aadao get renew, then this proposal pass. How long will it take to get first version of aaT?

Can we know more and less. how much ressources is needed ?

[Tricky]

Loving this idea, the voting mechanism especially. Would you say this is a replacement/competition for Timewave, or supplemental to it? We are already deploying liquidity and doing token swaps so this is a natural progression for the Hub’s POL. It shouldn’t be much of a curve ball to anyone.

Do you have any estimations of cost if this did end up as a community pool ask?

For the voting mechanism, this is very important to ensure proper say in consumer chains and open up governance participation. What about tokens that aren’t deployed as POL and sit in the community pool? Could the AAT track the number of said token it owns at any given point whether LP’s or not and enforce that voting weight to consumer chains? This needs to be standard for every consumer chain relationship. In cases where the hub has very little economic stake like Stride, it could also be negotiated to give a sizeable flat or dynamic voting % to the hub that is relatively tied to the economic value ATOM instead of their native token.

This will get tricky on when to include proposals and when not to. It can become subjective really quick. What if there was always a vote when there is weighted voting, and as votes come in from ATOM holders, their corresponding ATOM weight cast that weighted vote from the hub up until a 50% threshold at which then the entire amount is used as a weighted vote. Voting abstain instantly may also allow for some props to slide in that otherwise wouldn’t have reached quorum and can pass with a slim yes vote, possibly even used in a harmful way. I do see the problem of this becoming cumbersome, but maybe that is part of the value the hub brings, governance participation as a major stakeholders. This can also be something that sets apart some hub validators by actively participating in governance for the Hub’s CC’s. Not sure on the answer to this, but I don’t think a manual copy pasta with a higher deposit is the way to go. Maybe part of the work you are funded to do involves implementing weighted voting and the mechanisms required on the CC side to ensure it is implemented and in ways that work best with the AAT. It would suck to do all this work only to have the CC’s lack on that.

Considering the timing of making sure the prop is finished before the end of the vote and so many other parameters that could go wrong, its probably best to automate as much as possible to limit any mistakes. Seems like not a big deal but I raise you prop 818.

The Binary Builders team is great, appreciate all that you guys do.

[vixcontango]

Can this functionality be built on Neutron? I generally don’t like the idea of complicating the code base of the Cosmos Hub and opening it to attack vectors. All of the functionality described here opens up the Hub to multiple attack vectors (accounts doing liquidity management, voting, unstaking, etc). Other chains maybe affected by actions taken from the Cosmos Hub which then reflect badly on it and have to be fixed with governance proposals on the Cosmos Hub. I don’t think the Hub should be involved with account management - in any form.

[Govmos]

CONTEXT:

In response to the proposal regarding the Atom Alignment Treasury (AAT), we acknowledge the infrastructural solutions it aims to provide for observed challenges in the Cosmos ecosystem. The two primary issues addressed are the manual execution and management of liquidity deployment in the AEZ and the lack of a mechanism enabling the Hub to vote on critical proposals on Consumer Chains. The proposed x/aat module seeks to automate these processes, ensuring efficient liquidity borrowing and facilitating governance alignment between the Hub and Consumer Chains. Importantly, the proposal emphasizes the core value of maintaining direct access to the Hub’s assets, avoiding centralization in the decision-making process.

ANALYSIS:

Version 1 of the AAT wisely abstains from including logic for actively maintaining position sizes within the Gaia binary. Instead, it suggests placing this logic on Neutron, allowing for greater flexibility and responsiveness to changes in DeFi protocols. The proposal also recognizes the importance of account separation, particularly in distinguishing between treasury management and the community pool. This separation safeguards against potential centralization risks and aligns with the principle that assets belonging to the Cosmos Hub should be under its direct control. Furthermore, the inclusion of Timewave Labs’ covenant system for handling changes on Consumer Chains adds an extra layer of adaptability to the proposal.

It’s worth noting that the AAT’s decision not to involve committees or multi-signature wallets aligns with the principle of avoiding concentration of control within a small group of individuals, reinforcing the commitment to a decentralized and community-driven governance model.

CONCLUSION:

In conclusion, we express our support for the Atom Alignment Treasury proposal, particularly commending its emphasis on maintaining direct access to the Hub’s assets. The proposed x/aat module introduces crucial functionalities that address existing challenges in liquidity deployment and governance alignment. At Govmos, our experience in traditional finance makes us strongly aligned with the commitment to account separation between treasury management and the community pool.

–

We welcome this proposal with huge optimism and want to thank @Noam and @Facundo for the quality of their overall work for the Hub so far. Thanks for reading,

[Noam]

@Tricky

Would you say this is a replacement/competition for Timewave, or supplemental to it?

Absolutely supplemental. The AAT can handle very simple mechanisms like IBC transfers and bonding, but we can’t build out the logic on the Hub for swapping, or interacting with the plethora of DeFi protocols out there. All of that, and probably much more is in scope for Timewave. The AAT can be seen as a mechanism for the Hub to express itself, Timewave can be seen as the executing party.

@Tricky

Do you have any estimations of cost if this did end up as a community pool ask?

Tagging @tanned as they asked the same question. We would start development in Q1. The work shouldn’t take long, but it depends on resource availability when we’ll be done. Ideally we’d complete work between 3-6 months time part-time. Full time this would take ~2 months. We haven’t fully mapped out the costs at this stage and were planning to do so at the end of the year. This isn’t a funding request, but a sentiment check on the AAT itself, which is why we don’t have these numbers yet.

Besides this we’re also committed to developing the DRIP and another module in 2024. Each of these would be separate requests for funding and would total under a million USD I reckon (napkin math).

Now, on the more interesting design questions:

@Tricky

What about tokens that aren’t deployed as POL and sit in the community pool?

These tokens should sit in the AAT imo, not the community pool’s spending account. In my mind, because ATOM holders have the same control over the AAT as they do over the CP, the AAT is essentially an extension of the CP, with a more specific scope. This is not to say all assets in the AAT need to be deployed though! It’s just that we shouldn’t want to keep CC tokens in the Community Pool, as its scope is one-time grant deployments (more or less), and we likely don’t want to pay these in CC tokens because it reduces our alignment.

So, if there are bunch of Consumer Chain tokens there we don’t want to deploy, we can just stake them from the AAT if needed for using governance.

@Tricky

Could the AAT track the number of said token it owns at any given point whether LP’s or not and enforce that voting weight to consumer chains? This needs to be standard for every consumer chain relationship.

It’s hard to standardize this across Consumer Chains because voting systems differ (Stride uses Cosmos SDK’s x/gov while Neutron uses CosmWasm). This gets worse with increasing tech plurality. We haven’t fully mapped out yet whether if, and how, to calculate the voting weight. Neutron team has signalled they are willing to do some work on their end to accommodate. If anything, new agreements with Consumer Chains needs to include requirements to enable the Hub’s vote to be successfully cast on the CC.

This is one of those cases where we’re really going to need to see how this plays out practically. At a very minimum we want to make sure we can solve for our current issue (NTRN voting power), and iterate as use cases become apparent.

@Tricky

This will get tricky on when to include proposals and when not to.

I’m personally quite convinced that having every prop auto-copied to the Hub is a terrible idea as it will overwhelm governance and drown out actually important props. We should see how things play out imo. I have a feeling non-relevant props that are copied to the Hub will get no-with-vetoed. If not, we can explore other options.

@Tricky

Considering the timing of making sure the prop is finished before the end of the vote and so many other parameters that could go wrong, its probably best to automate as much as possible to limit any mistakes.

Yes, this will all be automated as much as possible. Essentially the “clone prop” transaction would require no input from the user if possible. However, this will depend on the IBC query implementation we choose due to potential metadata decoding issues.

[Noam]

Because of the governance aspect here, there is no way to completely run all logic on Neutron. Modifications will have to be made to x/gov in order to allow for custom voting periods, prop cloning would have to be handled in a front-end (which is not needed if done on the Hub only), funds would have to be streamed to the AAT periodically, requiring changes to distribution module. It’ll end up quite a Frankenstein piece of software that’ll be very hard to maintain as the SDK bumps versions over time.

More philosophically though, I think all of the Hub’s core functionality should sit on the Hub. As Liquidity-as-a-Service becomes part of the core offering it makes sense to have it on the Hub. It’s a lot of money being handled, it needs a secure place to do this.

[waqarmmirza]

It would be a great addition, and it is much needed I believe.

[vixcontango]

Consumer chains should implement a standard voting interface/API so that the Hub can vote. Absolutely should be part of the agreement.

[Noam]

Perhaps a voting API could be part of the ICS Consumer module?

Cc @jtremback

[Noam]

FYI, spec will be posted Friday or Monday, and will then also move this prop to Last Call before it goes on-chain.

[Ertemann]

YES!

We really need these tools to make ICS a larger success and the Binary team is more than capable enough to deliver this.

Ertemann - Lavender.Five Nodes

[Victor118]

This is a must have !
Does it means a proposal can incorporate several ICA message in a queue ?
Writing proposals will become a very technical job, a good UX to help writing proposal will be needed IMHO !

[Noam]

Technically any amount of messages could be executed in a queue. But it gets a bit tricky as we’re not building out elaborate failure handling. Basically if one message fails, the queue stops and a subsequent proposal is needed. As such, it’s not designed for complex stuff, but really just for simple things like sending tokens over IBC and then staking them on a consumer chain, for example.

Anything more complex, like swapping tokens, or adding to an LP position should be handled by a third party like Timewave.

Edit: Yes, UX will be important. At a first we’ll make sure to get some good docs out there with Gov examples when using the AAT. But ideally we’d have a website to easily construct Gov proposals.

[Better_Future]

@Noam

enabling of Interchain Accounts Controller module in the Gaia binary so that the Hub can create Interchain Accounts on Consumer Chains.

Excited about this specific improvement, there are other projects that need this capability as well, including DAO DAO deployed on Neutron to enhance Hub governance on behalf of Hub community.

[StakeLab]

One specific question about this funding:
Why not having it voted right now instead of waiting AADAO approval to get funded by them?
The subject seems very interesting and aligned with the Hub development and community should be more aware of it than just passing the governance and going through the DAO…

In support of this development module!

[Noam]

I mean, we don’t mind either way. I’m just under the impression that Hub Gov has signalled that small grants work (which is what this is) should go through the AADAO, and large funding proposals (like Informal & Hypha) should go through community spends.

I’m also in agreement with that distinction and delegation of responsibilities.

I don’t think it would make a big difference in terms of awareness whether this is a signal prop or community spend prop.

[Noam]

Last call! This will go on-chain next week.

We’ve added a high level technical specification here. This is simply a starting point and we’re very open to feedback! A more elaborate technical specification will be created once we enter development stage next year.

[jtremback]

@Noam sorry if I missed it above, but how does this interact with your work on DRIP? Is there some synergy? Can you do both at once?

[Noam]

Very little overlap tbh. We’d prefer to approach these as separate features. But ideally both launched in the first half of 2024 or shortly thereafter.

Third module we’re designing would leverage elements of both (queue system, ICA manager & oracle system).