Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Cosmos Hub

Cosmos Hub

Supply and Accrual Unsynced
Cosmos Hub is an interconnected blockchain, one among many forming the Cosmos network, a network which aims to increase interoperability among different blockchains and allow decentralized applications to set up sovereign blockchains for different use cases.
HISTORY

Spring 2014
Tendermint Founded

Aug 2016
Cosmos Whitepaper

2018
SDK and Testnests

Mar 2019
Cosmos Hub Launch

Feb 2021
IBC Launches

Nov 2022
ATOM 2.0 vote fails

ECOSYSTEM COMPONENTS

Cosmos SDK
Programmable blockchain framework 

Cosmos Hub
Incumbent Cosmos blockchain used for development and testing

Zones (App chains)
SDK-based blockchains, connected to other Zones through IBC

IBC protocol
An interchain standard for interoperability and cross-chain communication

COMPETITORS

Polkadot
Network of L1 parachains with a common securing relay chain

Ethereum
Largest incumbent Smart Contract Network

NEAR
Sharded blockchain with parallel execution capabilities

Avalanche
A multi-chain, multi-VM approach to scalable application blockchains

INTRODUCTION

Cosmos is perceived as a competitive interchain network. Yet, as perception has it, the growth of the network has not scaled the utility for the Cosmos Hub’s ATOM token in a manner one might expect of comparable protocols. This commentary explores the basis for such positions on Cosmos and ATOM, how the current set of token utilities are reflected, and what future iterations the network is considering to address some of these concerns. 

Cosmos’s developmental history and levels of developer activity provide some reason to characterize Cosmos a successful interchain network. As expanded on in the key metrics, Cosmos Tendermint was one of the first proof-of stake designs, and Cosmos’s first appchain (Cosmos Hub) launched roughly a year before the Polkadot relay chain. In 2021, Cosmos had the third largest developer base, suggesting the network is attracting developers to build on it.

Yet Cosmos’s relative success does not entail ATOM’s— the scope of the Cosmos Hub and Cosmos’s toolkits should be distinguished, as stack diagram A helps illustrate.

PROJECT ARCHITECTURE

ZONES

Zones are application specific chains built using the Cosmos SDK that are a part of the IBC interchain network. They have their own unique set of validators, making the blockchain functionally independent from other networks (though they may have business dependencies). 

COSMWASM

Cosmwasm is the smart contract primitive for the Cosmos ecosystem. Existing as a Cosmos SDK module, it is widely accessible to app chains. Cosmwasm typically uses the Rust programming language (though AssemblyScript is also used), and enables the WebAssembly Virtual Machine.  

INTERCHAIN FOUNDATION

Core teams across various app chains that help to maintain the Hub, the SDK, Cosmwasm, IBC, and Tendermint - as well as deploying capital investments to help the further development of the interchain ecosystem. Such investments include Celestia, Agoric, and Penumbra - so not limited to classical app chain modeled projects. 

TENDERMINT CORE

Tendermint core is the BFT consensus engine that ensures that up to ⅓ of a network’s validators can fail without compromising the network. This, with the Tendermint Application Blockchain Client Interface (ABCI) allows for language agnostic state machines. 



Cosmos’s SDK, IBC, and Zones (separate appchains) are almost entirely independent from the Cosmos Hub, hence do not require ATOM tokens to utilize. The SDK is an open source framework for creating Tendermint blockchains, and appchains typically issue their own sovereign token and validator sets. Sovereign chains connected to the Hub do not have to interact with the ATOM token. This is in contrast with the designs of similar projects, such as  Polkadot Parachains, which require staking of DOT to secure one of the limited slots for independent chains.Third party bridge tooling typically levy a transaction fee (separate from network fee) to use the tooling and IBC connections only need to be made to the Cosmos Hub if the respective appchain decides to do so. 

This leaves ATOM with a comparatively narrow set of use cases, summarized in the key user flows, though a proposed but as yet unimplemented stack element might alter the dynamic. Interchain Security, which is a feature set to roll out as soon as January 2023, will offer the ability for projects to rent Cosmos Hub’s validator set to spin up a consumer chain. Consumer chains are functionally similar to Zones but will be a lot easier to spin up due to this feature. It is suggested that they will be used for application development or to be a financed test ground for new core Hub functionality. Future iterations may include the ability for Hub validators to choose which consumer chains to validate, as well as the ability for interchain security to be run bidirectionally among Zones. At the feature is not live, the key token interactions and token utility classifications do not reflect this potential use case.

KEY TOKEN INTERACTIONS

Four use case scenarios for 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 SERVICES

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:

Atom is intended to be used as a Money, Contribution and Governance token

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.

TOKEN SUPPLY FINDINGS

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.

Distribution, sources and sinks for Atom

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

