Discussion: AEZ Growth & the ATOM Alignment Treasury

[Noam]

Designing the Financial Infrastructure for AEZ Growth: the ATOM Alignment Treasury

Author: Noam Cohen, with support from Aleksandr Bezobchuk.

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

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.

[Spaydh]

Now that’s one hell of an essay. Thanks for putting it together @Noam, there’s too much to discuss here for me to reply at this time (3am ) but I’ll try to chyme in asap. Maybe we should organize a space to break these things down as well? Might help introduce some of these ideas and invigorate the conversation.

[Seppmos]

Amazing read, kudos to everyone who contributed to this essay.

I haven’t read a forum post with as much pleasure as this one in a while.
To mee it seems that the Hub has found a new direction and purpose, core values and clear objectives to pursue. I’m super aligned with the three stated objectives a) AEZ growth, b) Financial Alignment with Consumer Chains and c) Increased decentralization of the Hub’s Voting Power.

Also concepts and features such as the Atom Alignment Treasury, Liquidity as a Service, Token Swaps or active Treasury PF Management are compelling ideas and definitely worthwhile to further explore. For the first time I feel that the Hub is moving into uncharted territory, drives innovation and pushes the envelope.

We as the Cosmos Hub community can’t rest on our laurels and watch other protocols and chains out-innovate us. The features proposed in this essay have massive potential imo, and the Hub is in an unique position to execute on them. There are no other chains that have such a vibrant on-chain governance system in play and a high market cap to exploit ideas like LaaS or AAT to grow it’s very own ecosystem (AEZ).

I was not happy at all with the direction the Cosmos Hub was moving throughout the last two years. But now it seems that the tide has turned and were are moving away from an wait and see attitude and take on a more proactive approach to innovate the Hub out of its “purpose crisis” and make it thrive again.

This was only possible because the Cosmos Hub community had the courage to fund the AADAO and thus invest into it’s own future and growth.
Therefore I think we should keep investing into the growth of the AEZ and supporting the ideas and concepts proposed in this forum post are a first step into this direction.

How all of this should be implemented in detail, can be discussed at a second step.
For now, all I can say is that I strongly support this new vision for the Cosmos Hub.

[Wunderbernd]

Thank you for this very detailed post, it is so long, I think I will have to read it a couple of times to get a detailed picture

Lending Out Liquidity (Liquidity as a Service)
I really like this idea, liquidity is one of the biggest issues in the Cosmos defi ecosystem right now. It would be great if we pair ATOM with stables, BTC, other L1s and diversify the treasury. IF we want IBC to become the bridging standard for the blockchain ecosystem, we might want to think about building up a stake in other ecosystems.

As someone who is a defi degen since 2020 I saw and experienced a lot of hacks (especially in the ETH ecosystem), my question is how do we mitigate potential exploit risks? There is always a risk in Defi and if a pool gets exploited, we can lose the entire amount and get additional sell pressure.

So if we want to use this service, we need to implement additional security measures. Unfortunately I am not too familiar with the technical details, but in an ideal world it should only be possible to move the funds back to the specific hub address. To give you an analogy: If you are in a car chase and try to flee from the police, the only road which is not blocked, should be the road to the police station.

Active Portfolio Management

I am not a fan of active portfolio management. The insanity in the crypto space is limitless, we can reach absolutely insane prices. There is the risk that we cut our winners way too early and we put a resistance barrier on the token prices. On the other hand it makes sense to prepare for bear markets, so we should rather sell tokens at high prices for stablecoins.

So maybe we should just increase the percentages of Noble (USDC) during the bull market and increase the position of the other tokens during the bear. It should be much easier to plan future investments, the run rate etc. if you own a stablecoin stack

[Stride]

Intro

A huge thank you to Binary Builders for this thoughtful and detailed post!

We are strongly in favor of the three stated objectives in this post, namely 1) growing the ATOM Economic Zone through liquidity deployments, 2) financial alignment with consumer chains, and 3) increasing the decentralization of Cosmos Hub voting power. We are also broadly in favor of the strategies suggested to achieve these objectives. Now that ICS and the AEZ exist, Cosmos Hub governance should be more active and assertive than it has been in the past.

