Cosmos Hub

‍

1. Use Case 1 highlights an internal transaction within the Cosmos Hub chain. Currently, this may include token transfers between accounts, locking up and delegating stake, or withdrawing staking rewards. Each of these accrue gas fees to the Cosmos Hub validators. 
2. Use Case 2 highlights an IBC transaction being sent from the Cosmos Hub chain. This also accrues gas fees to Hub validators. An example of this may be sending ATOM to Osmosis, Juno, Axelar, etc. 
3. Use Case 3 shows an interaction happening on another app chain. This could include providing liquidity and earning yield on Osmosis, staking AKT on Akash,  or participating in a DAODAO community governance vote on Juno. This can be done from the Hub chain through interchain accounts, or by switching the wallet’s network to the specific chain. Either way, the gas fee will only accrue on the chain on which the transaction takes place.
4. Use case 4 involves a zone sending a balance back to the Cosmos Hub. Similar to Use Case 2, the transaction fees here accrue to the sender chain - and therefore not the Cosmos Hub validators. 

To better understand markets for ATOM, it is helpful think through these interactions in terms of what users are trying to accomplish and how interactions are combined in practice:

An investor wants to maximize yield on their ATOM. They notice that they could earn greater yield by adding liquidity to an ATOM/OSMO pool on Osmosis. In order to do so, the investor first needs to unstake ATOM on the Cosmos Hub (Use Case 1). They then need to transfer their assets to Osmosis through the IBC (Use Case 2). Once there, they can deposit their ATOM into the ATOM/OSMO pool (Use Case 3). Perhaps the investor does not want to incur the impermanent risk, or they would rather use their ATOM to influence treasury allocations on the Cosmos Hub. They would remove liquidity from the Osmosis Pool (Use Case 3), and send their ATOM tokens back to the Cosmos Hub (Use Case 4). They can then re-delegate ATOM on the Hub to participate in Hub governance (Use Case 1).

A voter wants to pass a proposal up for vote in JunoSwap Governance. They must first send their ATOM to the Juno app chain (Use Case 2). Once on Juno, the voter can use JunoSwap to exchange ATOM for RAW (Use Case 3). Finally, the voter then goes to the JunoSwap governance platform through DAODAO and stake RAW to vote on proposals (Use Case 3).

A Terra adopter wants to send assets from Akash to Terra. There is currently no direct IBC channel between those two zones. The Terra adopter can send assets to the Cosmos Hub (Use Case 4), and then subsequently to Terra (Use Case 2), effectively using the Hub as an interchain router. 

Findings on ATOM token utility and supply provide a higher level and complete overview of what users can do with the token and how current issuance rates are apt to affect the utility of current ATOM holdings.

Token Utility Findings

Token utility classifications  answer the question ‘what can the asset owner do with this asset’, and focus on benefits to end-users rather than benefits to the protocol. All classifications are based on a token utility typology of discrete utilities developed from corollaries from non-crypto environments. Classifications are based on implemented vs roadmap functionality, are non-exclusive, and are relative to the time of publication.

ATOM has three forms of utility:

Using ATOM for transaction fees for both native and outbound IBC transactions helps to prevent network spam. These fees also provide additional revenue for validators, though transaction demand would have to increase significantly for this to provide similar yields to inflation rewards.

Following conventions used in the design and maintenance of virtual economies, token supply is explained via three questions. How assets were issued, how much of it, and under what conditions is answered via initial distribution findings. How the asset supply expands over time is answered via source findings.  How liquid asset supply shrinks over time, either through usage and burn,  is answered via sinks findings, with the hard/soft distinction indicating which types of sinks temporarily lock up supply v. which permanently reduce it.

ATOM’s inflationary supply gradually transfers wealth from those who do not secure the network to those who do through its distribution of block rewards to its validators and delegators. The heavy net inflation of the asset suggests that, in a steady state, ATOM’s price will fall year-over-year. This will ultimately reduce the dollar value of block rewards, resulting in the increase in reliance on revenues from transaction fees in order to maintain validator profitability.

By maximizing staking rewards at ⅔ of the total supply locked, the system optimizes for not only high security through bonded tokens, but also incentivises for share of highly liquid, high velocity unbonded tokens. In design, optimizing for a quality can be to choose to prioritize one quality valued over another, and, Cosmos’s case, security is the tradeoff for liquidity. If the system incentivized everyone to stake successfully, then the chances that anyone could acquire tokens (for malicious purposes or not) is zero. This would be extreme security but also impossible liquidity. Two thirds was likely chosen because that is the number of honest actors required under BFT for the network to be secure against attack.

The ATOM2.0 proposal, which still remains to be the dominant vision for the future of the Cosmos Hub even though the initial proposal failed, ideated several changes to the supply and rewards mechanisms of the ATOM token. This includes an initial increase in emissions (4M ATOM, with up to 10 additional tranches of 4M ATOM), to bootstrap a new treasury, used for the interchain allocator and ecosystem initiatives.  That being said, eventually emissions would see an overall decrease to 300,000 ATOM per month - as opposed to the 7-20% variable annual emissions schedule the network currently utilizes. Controversially, these new emissions would not go towards the security subsidy (Validators + Delegators), but rather to the treasury as long as the staking ratio remains to be greater than ⅔.

Design of token utility (which includes forms of utility not opted for) are shaped by project goals, technical constraints, community expectations, and perceptions of opportunity and risks, among other factors. 

For purposes of better understanding why Cosmos Hub’s ATOM token was designed as it currently is, it is helpful to think through how the original, ostensible mission for the Hub may have informed the project’s decisions on Hub architecture, token utility, and token supply.

In project materials, The Cosmos Team has presented the Cosmos Hub (and by extension, the ATOM token) not as the centerpiece of the Cosmos ecosystem, but rather, as a port city that facilitates trade between independent ‘cities’.  Each zone should not have to rely on the Hub and should be able to take creative liberties to differentiate themselves both technically and economically. This is reflected in network architecture, which dictates that each zone have their own unique set of validators such that their security and relevant incentive models are not tied to that of the Cosmos Hub. 

Likewise, for purpose of Hub independence, much of Cosmos’s tooling outside of the Hub are either free to use, or does not accrue value back to the ATOM token. This could be compared to Parachain leases requiring the bonding of DOT tokens in exchange for security and inclusion. The independent validator sets in Zones contribute to the separation of these models. If ATOM were implemented as a rent-seeking tool for these network tools, it may come at a direct clash of its long term vision of app chain sovereignty. 

It seemed like elements of the ATOM2.0 whitepaper would start to address some of these issues. In fact, there was a great amount of positive feedback for technical implementations surrounding the Interchain Scheduler and revenue potential of Interchain Security. That being said, the proposal ultimately failed due to the inability for the community to align on the purpose and funding  of the treasury. Proceeds from the Interchain Scheduler, Interchain Allocator, and network inflation would all subsidize the treasury, and not the validators. Since much of the proposed changes in the whitepaper do help to address some of the issues discussed above, it is likely that a new augmented version may pass in the future.