CONCLUSION

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.

SOURCES

Alqahtani, Salem. “A paper review: The design, architecture, and performance of the Tendermint Blockchain Network.” Medium(blog). Nov 30th, 2021.  Accessed Oct 31st, 2022. 

ATOMscan, inc.  Votes. [Voting records for proposals, including summary of proposal,  numbers and percent of votes in favor, against with veto, against without veto, and abstaining. Mar 20th, 2019 -Oct 14th, 2022] Available from ATOMScan.com. Accessed Oct 25th, 2022. 

Buchman, Ethan and Hart, Sam. “The Cosmos Hub is a Port City.”Cosmos.Network(blog). Feb 23rd, 2021. Accessed Oct 31st, 2022. 

CosmWasm. “Docs.” 2022, CosmWasm. Accessed Oct 31st, 2022.

Interchain. “Cosmos History—Part I—Inception to PreLaunch.Cosmos.Network(blog). Sep 24th, 2022. Accessed Oct 31st, 2022. 

Interchain.  “Preparing for the Cosmos Hub v7-Theta upgrade. Medium(blog). Mar 10th, 2022. Accessed Oct 31st, 2022.

Interchain Core Team. “Cosmos SDK Documentation.” No date, Cosmos. Accessed Oct 31st, 2022. 

Interchain GmbH. “Tendermint Core.” No date, Tendermint. Accessed Oct 31st, 2022. 

Philips, Daniel and Tran, Ki Chong. “What is Cosmos Network (ATOM), the Internet of Blockchains?.”Decrypt, Mar 5th, 2021.

https://mapofzones.com/home?columnKey=ibcVolume&period=24h

Shen, Maria. “Electric capital Developer Report.Medium(blog). Jan 6th, 2022. Accessed Oct 31st, 2022.

No items found.
No items found.
ACTOR
USER
USER
USER
BEACON
BEACON
USER
FUNCTION
DESCRIPTION

Publish Content

A user uploads content to a content network and receives a content address. The user then selects one or more content beacons on which to broadcast their content, as well as any associated metadata.

Beacon Discovery

A user connects to the genesis beacon and receives a list of active public beacons, or directly enters in the address of a beacon into their client. These beacons can then be used to publish content or can be monitored for new content.

Content Discovery and Processing

A user connects to the genesis beacon and receives a list of active public beacons, or directly enters in the address of a beacon into their client. These beacons can then be used to publish content or can be monitored for new content.

Announcement

A beacon (optionally) announces itself by sending an announcement message to the genesis beacon. This announcement is repeated at a standard announcement interval to show the continued liveness of the beacon.

Process and Publish Content Map

During each publication period beacons watch for transactions sent to their address that contain content links and metadata. The beacon then verifies this data by its own auditing and curation process, then stores the results in a content map on a content network and publishes the location of that content map to a signal address for discovery by its followers.

Beacon Verification / Simulation

Users can (optionally) process the transactions of any beacon by creating content maps locally based on the submissions to that address.

MEMBER TIER
Full
Full Copy
Full Copy 2
REQUIREMENTS
BENEFITS
GOVERNANCE UTILITY
LIMITATIONS

Hold 75 $FWB tokens at all times
Pass a membership application (acceptance rate is unclear, and appears to be skewed towards diversifying the DAO’s demographics)

Access to all Discord channels and content
Invitations to weekly virtual events
Access to regional in-person events
Access to the community’s weekly newsletter

$FWB-weighted voting rights

Access to participate in the governance Discord channel and governance-related virtual meetups

Ability to submit proposals

$FWB-weighted voting rights

Access to participate in the governance Discord channel and governance-related virtual meetups

Ability to submit proposals

Hold 75 $FWB tokens at all times
Pass a membership application (acceptance rate is unclear, and appears to be skewed towards diversifying the DAO’s demographics)

Access to all Discord channels and content
Invitations to weekly virtual events
Access to regional in-person events
Access to the community’s weekly newsletter

$FWB-weighted voting rights

Access to participate in the governance Discord channel and governance-related virtual meetups

Ability to submit proposals

$FWB-weighted voting rights

Access to participate in the governance Discord channel and governance-related virtual meetups

Ability to submit proposals

Hold 75 $FWB tokens at all times
Pass a membership application (acceptance rate is unclear, and appears to be skewed towards diversifying the DAO’s demographics)

Access to all Discord channels and content
Invitations to weekly virtual events
Access to regional in-person events
Access to the community’s weekly newsletter

$FWB-weighted voting rights

Access to participate in the governance Discord channel and governance-related virtual meetups

Ability to submit proposals

$FWB-weighted voting rights

Access to participate in the governance Discord channel and governance-related virtual meetups

Ability to submit proposals

2 copy