Start small

But what concrete steps should Cosmos Hub take today?

We believe it would be best for Cosmos Hub to begin by taking small, simple, well-defined steps - and then gradually progressing to some of the more advanced strategies described by the original post above. Beginning with small steps is the best way to build consensus.

Taking a quick look at the history of Cosmos Hub, the recent proposal to deploy 450K ATOM was the first Cosmos Hub DeFi proposal to achieve consensus. Previous Cosmos Hub DeFi proposals, such as the Osmosis proposal from 2021 and the ATOM 2.0 proposal from 2022, did not achieve consensus. The lesson here is clear: when it comes to Cosmos Hub actively participating in DeFi, small, simple, well-defined proposals have the best chance of success.

We believe that after taking a few small steps - and once it has been proven to everyone that Cosmos Hub can participate in DeFi in a safe, efficient, responsible way - then Cosmos Hub will be ready to pursue the full range of strategies discussed above.

Proposed actions

So again, what specific steps should Cosmos Hub take today?

1 - Deploy a meaningful amount of NTRN/ATOM liquidity to Astroport Neutron. Note that ATOM and NTRN already exist in the community pool, and Cosmos Hub already has experience deploying liquidity to Astroport Neutron.

2 - Deploy additional ATOM to the stATOM/ATOM pool on Astroport Neutron, to make the AEZ an even more attractive destination for upcoming LSTFi applications.

3 - Conduct a token swap with Stride, and deploy the resultant liquidity to an STRD/ATOM pool on Astroport Neutron.

4 - Persuade the Neutron DAO to combine its NTRN/ATOM and NTRN/USDC pools into a single USDC/ATOM pool.

Justification

These four steps would create this pool architecture on Astroport Neutron:

USDC/ATOM (owned by Neutron)
NTRN/ATOM (owned by Cosmos Hub)
STRD/ATOM (owned by Cosmos Hub and Stride)
stATOM/ATOM (owned by Cosmos Hub)
wstETH/ATOM pool (maintained with liquidity incentives)

In this pool architecture, ATOM is the common denominator for each pool. This gives ATOM continued relevance in the AEZ, and contributes to its quality of being money. Also, with ATOM as a common denominator it makes for efficient pool routing, as traders can do any trade with at most one hop.

In general, these four simple steps would add a huge amount of liquidity to the AEZ and would establish the AEZ as the proper place to trade all consumer chain tokens. With deep liquidity over a diverse array of interesting tokens, many more users and builders would be drawn to the AEZ.

These four steps would achieve the three objectives above in a simple and easy way:

Objective	How it’s achieved
Grow AEZ through liquidity deployments	A huge amount of liquidity is added to the AEZ, all of it paired with ATOM
Financial alignment with consumer chains	A token swap between Cosmos Hub and Stride, giving CH a stake in Stride. Would test the token swap idea in production. (Cosmos Hub already owns 5.5% of Neutron.)
Decentralize Cosmos Hub voting power	Stride protocol spreads the ATOM backing stATOM equally across the Cosmos Hub val set. So by providing liquidity to the stATOM pool and generally promoting stATOM, Cosmos Hub vote power becomes more decentralized*
Bonus objective: keep it simple!	No ATOM is sold, no ATOM liquidity incentives, all steps are clearly defined.

*For more info on this, check out this Stride forum post about host-chain validator selection. This other post is helpful, too.

Details

One big question is: how much liquidity should Cosmos Hub deploy with these four steps?

We believe most of the ATOM currently in the community pool should be deployed, as it is getting rather large and the current tax parameter of 10% is quickly filling the pool. For context, at the current rate, the community pool is filling at roughly 4M ATOM per year. Determining how much should be deployed to the various NTRN/ATOM, stATOM/ATOM, and STRD/ATOM pools still needs to be determined.

Another question is, what technical implementation should be used to deploy the liquidity?

