ATOM Tokenomics RFP: Designing the Financial Infrastructure for AEZ Growth – the ATOM Alignment Treasury

Over the past few months some very interesting ideas have come up around how the Cosmos Hub can support the ATOM Economic Zone (AEZ), how it should utilize its available funds, and how we can do so sustainably without generating significant selling pressure on the ATOM token. In this forum post, we’d like to start brainstorming about how we can create the infrastructure to enable this in a more structured manner. The designs we’re approaching fall under something we’d like to call the ATOM Alignment Treasury (AAT).

But first, a little about us: our company Binary Builders is the primary development team for the Cosmos SDK. We also run the Interchain Builders Program on behalf of the ICF, started a data analytics firm called Numia 4 and have been a validator on the Cosmos Hub for several years now. We recently received a grant from the AADAO in order to research, design and propose several modules that would benefit growth of the AEZ and help the Cosmos Hub reach a more mature and financially sustainable future.

This forum post covers just one of the modules we’re designing. We’re sharing this early because we want the design process to be transparent while we’re also looking for early feedback to our preliminary thinking.

This post was first published on the Cosmos Forum. Be sure to join in on the conversation on the forum.

Objectives

At a high level, we might be able to start discussing a few objectives that the Hub community can potentially (and hopefully) align itself on:

• AEZ Growth: The Hub has funds that can sustainably be used to grow the AEZ and should do so when possible. Here we are not referring to investments or grants, but rather things like providing liquidity on DeFi protocols, where the Hub retains its funds and even earns a yield in the long term, to give ATOM a sustainable value accrual mechanism while also making ATOM the default currency within the AEZ.

• Financial Alignment with Consumer Chains: Although both the Hub and its Consumer Chains have a strong indirect alignment, they do not have an actual stake on each others’ networks that allow them to vote on meaningful proposals that would significantly impact their future. Ideally we can move to a scenario where this is enabled. This also more directly enables value accrual to ATOM in case consumer chain tokens become highly successful.

• Increase Decentralization of the Hub’s Voting Power: With ICS increasing the operational costs, validators on the lower end of the active set are struggling to financially keep up in the bear market. We have considerable ATOM on the Hub that’s sitting idle. Ideally some kind of automated delegation program could allocate more stake to all validators based on their voting power, with a slight offset to the lower validators in order to increase their income and voting power and further decentralize the network.

Use Cases

If these are objectives that we can align on, then let’s start by looking at a few use cases that play into these objectives that could use better infrastructure.

Consumer Chains <> ATOM token swaps

Imagine that a Consumer Chain candidate or a protocol on Neutron that is launching a token is interested in joining the AEZ and forging a strong partnership with the Hub. It wants to swap tokens with the Hub in order to formalize an incentive alignment and to share voting power on each other’s networks.

They can elect a committee to hold these funds in an escrow to facilitate the transfer, but they seek a more trustless manner to do so. Furthermore, they have specific requirements for the swap such as a specific lockup period, which is not supported in the current community pool. They also are unclear where these assets should go on the Hub. Because these tokens cannot be vested in the community pool, and they fear selling pressure, they could opt for a committee to hold these funds, but the Cosmos Hub community might not be comfortable with a committee holding these tokens. Additionally, these tokens could potentially be used to earn a yield through staking or liquidity pools, but there is no mechanism in place to do so.

Injecting Liquidity in AEZ projects

Recently the Hub approved the usage of 450,000 ATOM from the community pool to be liquid staked on Stride and LPed on Astroport. This benefits both Stride and Astroport because of the increased liquidity, but also ATOM in a direct and an indirect way. Directly through the rewards that are generated by this position, and indirectly by supporting these AEZ projects in their growth.

The beauty here is that this did not cost the Hub anything. We are able to get out of this position at any point in time, and no funds are lost.

The process around this was unfortunately still a manual one, with the AADAO having to manage these funds and perform the liquid staking and LP actions manually through a multisignature wallet. As more projects and DeFi primitives join the AEZ, and as we strive towards a more trust minimized future, automating this process can help us both be more efficient in our support, as well as more effectively allocate (or unallocate) future positions.

Receiving Payments from Consumer Chains