In proposal 800, Cosmos Hub tested the method of using a multisig to steward protocol owned liquidity (POL). This method has proven to work very well. On the other hand, Timewave Labs has recently instantiated its Covenant smart contract system on Neutron. Covenant has been designed to allow the Cosmos Hub to deploy and manage POL without an intermediary. This is another strong option. Or perhaps a combination of both methods can be used.

Final thoughts

Despite being structured like one, this post is not a proposal! This post continues the conversation begun by the excellent post above by Binary Builders.

We expect this conversation to continue for the next few weeks, both on this forum and probably on X / Twitter Spaces. We look forward to continuing to participate in the conversation.

The awesome thing about Cosmos Hub is that it has always been comprised of many capable and diverse groups, making it seriously decentralized. With the advent of the AEZ, there are more Cosmos Hub-aligned groups than ever - which is certainly a good thing. It’s a pleasure to be a part of this decentralized decision-making process. We’re confident that if all groups contribute ideas and communicate, we can achieve consensus and continue to move the Cosmos Hub forward (:

All feedback on this post is certainly welcome. Let’s continue the conversation.

[jack]

Think that both @Noam’s post as well as the @Stride addition are great moves forward for the AEZ

[Noam]

Thanks @Spaydh! Would love to do a space of course. Need to give people some time to digest the forum post lol.

Let’s sync on TG.

[tom]

@Stride

to move the Cosmos Hub forward (:

omg i’ve finally found someone using “(:” as i do! \o/

great post, thanks Noam, and great answer from Stride.

will re-read all of this to see if i have something to add, but… glad we are moving forward that way.

for now i would say start small, with clear and well distinguished steps is the way.
and i’m really looking forward to what will be proposed to enhance the Nakamoto coeff of Atom chain.

Thanks again, this discussion is going to be very cool to follow.

[Noam]

Thanks for your constructive feedback @Wunderbernd! Just wanted to reply on the topic of security & volatility.

Security:
When lending out liquidity as a service, you can start with relatively risk free LPs like stATOM / ATOM, i.e. the pairs that are basically pegged to each other.

However, there is no way to de-risk from the protocol you’re using. If there was some kind of major hack on any of these DeFi platforms, then the assets the Hub would have posted there would be at risk.

Imo this reality requires a few things:

• Due diligence on every proposal. Never use unaudited protocols. Give protocols some time after launch before committing tokens. Most likely we’d want to get a DAO set-up with experts who deliver a report on each proposal, covering the risks and benefits that token holders might not have time to research.
• Diversification, don’t keep all your eggs in one basket.
• When possible, keep assets on the Hub.

Volatility
Yes, I think active portfolio management without any limits is a bad idea. However, there are ways to limit the downside risk by using concentrated liquidity on a DEX, or setting up custom logic. This could potentially also prevent cutting our winners too early, depending on the configuration we choose.

I don’t expect this to be a set of parameters that need to be actively managed by people, but rather an initial setup as part of the proposal. E.g. “let’s use 25% of our NTRN tokens & 5% of our ATOM in active management with maximum loss of 30%”.

Btw, the other module we’re designing is centered around converting tokens to USD during bull markets & visa versa, so I’m a big fan of your suggestion!

[Noam]

Thanks guys, appreciate the thoughtful feedback and great ideas.

I’m a big fan of starting simple and taking is as it goes. I think high level vision and conversation is necessary to help create a shared narrative around the Hub’s future, but I definitely want to avoid over-engineering something without seeing how things stick in reality.

I’m keen to see how the community responds to future proposals on using the Hub’s PoL. Your suggestion definitely has my support!

Practically speaking, I also see the AAT moving in small steps. Firstly just a slight modification to the community pool & gov module to enable multiple balances on the CP and some specific gov proposal types, then interfacing with something like Timewave’s covenants and other systems, all based on how we see demand arise and behaviour take shape in the AEZ.

[BendyOne]

Firstly I would like to say that I am delighted to see this sort of detailed thinking being presented - thank you Noam.

Secondly I would like to commend the Stride team in coming up with their suggestions.

I am always drawn to practical suggestions that push forward big ideas. It is better to take a good small step than wait for a large perfect one.

My own thoughts in response to Stride are as follows:
I think that moving towards further POL is useful in bootstrapping economic activity in the AEZ giving the community pool purpose while governance retains control of it.

While I think that there needs to be some further discussion about the quantities and the mechanisms involved, I would be in favour of starting with a relatively small investment in NTRN/ATOM that could be grown by future proposals - I suggest this as the hub has/will have both tokens but is not making that liquidity useful.

I am deeply in favour of a token swap with Stride (and indeed Neutron too) but appreciate that such a proposal would be more complex.

I am in favour of moving away from multisigs because we should be looking to minimise trust. As ATOM Accelerator we have funded work in this direction already both via Stride and with starting to bring DAODAO to Neutron. I think we would be supportive of continuing in this direction.

[jtremback]

I want to point something out, and this is something that @effortcapital pointed out to me-

Protocol owned Liquidity (at least using assets held by the community pool) is never going to drive a lot of revenue for the Hub in the form of direct fees, so it has to be applied in areas that have a lot of leverage for the Hub.

How much will AAT make directly? (not much)

Even with a heavy community pool tax lasting several years, the community pool is not going to have more than 5% of the supply of Atom in it. So any revenue from fees or appreciation will be on this 5%.

So for example, if the AAT is getting “Risk-free” yield of 8% (optimistically) from interest on loans, DeFi, etc., that’s 8% of 5%, or a yield to ATOM holders of 0.4%.

If the AAT is doing more direct investment where it takes a position on another chain’s tokens by buying them outright or LPing them, the ATOM token holders will still only be getting 5% of whatever the gain is, unless the community pool had more than 5% of the supply in it.

What should the aim of the AAT be then?

Due to the factors above, I think it is a very bad idea to treat the community pool as a VC fund or a money manager. It just doesn’t have enough capital to make a lot of returns. We can’t think about it in terms of dollars and cents. I also have serious doubts about the ability for an open governance process to outperform individual traders and investors in the market.

However, I am very supportive of the ideas put forward above by Noam and Stride. Why?

The AAT needs to be deployed in such a way as to put a “finger on the scales”. Even though the community pool is not big enough to make a lot of money in fees and appreciation directly, it can be leveraged to affect the course of events to accomplish two goals:

Help consumer chains win against their rivals

The AAT can be used to boost consumer chains. We want each consumer chain to be the top in it’s category. Deepening liquidity can help with this. The stAtom-Atom PoL deal that Stride put together is an amazing example of this, in that it boosts Astroport, boosts Stride, and is mostly risk free.

Help ATOM be used as money

The AAT can be used to make ATOM more likely to be used as money around the ecosystem. Things like deepening liquidity on ATOM paired assets, ensuring that any money market type DeFi protocols have a deep ATOM market, etc.

Guiding principles

• Don’t worry about how much interest something will earn, it won’t matter anyway.
• Worry about the impact that an AAT position will have on other participants in the market.
• It’s probably best for the AAT to have a neutral or even slightly negative rate of return if that subsidizes an early win for ATOM to become the dominant asset in a DeFi venue or a consumer chain against its rivals.
• Prefer “risk free” positions to direct token swaps or LP positions. This limits the downside of the AAT ensuring that it will remain relevant and powerful in the future. For example, instead of buying or LP a token directly, lend ATOM out at a zero or negative interest rate using that token as collateral for other people (or the token’s own treasury) to LP on those markets.

[Imperator.co]

I think we all agree that Cosmos lacks of DeFi interest and implication. The overall approach which is highlighted by @Noam is clear and will lead us to a brighter future for Cosmos. But, as @Stride mentioned, we should try to create a low-level executive plan and move forward.

Even if returns are " not much " deploying/managing liquidity and helping DeFi to settle could bring a lot of activity to Cosmos coming from other blockchain participants looking for opportunities.

The POL aspect of the plan is probably one of the best ways to align interest and provide value at a lower cost for the projects involved. I like to think about OlympusDAO which used this kind of initiative to bootstrap liquidity and create a robust ecosystem around them.

[Golden-Ratio-Staking]

Fully supportive of the overall message and direction that was put forth by @Noam!

Also fully supportive of the practical, digestible process set forth by @Stride!

Feels great to see some sort of consensus and direction, with actionable steps being proposed!

[VK_S16]

Thank you for posting this. Seems everyone is quite excited after reading it. Need to catch up soon!

[maximus]

Liquidity as a Service

Hey everyone, Max here posting on behalf of my team at Timewave. We’re a new team formed by several experienced cosmonauts, including Sam Hart (formerly Board of Management, Grants Manager, and Cosmos Stack Product at ICF), Udit Vira (Co-founder of Hypha), me (interchain maxi since 2017 and former financial services management consultant at Oliver Wyman), and several DAO DAO engineers. We appreciate the conversation that Binary Builders, Effort Capital, and numerous other Cosmos teams have kicked off. Timewave has been developing similar perspectives. We’re sharing some of those here so we can build upon each others’ ideas together with the community.

Since Binary’s original post above is open-ended, here we will attempt to complement that open-ended approach by providing an opinionated approach for the AAT. Also, since Stride’s post above provides a short-term approach, we will focus this post on a long-term approach. Our goal is to provide additional color on the potential for the Liquidity-as-a-Service (LaaS) point mentioned in the original post above and equip the Hub community with mechanisms and a narrative that could help make ATOM the preferred reserve asset of the interchain.

Background

Over the past year, we at Timewave have been exploring ways to increase collaboration between disparate internet-native organizations whether they be DAOs, dApps, protocols, blockchains, or a combination thereof. The first code to result from this explorations is what we’re calling Covenant v1, which is a set of smart contracts that will enable the AEZ to eliminate the need for the AADAO multisig to manage the Hub’s ATOM-stATOM LP position on Astroport and instead govern it directly via Cosmos Hub on-chain governance. Covenant v1 was audited by Informal with zero critical, high, or medium issues identified and is fully open source. We hope that the Hub will one day vote to migrate ownership of this LP position from the AADAO multisig to this set of trustless smart contracts, but let’s save that conversation for another day. Right now, let’s focus on LaaS.

Liquidity-as-a-Service (crypto-native market making)

Our work building Covenant v1 has led to our belief that that Hub’s core product is ATOM, that the Hub’s core business should be the lending of ATOM liquidity, and that the Hub’s existing and soon-to-exist capabilities (e.g. Replicated Security, token swaps, portfolio management, etc.) can be most optimally utilized by working in concert with LaaS.

What do we mean by lending ATOM liquidity (i.e, LaaS)? We mean a more sophisticated version of what the Hub is already doing with the 450K ATOM that the Hub is using to create an ATOM-stATOM LP position on Astroport. The increase in sophistication comes from mechanisms that would create market forces to determine the following:

a) how much ATOM liquidity is lent
b) to whom the ATOM liquidity is lent
c) how much interest is charged on the lent ATOM liquidity
etc.

Determining factors could include:
d) how much collateral is in place to absorb losses
e) how the liquidity is used
f) where the liquidity is deployed
g) duration of the liquidity loan
h) whether the borrower is secured by the Hub’s replicated security
i) how strategically important is the borrower to the Hub
j) conditions for automatic withdrawal
etc.

It is very important to note that in this case, the Hub is NOT lending ATOM—it is lending ATOM liquidity. This means that the Hub continues to own the underlying ATOM used for the LP positions. The risk that ATOM faces is primarily via impermanent loss (IL) and smart contract risk. IL can be mitigated by having the borrower put up collateral as a first lien against any losses. IL can also be mitigated by having provisions that automatically exit the Hub from a position in the event that IL has reached X% of the collateral, thereby ensuring that the Hub will be able to liquidate the collateral and exit the position before incurring losses.

The design space for LaaS is vast.

How LaaS supercharges Replicated Security

One might argue that the Hub already has a core business, Replicated Security. While we believe that Replicated Security is a step in the right direction, the fees from security will likely be a race to the bottom with competition coming from mesh security, Eigenlayer, and Babylon. Therefore, the Hub will likely need a means of differentiating its security offering from competing security offerings. Offering liquidity in addition to offering security is a key way for the Hub to maintain a competitive edge because the Hub has the deepest liquidity of any Cosmos SDK chain.