The unclaimed tokens from the Neutron airdrop are set to be donated to the Cosmos Hub’s community pool in the near future. With ~45,000,000 NTRN tokens sitting at ~14 Million USD at the time of writing, and representing 4,5% of the Neutron’s total supply, we currently do not have an effective way to utilize these tokens. ATOM holders might want the Hub to use its voting power on Neutron to vote on an important proposal, or lend its liquidity to Astroport or Duality in order to make trading on the platform more attractive.

Currently, these types of actions would have to take place via governance and would require either a lot of different proposals for each transaction, or a committee that’s entrusted to manage these tokens. As more projects join the AEZ, the former would become too overwhelming for the Hub’s governance system, while the latter option is highly centralized and brings legal risks to the committees managing these funds.

Potential Solutions

When designing a system like this, you can divide the work into several components. I’d like to go over these and suggest a few ideas on how to potentially approach them.

1. The allocation and placement of funds

We believe that this treasury should be part of the community pool, but are also keen on exploring ways to expand the community pool’s infrastructure to create separate buckets that are managed independently. This idea is actually a very basic accounting principle: instead of having one bank account for everything, you have separate accounts for daily spending and savings.

In such a framework, the community pool can be understood as having a spending account (for grants, one-off payments, etc), and an alignment & savings account (the AAT). Community spend proposals would specify which account to take from, and complete community control would be maintained. If the community decides to use some savings, funds should be able to be directed from the AAT back to the spending account for example.

When it comes to the allocation of funds to the AAT, there are a few options to explore that can complement each other:

• An initial bootstrapping from the community pool
• A regular allocation through inflation
• A regular allocation based on revenue generated from other features like ICS, a liquid staking tax, or future infra products that the Hub might choose to run

Each of these options will require separate dialogue and governance proposals.

2. The mechanism to express how to manage these funds

A core value that we believe the Hub should maintain is the direct access of 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. The decisions on how to allocate funds, and how to manage them should be up to the community at all times. How would we go about this?

The Hub might want to express a desire to allocate a percentage of this fund for a token swap with Neutron, or for a liquidity pool on a DEX. It might also want to express a desire to maintain a constant percentage of Stride tokens in relation to the total value of the AAT. How would we express such desires?

• Token Swaps: A Consumer Chain (potentially together with other stakeholders) would make a proposal to the Hub signaling they wish to swap a certain amount of ATOM for the Consumer Chain’s native token. This proposal would contain the amount of tokens, which escrow account to deposit them in, as well as a vesting schedule associated with it if desired. Meaning that these tokens would be locked up for a certain amount of time. The community would then decide if these are acceptable conditions and vote on this proposal.

• Active Portfolio Management: Instead of just a one-time swap, ATOM token holders might want to express an interest to allocate a constant percentage in the treasury to a specific token, something like “we’d like to have 10% of the AAT be NTRN at all times”. With that expression comes the desire that if the total value of the AAT increases, the Hub would somehow acquire more NTRN tokens through some mechanism (below). If this is something the community is interested in, the Token Swap proposal can be expanded to include a desired weight as well. This would mean that after the initial swap is achieved, the portfolio would continue to purchase (or sell) tokens to maintain its balance. The benefit of this type of management is that if tokens in the portfolio suddenly start to perform well, there could be ATOM buybacks. Given a sufficiently sized AAT, this could help correlate the price of ATOM with the value in the broader AEZ.

• Lending Out Liquidity (Liquidity as a Service): This is a more complicated type of proposal. At its core it would be a proposal to use a certain amount of ATOM (or other tokens from the treasury) in a DeFi protocol such as Astroport. The Hub would maintain ownership of the tokens it uses to create the LP positions—the borrowing chain would pay fees (interest) to the Hub in return for the value that the Hub provides in helping to bootstrap the pool. This proposal would also need to contain parameters on which DeFi platform to use and how to convert tokens if the other half of the LP is missing (e.g. how to liquid stake ATOM for the stATOM/ATOM pool).There are likely other expressions as well, such as a desire for (liquid) staking, interest rate functions, or others. When it comes to these strategy proposals, we’d likely have to design a singular governance proposal where a proposer would select a strategy and then input the associated parameters. These proposals would point to a modular system that contains strategies in a specific structure.

3. The mechanism to execute these expressions

There are a lot of different ways to go about implementing the above. Instead of going too deep into a specification, we’d like to discuss a few high level suggestions that we hope would effectively help us reach some of the above mentioned objectives.

Token Swaps Between Consumer Chains & The Hub:

This is a relatively easy mechanism to implement. It would require escrow functionality on the Hub. A Consumer Chain would deposit tokens in the escrow account with an end date set right after the proposal voting period ends. Then a proposal to the Hub would be submitted for a swap. In case the proposal passes, ATOM is sent to the escrow account and the swap is executed. In case it fails, no tokens arrive at the escrow account and the tokens are returned after the end date.

A recent grant from the AADAO has been paid out to to develop escrow functionality and we should see if that specific implementation is suitable for this purpose.

Liquidity Bootstrapping & Other Strategies:

There are a couple different strategies that we might want to include here: providing liquidity on a DEX, (liquid) staking, lending and potentially others. As an initial version, we could simply assign a DAO to execute these while we work out an automated process.

Ideally we would design a modular system where actions can plug into each other. For example, let’s look at the recent allocation of 450.000 ATOM to provide liquidity on the stATOM / ATOM pool on Astroport. In order to achieve this, 50% of the ATOM had to be liquid staked and returned to the Hub. Only after this was completed, the ATOM and stATOM had to be transferred to Astroport and then deposited into the correct pool. How could we automate this process through reusable components?

Let’s use a diagram to explain:

1. First, through a governance proposal, a desire to LP tokens on Astroport is established. An ATOM amount is specified, as well as the parameters that go into a LP_1 module. After the proposal passes, tokens are directed to the LP_1 module that was instantiated by the Hub.
2. The LP module checks if it has the required assets in order to post liquidity to Astroport. In case it doesn’t, it sends over a percentage of the Base Token and sends it to the module that was specified to give it back whatever counter token is needed to complete its job. Because it only received ATOM, it sends 50% of that ATOM to the LSD_1 Module that it instantiated.
3. The LSD module sends the tokens to Stride using Stride’s autopilot over IBC.
4. Stride liquid stakes the ATOM tokens and returns stATOM to the LSD_1 Module. The module then checks if it received the counter token that was specified.
5. The LSD_1 module sends stATOM back to the return address that was specified, in this case the LP_1 module
6. The LP_1 module receives the stATOM and checks if it now has the correct balance to LP on Astroport. In case it does, it sends it over IBC to Astroport and deposits the funds in the specified pool address.

By using these blocks and allowing them to interact with one another, we can create a reusable plug-and-play system that can be utilized by the broader AEZ if desired. The portfolio management system could potentially plug into a swap module that interfaces with DEXes. When you put all this together, you are effectively building an intents system that allows the Hub (or others) to express intentions and have them executed across the Interchain.

We are leaving out some important implementation details here. Specifically around error handling, oracles, account ownership on other networks through ICA, and how Authz needs to be utilized to allow these modules to handle the Hub’s assets. For now we simply want to start the dialogue on whether this is an approach worth putting more research into.

More importantly, we want to stress the significance of Liquidity as a Service as having a potential for being a real, scalable and mutually beneficial business model for the Hub. One of the major pain points that the Cosmos ecosystem has historically observed is a lack of liquidity and market makers in the space. The ATOM Alignment Treasury has the potential to serve as a vehicle for liquidity provision in the AEZ which could foster and accelerate a more frictionless economy.

Active Portfolio Management:

Although this section goes relatively deep into implementation details, I want to stress that the active management of the AAT’s portfolio is less about a potential return of investment and more about obtaining sufficient liquidity to be lent out to enable growth and a more frictionless economy in the AEZ, as well as maintaining a significant stake in other protocols. If the AAT obtains more ATOM over time through revenue or inflation, or if the total USD value of the AAT increases through bullish price action, it would be helpful to have a mechanism in place to maintain certain desired portfolio distributions.

A simple version of a portfolio management system would have all assets in one vault and constantly make sure the correct percentages are maintained in terms of USD value. So for example, if you want 50% ATOM, 25% NTRN and 25% STRIDE and NTRN happens to increase in value, you would convert some to ATOM and some to STRIDE in order to balance it out.

However, this wouldn’t be the most optimal way to ensure that value increase in the AEZ drives back to ATOM. It would in fact also benefit the other tokens in the pool, because in this example STRIDE tokens would also be acquired.

As an alternative, we suggest splitting the treasury up into two vaults: the ATOM Vault and the Cosmos Vault.

Here’s a simple diagram visualizing how this would work. Keep in mind these are just random allocations. It would be up to the community to decide how to allocate everything through governance votes:

If more ATOM is injected into the ATOM vault through inflation, revenue or a one-time payment, ATOM would be used to acquire the tokens in the Cosmos Vault like this:

Similarly, if one specific token in the Cosmos Vault would suddenly perform well, ATOM would be bought back until value parity is reached again:

Given a sufficiently sized treasury, this could enable significant purchases of ATOM in case some of the tokens in the Cosmos Vault perform well, depending on which token acquisition mechanism we choose.

Because there are risks involved, it’s important to note that this balancing should have parameters set to allow for the disabling of certain flows. Perhaps ATOM holders are not interested in continuing to purchase one specific token and are happy with the amount acquired during an initial deposit or swap. Alternatively, maybe the community would like to wait until buying back ATOM until a higher value in the Cosmos Vault is achieved.

Some other questions that are still open are how to handle vested tokens in case projects are interested in lockups. Most likely the vested tokens would sit in a different bucket, still counting towards the total value of a vault, but unable to be utilized until unlocked.

More importantly, a suitable mechanism to acquire tokens needs to be explored. There are a few options available that enable the Hub to maintain direct access to the tokens, although they have significant trade-offs that need be to considered as well:

• Direct purchase on a DEX: This would entail the AAT module interfacing directly with a DEX, or leveraging an external service to execute swaps. Whether or not this can be done without significant price impact depends heavily on the size of the treasury & the available liquidity on these platforms.

• Auctions: Tokens that need to be swapped can be sold through an auction. There are some concerns with this approach: without sufficient demand, suboptimal prices may occur. Although we can set bounds to the auction, what do we do if tokens simply aren’t being swapped?

A more growth-enabling approach would be to deposit tokens into a weighted pool on a DEX like Astroport or Duality. Tokens in a liquidity pool are basically a way to automatically maintain a certain distribution of tokens. E.g. if NTRN token price goes up, you automatically get more ATOM tokens through the trading and arbitrage that happens on the DEX.

The benefits to this approach are significant: it reduces price impact between AEZ token sales by increasing liquidity, it helps ATOM become money as the preferred trading pair with the highest liquidity, and it enables a more frictionless economy in the AEZ, stimulating retail trade. However, this does set some limitations that are important to consider as well: it prevents the Hub in using the tokens for other DeFi primitives such as lending, but more importantly, it requires tokens to be liquid staked in case the Hub wants to maintain voting power on the networks within the AEZ, which is a contentious topic right now.

Potentially a combination of approaches are possible, or rather, only a small portion of the AAT could be enabled for active portfolio management. We would like to engage in an active dialogue on how to best handle these token acquisitions. Ideally we’d see third party service providers like in the AEZ like Astroport, Duality or Timewave come with proposals on how to approach this in the most capital efficient manner.

Implementation – Where do we run this?

We’d love to discuss the above ideas with everyone here. We want to make sure we are not spending resources on ideas that have no support in the community. As we are funded by the AADAO to do this research, we want to make sure that the money that was trusted to us is being spent wisely.

So before we go into more specifics on the above, we’d like to explore a few questions first. How would we go about designing and building these mechanisms? There are a couple ways we could approach this, and we are eager to hear more from you!

• Timewave’s Interchain Allocator on Neutron, which although still in early stages, is being designed specifically for the above use cases. It could theoretically handle a lot of the mechanisms that we outlined above. This could function using Interchain Accounts and Authz, giving their smart contracts authority to execute only a specific set of transactions from the treasury in order to automatically manage the portfolio based on the parameters set through governance on the AAT module on the Hub. If done in this manner, the funds would mostly stay on the Hub, and ATOM holders would continue to have direct access and would be able to revoke permissions at any point in time.

• This functionality could technically be executed directly on the Hub itself. This raises a few questions and might require CosmWasm to be enabled. Because this is a modular system that requires updates when there are breaking changes on the DeFi protocols we interface with, it would be very slow and ineffective to integrate these modules directly into the Gaia binary that runs the blockchain. So in order to make sure we can update these modules when needed, we need a fast development process that can upgrade dynamically without having to perform an entire chain upgrade.

• We can ask platforms to design and maintain certain modules for us. If Astroport wants us to provide liquidity on their platform, they can build direct interfaces with the Hub using Interchain Accounts.

Governance

Once the AAT has acquired tokens from AEZ protocols, it now has a stake in these networks. But how can it execute on this voting power? There are two paths to explore here:

1. The Hub casts a unified vote:

People could submit a new special type of proposal with a different threshold and voting period that would allow the Hub to vote with all its voting power on another network. This would be reserved for high impact proposals on consumer chains. Once threshold is reached and the voting period is over, the Hub could do two things:

• Cast one vote matching the outcome of the Hub’s special proposal.
• Cast a distributed vote matching exactly the voting pattern on the Hub’s proposal, but with all its voting power.

The benefits to this approach are that all voting power is used and that ATOM holders have more visibility on high impact proposals. The downside is that you are assuming that the threshold that was reached on the Hub for this special type of proposal is an adequate representation of all ATOM holders’ votes.

2. Each staked ATOM represents direct voting power:

This entails ATOM holders directly voting on these networks with their ATOM tokens. So let’s say the Hub owns 5% of Neutron. If you have 1% of ATOM, you have 1% of 5% of Neutron, meaning that your ATOM vote would count for 0.05% of the vote on Neutron. The benefit is that this is a more fair, direct and granular approach to voting on other networks. However, it limits the voting power that the Cosmos Hub has available. As the Hub’s special proposal’s voting period would have to be shorter than the consumer chains proposal (which might be shorter than the Hub’s anyway) we can expect a lower turnout and a less effective usage of the Hub’s voting power.

I want to stress that I do not think ATOM holders can be expected to vote on all of these proposals. But for really important ones this functionality should exist. For example, if a consumer chain is voting to leave the AEZ, the Hub should have a say in that decision.

Interchain Security Deals

A lot of dialogue has been had around whether the agreements we have with Consumer Chains are sufficient. Whether revenue share to users is the right path forward or if the Hub should receive these tokens instead, or whether the Hub should receive a part of the genesis allocation as an initial onboarding payment, for example. Although we take no stance on these in this forum post, we’d like to emphasize that the AAT would be an ideal vehicle to accept any tokens coming from Consumer Chains. This would allow the Hub to maintain a larger stake in these networks, as well as enable it to reach the above mentioned objectives more effectively.

Allowing users to participate in the AAT

Although this is completely optional, an interesting idea to explore is whether token holders might be interested in participating in this treasury by bonding whitelisted tokens in return for a stake in the treasury and the revenue that’s generated through these strategies.

While the AAT is being designed primarily to promote the growth of and alignment within the AEZ, the treasury also generates yield via LP positions, (liquid) staking, and potentially the rebalancing of assets within its portfolio.

Any interest of users to bond tokens would also increase the stake the Hub has in these other networks. If the community agrees on the active portfolio management mentioned above, any deposit of $ATOM, $NTRN, $STRIDE or others would mean the Hub as a whole would have more tokens and voting power available to it, further aligning the Hub with the broader AEZ.

Of course there are legal risks involved in enabling this functionality. We don’t believe this functionality is by any means a requirement for the success of the first version of AAT, but we would encourage further legal research being conducted for future versions of this module.

Conclusion

It’s important to note that this is a relatively modular system and as such we can leave out things, or add different features. The community might not want to enable other users to bond tokens, or it might not want to have a dynamic portfolio management system.

In the end, whichever solution we decide is up to the community. Whether to go with a module on the Hub to manage these funds, or have them sit somewhere else. Whether to use Timewave’s Interchain Allocator or to have a custom implementation designed to be run on the Hub or elsewhere.

There are a lot of things to explore and questions to seek answers to. What we’re hoping to get from this forum post is to have a discussion on all of this. Some questions we would love to discuss are:

• Are the above mentioned objectives aligned with the Cosmos Hub community?
• Are the solutions suggested reasonable approaches to achieve these objectives?
• Do we want to contain this alignment with just the AEZ or are we potentially interested in aligning ourselves with the broader Interchain as well? What about ETH or other ecosystems beyond Cosmos?

Of course, none of the above is set in stone, these are just our preliminary ideas. We hope that by starting this conversation at an early stage we can make sure to have a transparent process around the future of the AEZ and that the community’s opinion is taken seriously. We want to make sure that whatever design is proposed is one that we know has broad support.

Thanks for taking the time to read all of this! Any feedback on the above ideas is welcomed and encouraged

Also, big thanks to all the feedback and helpful discussions I’ve had with @effortcapital @Spaydh @jtremback @hxrts @maximus @Elijah @Riley & the Stride team and so many others.

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.