Combining security with liquidity is positive-sum. Not only does it help differentiate the Hub’s Replicated Security offering, it also helps differentiate the Hub’s liquidity offering. When the Hub secures a chain, the Hub can place security guarantees on loans made to the secured chain that enable the Hub to lend more liquidity at lower interest rates without taking on additional risk—competing liquidity lenders that do not have the extra guarantees that the Hub has (i.e., entities that are not securing the borrowing chain) would have a difficult time competing.

If/when liquidity lending becomes the primary business and security becomes a supporting business, the definition of what the AEZ is can expand to include not just chains secured by the Hub’s replicated security, but also include all chains, protocols, dApps, and DAOs that borrow ATOM liquidity. The Hub could prioritize lending to internet-native organizations that are secured by the Hub’s validators, but still make liquidity available for chains that are not Hub-secured. Non-Hub-secured chains would simply have stricter borrowing terms (e.g., pay higher interest, have lower borrowing limits, etc.). This flexibility enables the Hub to expand the scope and reach of its relationships, thereby avoiding alienating itself from the broader interchain by not being too biased towards chains that are secured by the Hub’s Replicated Security.

How LaaS supercharges swaps and treasury management

Similar to how we believe that LaaS could differentiate the Hub’s Replicated Security offering, so too we believe that token swaps and treasury management would be most optimally conducted when done in concert with LaaS.

Blockchains face structural disadvantages when it comes to participating in financial markets. The Hub, for example, would not only have its trading strategy fully public, it also requires a 14-day governance period to change its strategy, giving everyone on the internet the opportunity to front-run the Hub. In order for Hub to participate in financial markets without getting pwned, we must give the Hub structural advantages to counter the structural disadvantages.

A potential source of structural advantage for the Hub can come from battle-tested ideas from traditional finance: the capital stack. In TradFi, capital stacks often look something like this:

One way of viewing LaaS is setting the Hub up to be the provider of senior debt, the debt that is the first to get paid back in the event of things going wrong. There are a number of ways of achieving this. The simplest is for the borrower to put up collateral as a first lien against losses. Alternatively (or perhaps additionally), some DEXs might be willing to give the Hub preferred exit routes to ensure that the Hub can exit its position before anyone else can exit. An even more sophisticated option if the borrower is secured by the Hub’s replicated security is for the Hub to mint the borrower’s token and sell that token for ATOM until the Hub is paid back (note that this a nuclear option that should be avoided at all costs and should not be a default setting, but rather one that is consensually opted into). There are additional mechanisms available and we are not proposing the use of any at this time. The point is that Hub could (and probably should) act NOT like a high-risk venture investor holding tokens, but rather act as a low-risk senior lender.

Rather than having foreign tokens sitting in a wallet just waiting to get front-run, the Hub could exclusively gain exposure to foreign assets when that asset is paired against ATOM in an LP position (e.g., all exposure that the Hub has to STRD tokens could be in the form of ATOM-STRD LP positions). The primary decision the Hub would need to make is to whom it wants to lend ATOM liquidity and at what terms. The second order-effects of that decision might result in a token swap to acquire the necessary token pair for the LP position. The active treasury management the Hub conducts could be in the management of its LP positions, allocating additional liquidity to profitable positions and exiting liquidity from unprofitable positions. To the extent possible, the Hub could automate this core business by automatically increasing the ATOM available for lending (perhaps by carving off a % of inflation to go toward Laas), set functions for interest rates so that they dynamically adjust based on market conditions without additional governance intervention (Frax’s utilization function for interest rates could be a good starting point Interest Rates - Frax Finance ¤), and set conditions for automatic and gradual re-investment or exiting of investments that are performing well or not, respectively.

The design space for this crypto-native LP management is enormous. We support Binary Builders in their exploration for how the Hub should go about approaching this challenge via the AAT. We at Timewave would gladly build the tooling necessary to implement Binary’s/AEZ’s desired approach in a trustless manner.

Why the Hub is uniquely well positioned for LaaS

Bitcoin and Ethereum do not have on-chain governance and therefore cannot lend liquidity at the protocol level. dApps such as Uniswap and MakerDAO that have deep liquidity also have core businesses of trading and creating stablecoins, respectively, that they would likely prioritize over their liquidity lending business. As articulated above, the Hub’s existing and soon-to-exist capabilities (e.g. Replicated Security, token swaps, portfolio management, etc.) can be most optimally utilized by working in concert with LaaS. If the Hub chooses to use LaaS as the lens through which it determines its strategy, the Hub would be uniquely well positioned to win.

Lending liquidity is an especially good business for the Hub because borrowing liquidity is a voluntary action that the borrower would opt into, thus eliminating the need for the Hub to pursue coercive business practices.

Additionally, LaaS is a business that adheres to Hub minimalism because it can be accomplished without any additional machinery built on the Hub. The Hub would simply need to continue honing its existing core strengths by deepening ATOM liquidity, maintaining its strong validator set, and directing on-chain governance toward making prudent lending decisions.

The KPIs for LaaS: return on investment (ROI) and return on liquidity (ROL)

As Jehan has pointed out above, the amount of profit the Hub stands to make on LaaS appears very low when comparing returns earned on LaaS relative to all ATOM in circulation. We would argue that return on investment (ROI) is a more appropriate KPI and that an additional KPI to consider could be return on liquidity (ROL).

ROI

Assessing returns on LaaS relative to all ATOM in circulation is somewhat akin to a venture capital fund assessing its returns on a single investment against all of that fund’s capital. For example, if a venture capital fund with $1,000M invests $1M into a startup that 10xs in value, it would appear that this is a relatively lousy business for VC if it’s reporting a 1% return ($10M in returns divided by $1,000M in available capital). However, when the amount of profit is instead compared to the amount of capital deployed to earn that profit, the VC firm would report a 1,000% return ($10M in returns divided by $1M investment). This KPI is known as ROI, and is a more appropriate KPI than return on total capital available because it compares the returns earned on the investment exclusively against the capital sacrificed for that investment, excluding the excess capital that plays no role in this investment.

ROL

While ROI is an important KPI to consider to understand opportunity cost of capital, it’s often helpful to use several KPIs to understand how an organization is performing. In this case, ROL (profit divided by loss) could be a valuable KPI to consider. Lending ATOM is different than lending ATOM liquidity. When a VC invests $1M in a startup, the VC no longer owns the $1M. The $1M appears in the denominator for ROI because it is the amount of capital that the VC had to sacrifice in order to gain the upside. When the Hub lends ATOM liquidity, the Hub still owns the ATOM. When choosing a number for the denominator, one could use the amount of capital that the Hub had to sacrifice to gain the upside on the investment. The ATOM sacrificed would most likely be in the form of impermanent loss (and/or smart contract failure). If the Hub were to lend $1M in liquidity, receive $10K in profit, and incur $5K in impermanent loss, the Hub’s ROL would be 100% (($10K revenue minus $5K IL) / $5K IL). When viewed from this perspective, liquidity lending becomes a powerful driver of value to ATOM.

Various KPIs give different perspectives on the health of an organization. We are NOT proposing that ROL be the only KPI used. Instead, we are inviting the community to consider it as one of the KPIs used to understand the power of LaaS.

Stride’s proposal as a good set of first steps

LaaS is an ambitious idea. If successful, it could make ATOM the preferred reserve asset of the interchain. Even if we are right about LaaS being the Hub’s optimal long-term strategy for value accrual, the design space is enormous so we are in favor of taking small steps toward achieving this vision.

That is why we are broadly in favor of the immediate steps that Stride has proposed. We as a community will need to set mechanisms for determining appropriate properties of the various ATOM lending facilities (e.g., amount lent, fees, collateral, etc.). Even if the profits the Hub earns from lending liquidity are small to start, simply establishing the economic relationships and proving the reliability of the mechanisms that enable the trustless management of those economic relationships would support the narrative of ATOM as the preferred reserve asset of the interchain, which would be a powerful meme.

We at Timewave hope to have the opportunity to collaborate with Stride, Neutron, the Hub, and future AEZ participants to help determine appropriate properties for the ATOM liquidity credit facilities and build the machinery necessary to manage the liquidity trustlessly.

Conclusion

This post builds off of ideas proposed by Noam at Binay Builders, as well as replies from Stride, Jehan, and others, by sharing Timewave’s perspective on how LaaS could serve as a cohering force to optimally utilize Replicated Security, token swaps, and treasury management. We posit that LaaS is the Hub’s optimal long-term strategy for value accrual because it is a business that the Hub is uniquely qualified to excel at given its core strengths of 1) deep liquidity, 2) Replicated Security, and 3) active on-chain governance. We are not proposing any specific liquidity credit facilities, but rather putting LaaS forward for consideration as the Hub’s north star. We are broadly in support of Stride’s proposed liquidity facilities and support Binary Builders in their furtherance of this discussion. Let’s make ATOM the preferred reserve asset of the interchain!

P.S.

At Timewave, we are building the tools that will enable blockchains, protocols, dApps, DAOs, and other internet-native organizations to permissionlessly and trustlessly enter into economic partnerships with one another. The Hub is uniquely well positioned to benefit from these tools, but it is not the only entity that stands to benefit. If you are a part of an internet-native organization seeking to create trustless economic relationships with other internet-native organizations, we’d love to hear from you: @TimewaveLabs.

P.P.S.

The principle of “strong opinions weakly held” applies to this post and all future Timewave posts. Feedback welcome.

[vixcontango]

Great stuff. All of this can run on Neutron. There is absolutely no need to complicate the Hub technically now that you have Neutron.

This Treasury functionality should be limited to the AEZ. Cosmos needs some sort of a “walled garden” to generate value for ATOM and its investors. Then that value can be used to finance services for the interchain. Cosmos has had the opposite approach for the past 5 years and I don’t think that is working. I mean free is a good way to get market share, but ATOM will head straight to zero if it doesn’t have value accrual mechanisms. I feel like Cosmos’s great devs are grossly underpaid relative to others in the crypto world given their impact. The reason is lack of a value accrual mechanism. People should get paid for the great work they do and for that you need a “walled garden” of your own.

If you want tomatoes, you need a garden

[Noam]

Thanks for this elaborate reply Max! I am curious to hear about more practical examples, especially within the context of borrowed liquidity and how the Hub could set requirements such as the interest that is charged, or how it would enforce its senior debt position.

In my mind, two use cases seem apparent for V1 of the AAT:

• LPs like stATOM / ATOM or amATOM / ATOM with little to no impermanent loss (relatively risk free)
• LP positions like ATOM / NTRN as a way of bootstrapping liquidity while maintaining an active portfolio, using concentrated liquidity to minimize IL at the extremes.

I am wondering what other specific cases of borrowed liquidity you have had in mind that made you consider focussing on the security guarantees the Hub could place on these loans.

On a side note, I actually fully agree with @jtremback in that this is not about ROI, (or ROL), but rather a tool to further increase alignment and bootstrap liquidity in the AEZ. I want to stress that the primary function of the AAT is not direct revenue generation, but rather reducing the economic friction and increasing the attractiveness of the DeFi landscape in the AEZ as well as making ATOM the preferred currency in the Interchain.

[BlocksUnited]

Sell 1/3 on a triple and let the rest run with a trailing stop loss.

[BlocksUnited]

BOOM! Love this extrapolation.