Overview

Cosmos is a decentralized and community-owned ecosystem of interconnected applications and services, often branded “the internet of blockchains”. Cosmos apps and services connect and use the IBC technology, which stands for Inter-Blockchain Communication. The Cosmos Hub is the economic center of Cosmos, and acts as the main security provider, go-to marketplace, multichain router , and best place to manage accounts across all chains in Cosmos.

On the technology side, both the Cosmos Hub as well as its sovereign interconnected chains, are built using the Cosmos SDK. Developers can use this framework to create applications and expand the market share of the Cosmos ecosystem. Cosmos is a Proof of Stake blockchain with a Byzantine Fault Tolerant consensus engine, which lowers its carbon footprint and also favors scalability. Fees average to $0.01 and transactions are confirmed in ~7 seconds.

There are currently more than 263 apps and services running in the Cosmos network, including Binance Chain, Crypto.org, and the Cosmos Hub among many others, all of them with over $61B of digital assets under management. All these are sovereign and autonomous chains running their custom set of applications while exchanging and securing value between other chains in the ecosystem. Instead of millions of applications competing for throughput on a single base layer 1 blockchain, Cosmos allows for multiple application-specific chains to be interconnected across a multitude of sovereign chains.

Cosmos is a network of independent parallel blockchains powered by Tendermint BFT consensus algorithms. Cosmos allows developers to build and deploy scalable and interoperable application-specific blockchains. Instead of developing on top of existing monolithic layer 1 blockchains, Tendermint and the Cosmos SDK propose another way to build decentralized applications.

Instead of having the application part of the blockchain be a Virtual machine and build applications on top of it, Cosmos simplifies the development of decentralized applications as the application of the blockchain itself.

Cosmos is a decentralized network of independent blockchains using the Tendermint Byzantine Fault Tolerant (BFT) algorithm. In other words, the Cosmos ecosystem is a set of interoperable chains that can scale and communicate with each other. The best part of building application-specific chains on Cosmos is the ability for developers to customize a ledger that performs computation and settles transactions in a decentralized and sovereign manner.

From the technical point of view, blockchains are deterministic state machines replicated on a number of full nodes that maintain the network’s security by following a consensus mechanism.

Deterministic is an attribute used to describe the unique results that come out of a computation. Given the same input values, a deterministic result will always return the same output. When applied to blockchains, this means that when you apply the same transactions to the Genesis state, you will always obtain the same resultant state.

A state machine is a concept used in Computer Science to explain how a computer program is able to hold a state and modify it when it receives inputs. For example, a blockchain state will represent multiple addresses with different balances each. This state will be modified every time there is a token transfer from one wallet to another.

A full node is a node that stores and validates the entire state of a blockchain.

Consensus safety is the mechanism by which nodes behave in an honest manner to reflect and replicate the state of the blockchain at any given time.

Diving deeper, the architecture of blockchains can be divided into 3 layers:

• The Application layer is responsible for updating the state of the blockchain given a set of transactions.
• The Networking layer is responsible for propagating transactions and consensus-related messages across nodes.
• The Consensus layer enables the agreement by nodes on the current valid state of the system.

Cosmos technology is focused on solving the Blockchain trilemma by building modular blockchains that can communicate with each other in a decentralized manner.

A blockchain is said to be modular when it specializes in only a few functions rather than all of them. Therefore, it will be specialized in one of the following functionalities: consensus, execution, settlement, or data availability.

Why The Project Was Created

To understand how Cosmos fits in the blockchain ecosystem, it is important to go back in history and appreciate the innovation of Bitcoin, the first peer-to-peer blockchain. Bitcoin used a Proof of Work consensus mechanism that supported a monolithic codebase that combined all three layers of a blockchain: networking, consensus, and application.

To further improve the cumbersome scripting language of Bitcoin, the Ethereum Virtual Machine was created in 2014. It was meant to be the base layer for building decentralized applications whose logic would be handled by smart contracts that anyone could deploy in a permissionless fashion.

Smart contracts are snippets of code that are deployed to a blockchain to incorporate a virtual machine as part of its application layer.

However, the limitations of Ethereum became apparent as more and more decentralized applications led to network congestion and hindered scalability. Three limitations stood out:

• Scalability due to a maximum allowance of 15 transactions per second (all dApps competing for limited resources).
• Usability is due to the low flexibility that developers could achieve by building on top of generalized virtual machines designed to accommodate for all use cases. 
• Sovereignty because all applications are shared and operated on the same underlying environment. This also leads to governance problems because if someone requests to implement a new feature, then the entire governance participation of the platform must agree on the approval decision to carry on with the implementation.

All of these limitations, however, were not unique to Ethereum. All generalized layer 1 blockchains are exposed to the same problems in one way or another.

To solve this problem of scalability and interoperability, the vision of Cosmos is to make it easy for developers to break the barriers between blockchains by allowing them to transact with each other. The mission is to create an Internet of Blockchains where all chains can communicate with each other in a decentralized manner.

By combining open source tools like Tendermint, the Cosmos SDK, and IBC, teams of engineers can build custom, secure, scalable, and interoperable application-specific chains.

The origin of Tendermint

Tendermint emerged with the goal of providing a more efficient and secure consensus algorithm than Bitcoin’s Proof of Work. In its early days, Tendermint also had a currency built into it. Users had to “bond” units of that currency into a security deposit which could be revoked if they misbehaved. Since then, Tendermint has evolved to become a general-purpose blockchain consensus engine that can host arbitrary application states written in codebases that use multiple programming languages thanks to the implementation of the Application Blockchain Interface (ABCI).

The origin of ABCI

The majority of blockchains have a monolithic design, where a single program is responsible for handling all the functioning of the decentralized ledger (Peer-to-peer connectivity, mempool broadcasting, consensus on the most recent block, account balance, user-level permissions..). In Computer Science, this is a bad practice, since it makes it difficult to reuse certain pieces of software that are responsible for the execution of very particular functions. Monolithic designs are also a barrier for programming languages, since the entire stack must be written in the same language.

In practical terms, we can take the Bitcoin blockchain as an example to explain what a Bitcoin-like built on top of a modular architecture on Cosmos would look like. In this scenario, the Tendermint Core would be responsible for sharing blocks and broadcasting transactions between nodes by establishing a canonical and immutable order of transactions. The Application layer, therefore, would not have to take on that extra work and can focus on executing the application logic in the most optimal manner. This is what ABCI enables. Following the same example, ABCI would be responsible for maintaining the transactions (UTXO) database, validating the cryptographic signatures of transactions, preventing transactions from double spending, allowing clients to query transactions…

Furthermore, there can be multiple ABCI socket connections between an application and the Tendermint Core. For example, one connection could validate and broadcast the transactions in the mempool, another connection could run the consensus engine, another one could facilitate the querying of transactions…

The origin of IBC

As the number of blockchains with different value propositions started to grow, the number of users and growth in usage quickly proved that huge loads of traffic could be detrimental from a user experience perspective due to network congestion.

Before IBC, all these blockchains existed in closed silos and were unable to communicate with each other. Since these traditional blockchains were not interconnected, they often experienced scaling issues, high fees, and prolonged transaction times. As an example, in July 2021 Ethereum experienced a hit of 98% of its maximum capacity.

IBC was invented to achieve a sustainable DeFi environment where tokens and data can be transferred in a frictionless and trustless manner. Traditional blockchains perform various tasks, but they are very specialized in the distinct set of tasks that they perform. That’s the reason why they remain isolated. With IBC, the problem of communication between blockchains is solved. Today, more and more chains continue to interoperate with each other, not only leading to innovative and unprecedented use cases of decentralized technology, but also allowing the industry to scale in an exponential manner.

​​

Roadmap

The 2024 roadmap was introduced on September 25, 2023.

In 2024, the Cosmos SDK is set out to be a modular software development kit.

The focus will be cleaning up the technical debt, making the repository modular, and pushing new features improving the lives of developers by maintaining high-level security and performance.

The in-depth roadmap includes the following.

Technical Debt

• Storage
  • Performance
  • Scalable for clients
• Core
  • Modular (use different consensus engines: Rollkit, Dymint, etc..
  • Swappable (easily swap components: storage, different module loaders (Wasm, FFI, gRPC and native), client, etc..)
• Modules
  • Easily provable in VMs
  • Reduce total lines of code
  • Modular (allow application developers to modify business logic)
  • Rewrite legacy modules (Auth, Bank, Staking, Distribution, Mint, Slashing, etc..)
• Cryptography 
  • Rewrite key handling, make it more modular allowing others to use custom HSMs
  • Introduce new crypto primitives 
  • Separate wallet

Modularity

• Consensus Modularity
  • Modular (use different consensus engines: Rollkit, Dymint, etc..
  • Swappable (easily swap components: storage, different module loaders (Wasm, FFI, gRPC and native), client, etc..)
• Storage
  • Allow commitment structures to be interchanged
  • Allow modules to have different commitment structures from each other
  • Parallelize reads and writes
• Module Composability
  • Allow users to fork or plugin custom logic (user feedback dependent)

Maintenance

• Bugs
  • Triage bugs when opened as issues
  • Solve and close bugs as they appear
• Documentation
  • Keep documentation up to date
  • Produce new blog posts based on new features
• Tutorials
  • Produce and maintain new tutorials for developers
  • Produce and maintain upgrade tutorials
  • Produce and maintain user tutorials
• Security
  • Incident Response & Handling
• Performance
  • Continually profile & benchmark software
  • Fix hotspots 

Future

• Cross-Language
  • Module Loaders (WASM, FFI, GRPC)
  • Possibly align closer with CosmWasm
• Upgrades
  • Separate business logic of modules and VMS from core/node upgrading
  • Make upgrades seamless (upgraded binary prior to upgrade height)
  • Sync from genesis
• Research
  • ZK circuits for proving modules
  • Fraud & Validity Proof

Team

The Cosmos Network is a project and technological initiative supported and backed by the Interchain Foundation. Most of the initial software development was done by the Tendermint Core team. However, in the spirit of decentralization, the development process has become more decentralized over time.

Today, there are a number of projects and development teams building the core software and infrastructure in the Cosmos ecosystem, such as Agoric, Akash, Althea, Chainapsis, ChainSafe, Confio, Informal Systems, Interchain GmbH, Iqlusion, IRIS, Ilunie, Promise Protocol, Regen, Sikka, SnowFork, VitWit, and Zondax.

The Interchain Foundation is a Swiss non-profit organization dedicated to the research and development of open and decentralized technologies like the Cosmos SDK.

Organizations

• Agoric
• Althea Network
• Chainsafe
• Chorus One
• Interchain Foundation; Swiss non-profit foundation with the mission to support the research and development of Cosmos
• Sikka
• Confio
• Chainapsis
• B-Harvest
• Iqlusion
• Tendermint; responsible for the research, development and commercialization of the Tendermint consensus algorithm developed in 2014. Since 2017 the company has been contracted by the Interchain Foundation to deliver and maintain the Cosmos Network and Hub

Individuals

• Ethan Buchman; Co-founder of Cosmos, CEO at Informal Systems, and VP of the Interchain Foundation
• Jae Kwon; Co-founder of Cosmos, CTO at Tendermint, and President of the Interchain Foundation
• Billy Rennekamp; Grants manager at Interchain Foundation
• Jack Zampolin; VP Product at Akash Network
• Peng Zhong; CEO and President at Tendermint
• Sunny Aggarwal; Founder at Sikka and Co-host for the Epicenter podcast
• Zaki Manian; Co-Founder of Sommelier Protocol
• Chistropher Goes; Lead developer at Interchain GmbH
• Ethan Frey; CEO at Confio and Early contributor to Cosmos
• Sam Hart; Grants Manager at the Interchain Foundation
• Tess Rinearson; VP of Engineering at Interchain GmbH

Sector Outlook

The Cosmos vision is to leverage the Cosmos technology to circumvent the problem of building monolithic blockchains that follow a “supercomputer” approach that leaves them in isolation and unable to communicate with other chains.

Cosmos seeks to build infrastructure that is resilient to high transaction throughput and achieves higher levels of scalability with a high-performance and low-energy consuming Proof of Stake consensus mechanism.

Sovereignty

The Cosmos ecosystem is built around a set of sovereign application-specific blockchains. As such, developers can choose whether to deploy a public Proof of Stake chain or a private Proof of Authority Chain. Regardless of that decision, validators will only validate the transactions of that specific chain. Therefore, all governance decisions are compartmented to the application of that chain. Whenever there is a problem or runtime concern, the rest of the chains in the ecosystem will keep working independently. This is a strong value proposition when compared to other virtual machines that, when they go down, they bring down all the applications that are deployed in it as well.

Flexibility

Contrary to other layer 1 blockchains where the innovation and creativity of its developers are constrained by the underlying development environment, developers on Cosmos have the flexibility to choose the programming language they prefer. This will apply when these developers choose to build their blockchain as an ABCI-application on top of Tendermint. While it can be difficult to build an entire blockchain from scratch, this process is simplified by the Cosmos SDK.

• Blockchains in Cosmos are connected to the underlying consensus engine via the ABCI interface, which can be wrapped in any programming language (Go, Rust, Javascript…)
• Developers can choose among multiple frameworks to build the state machine that will handle the application business logic. Among these frameworks stand out the Cosmos SDK, Lotion, Weave…
• ABCI allows blockchains to swap out the consensus layer and tweak its parameters
• Developers have freedom to explore the full spectrum of tradeoffs: number of validators, transaction throughput, security, data availability, UTXO vs account model….
• Teams can implement automatic code execution and choose the cryptographic library they prefer.

While the Cosmos SDK, Tendermint BFT, and IBC are an overall improvement in the developer experience and interoperability of blockchains, there are also valid use cases for using Virtual-machine based layer 1 blockchains such as Ethereum, Avalanche, Fantom…

• Small, low-usage applications that can be quickly prototyped and benefit from existing infrastructure
• Applications where the core team does not want to deploy and maintain their own set of validator nodes. By using existing Virtual Machines, the application developers will simply focus on the business logic of their application.

As the industry matures, blockchain protocols start noticing the need to communicate with applications in other chains. Over time, multiple competing protocols have resulted in the creation of separate siloed ecosystems that cannot transfer data or exchange assets with each other. However, if the cryptocurrency industry is looking forward to reaching mass adoption, blockchain developers must embrace cross-chain technology as the way to scale and strengthen the use cases of interoperable application-specific chains.

The majority of blockchains work independently of each other, which is a barrier for both users and developers, who might suffer from scaling problems as the usage of the chain increases (slower transactions, higher transaction fees…). To achieve the full potential of blockchains, it is essential to improve upon the specific limitations of each particular chain to allow for the transfer and sharing of information across chains with no downtime or expensive transaction fees. This is exactly the value proposition of Cosmos, to offer a solution for executing cross-chain transactions using IBC to transfer data and assets in a trustless and frictionless manner.

The bull case for Cosmos is to fulfill the promise of the “Internet of blockchains” by connecting thousands of independent assets and applications that are interoperable with other chains like Solana, Ethereum, Polkadot… It is important to notice that Cosmos is not a direct competitor of those chains. Instead, its total addressable market would increase significantly once there is a way to communicate with those chains. As more chains are added to Cosmos, the network effects would start to kick in a new wave of exponential growth in the adoption and value accrual of the ATOM token.

Overall, the Cosmos SDK opens up a new development paradigm and sector outlook that challenges virtual-machine blockchains like Ethereum, where the development generally revolves around building applications on top of existing infrastructure. Application-specific chains offer radically different value propositions that give developers the freedom and flexibility to make the design decisions that will enable their applications to run optimally.

Cosmos currently has a $60.78B in market cap from 72 apps and services, and $7.19B in market cap from 46 IBC-enabled chains. Among the most popular chains we find: Cosmos Hub, BNB Chain,  Cronos, Luna Classic, Osmosis, Thorchain.

The Cosmos ecosystem currently covers 263 apps and services, and 33 wallets.

The Appchain Thesis

On a monolithic chain, multiple different applications share the same blockspace which causes it to be highly congested, competitive, and spike in fees. On an appchain, the application owns its own blockspace instead of sharing it with other applications. An appchain is better able to control the fees and gives them the ability to keep it at a constant. Since the application is the owner of the chain, there is self-governance for fee structures within the application and its community.

The underlying tech allows optimization on the application while retaining composability between chains in the wider ecosystem with its native cross-chain messaging system such as IBC. This composability allows for the validator sets of the two communicating chains to be the trust assumption instead of requiring third parties.

For Users

Interchain Accounts

Users can access the Cosmos Interchain with one single account. This is achieved with Interchain Accounts, which allow blockchains to securely control accounts on other chains using Inter Blockchain Communication (IBC).

Interchain accounts are one of the catalysts to fully unlock the maximum potential of IBC on Cosmos. In simple terms, interchain accounts allow a blockchain to securely control an account on another chain. This is possible by using IBC at the application level. This allows applications to deterministically create new interchain accounts over IBC, as well as relay transactions to interchain accounts and submit those transactions to the target destination blockchain.

What problems do Interchain Accounts solve?

• Composability between Cosmos Zones without reducing the degree of sovereignty.
• Provide a simple and scalable path for the adoption of IBC.
• Mitigate security risks, since interchain accounts do not require significant changes to the core blockchain application logic.

Gravity DEX

The Cosmos Hub’s Gravity DEX enables users to seamlessly swap digital assets coming from all over the interchain. This is an improvement over traditional DEXes and combines features of traditional AMMs (like Uniswap) with an orderbook-based model.

The Gravity Dex is currently secured by over ~3B of assets that enable DeFi across multiple chains with an average of $0.08 in transaction fees.

The Gravity Dex uses an Equivalent Swap Price Model (ESPM) that seeks to improve the price consistency for traders while reducing the number of opportunities for arbitrage. This is achieved through batch order execution, which makes trading fairer and allows developers to build order book trading UIs where users can get instantly accurate market pricing information.

The Equivalent Swap Price Model allows for both fractional and full matching of orders based on the following criteria:

• Swap from X to Y:
  • Order price > swap price: order must be fully matched
  • Order price = swap price: order can be fully/fractionally matched
  • Order price < swap price: order must not be matched at all
• Swap from Y to X:
  • Order price < swap price: order must be fully matched
  • Order price = swap price: order can be fully/fractionally matched
  • Order price > swap price: order must not be matched at all

Since its whitepaper release in 2021, the Gravity Dex has struggled to establish itself as a larger player in the Cosmos ecosystem. For that reason, the project has gone through a process of rebranding. The project has relaunched as Crescent (CRE) and moved to a new chain of the same name. Along with this relaunch, B-Harvest also plans to introduce new features such as tools for lending and borrowing across chains, and a new order book DEX model.

Gravity Bridge

The Gravity Bridge is the most secure, efficient, and decentralized cross-chain bridge that allows blockchains on Cosmos to communicate with Ethereum. This enables assets on Cosmos to flow to the destination chain as ERC-20 tokens and vice-versa (bring ERC-20 tokens to the Cosmos ecosystem).

The Gravity Bridge has been designed with the following principles in mind:

• Trust in the bridge is anchored on the Cosmos side.
• It is mandatory for peg zone validators to maintain a trusted Ethereum node.
  • This removes all trust and game theory implications that usually arise from independent relayers.
• Transactions from Cosmos to Ethereum are batched. Batches may contain an arbitrary number of transactions

Chain Name Service

Chain Names are to blockchains what Domain Names are to websites. These chain names will be managed on the Cosmos Hub. By operating as a Chain Name Service, this will make it easier for users to identify the chains they want to interact with.

Chain Name Service was created to allow the Cosmos Hub to function as an interchain router. For that, it needs to access a canonical list of chain names. For instance, token holders on the Hub need a trusted way to trust that the IRIS tokens on the Hub are actually coming from the IRISnet network.

If the Hub decides to add services for Dexes, this would allow for use cases such as allowing token holders to quickly verify ticker symbols and provide liquidity to the right pools.

A Chain Name Service would provide the security for interchain transfers to occur while making it possible for token tracking upon every transfer both on and off the Cosmos Hub. When this happens, all zones could then relay transactions to the hub via a trusted setup that would also contribute to the growth of the ATOM token.

Liquid Staking

Liquid Staking is one of the most important primitives for making cross-chain DeFi possible. At their core, the Cosmos ecosystem will focus its liquid staking derivatives initiatives as claims against staked ATOM. Similar to staked ATOM, liquid staking derivatives will keep on accruing rewards while having the benefits of being a fungible representation that can be used across the decentralized economy.

Liquid staking unlocks capital that is otherwise staked to be deployed elsewhere. This further boosts Cosmos’s interoperable and interchain security design as users can extend their staked capital to other chains within the Cosmos ecosystem while securing the network. This could also attract external liquidity from other participants to participate in the Cosmos network given that they do not need to lose out on opportunity cost with liquid staking.

Some of the liquid staking providers are Stride, Persistence, and Quicksilver among others.

Developers

Developers in Cosmos can build their Decentralized Finance Applications by using the Cosmos SDK and creating application-specific blockchains. This means that, unlike other leading blockchains, engineers are no longer forced to exist as smart contracts on someone else’s chain. Instead, developers can opt out of high transaction fees and network congestion by coming up with their own blockchain architecture, rules, and scalability solutions. This opens up the doors for innovative applications in the fields of DeFi, NFTs, gaming, DAOs, social networks, marketplaces…

The Cosmos Developer Portal is the go-to place for engineers to start building on Cosmos. Developers can also access the Ignite CLI, built on top of the Cosmos SDK, to build, test, and deploy their own sovereign application-specific blockchain. Ignite is a development framework written in Go that accelerates the scaffolding process and allows developers to focus on the business logic of their product. This allows for use cases such as:

• Create modular blockchains written in Go
• Scaffold modules, messages, IBC packets…
• Connect to other blockchains with an IBC relayer
• Run a production node with live reloading

In Cosmos, the main programming languages for blockchain development are:

• Go is an open-source programming language that combines the ease of development of a compiled language with well-known programming paradigms such as object-oriented programming. Go is also statically typed, which makes it extremely useful for building blockchains applications that require features such as generics, structs, built-in concurrency, automatic memory management…
• Rust is a fast and memory-efficient language that has no runtime or garbage collection. It is a low-level language, which makes it useful for developing embedded and bare-metal solutions. The generated compiled binary code consumes very low memory and supports WebAssembly. In the Cosmos ecosystem the popular CosmWasm smart contract project allows developers to write multi-chain smart contracts in Rust. Rust is also a very popular language used in other blockchains such as Polkadot, Near, and Solana.
• Solidity is the go-to language for developers on the Ethereum ecosystem. It is an object-oriented high-level language for smart contracts on EVM (Ethereum Virtual Machine) compatible chains. It is statically typed, support inheritance, libraries, and complex user-defined types
• Javascript is the most popular general-purpose programming language for building both backend and frontend services. Most blockchains include a Javascript wrapper or library to make it easier for developers to get on board.
• Java is one of the oldest and most popular object-oriented programming languages. The code execution takes place on the JVM (Java Virtual Machine).

There is currently a Bounty program that provides incentives and pays rewards to users of Ignite. Among the projects that are already using this framework are Cronos, PolyNetwork, ZenChain, Celestia…

Delegators

People that cannot or do not want to operate validator nodes can participate in the staking process and contribute to the Cosmos Hub’s security as delegators. The requirement to be a delegator is to hold ATOM and send a delegate transaction specifying the number of ATOM tokens that they want to bond to a validator node. Later on, if the delegator wanted to get its assets back, it would submit an “unbond transaction”. When that happens, delegators are forced to wait 3 weeks before they can retrieve their assets.

Validators are not chosen based on their self–delegated stake. Instead, the total stake of a validator is considered when assessing its eligibility for participating in the network. This amount is the sum of their self-delegated stake and the stake that is delegated to them by other users.

Delegators share the revenue of their validators. Similarly, they are also exposed to the same risks. In terms of revenue, validators can choose to apply a commission on the income that is distributed to delegators.

The following factors will be taken into consideration by delegators before picking a validator:

• Validator’s moniker and description
• Commission rate
• Commission maximum rate of change
• Maximum commission
• Minimum amount of ATOM tokens that the validator can self-bond

Validators

The Cosmos Hub relies on a set of validators that are responsible for committing new blocks in the blockchain by following the Tendermint consensus algorithm. Validators will participate in the consensus algorithm and will broadcast votes by cryptographically signing transactions with their private key.

Validators can bond their own ATOM holdings and also receive delegated ATOM tokens that they will stake on the delegator’s behalf.

The Cosmos Hub has an ever-increasing number of validators (currently 175 nodes) that is determined by the total number of ATOM tokens delegated to them.

Validators and their delegators earn ATOM as block rewards from transaction fees. Validators can set a commission percentage on the amount of fees collected, which will impact the amount of ATOM tokens that delegators will receive as an incentive.

If validators double sign or are offline for an extended period of time, their staked ATOM (including the ATOM tokens that have been delegated to them) can be slashed. This penalty will depend on the severity of the misbehavior.

Hardware requirements

The hardware requirements impose the co-location of validator nodes in secure data centers with redundant sources of power, connectivity, and storage backups. As the network grows, the requirements for CPU power, memory and bandwidth will increase.

• Large hard drives are recommended for storing years of blockchain history.
• Significant RAM memory is recommended to process an increasing amount of transactions.
• It is recommended that validators set up sentry nodes to protect against DDoS attacks

Software requirements

Validators are expected to implement monitoring, alerting, and management solutions on top of the required Cosmos software to activate and run their nodes.

Network requirements

Relative to other chains, the Cosmos network has a high capacity for throughput. Validators are encouraged to connect their nodes to cloud data centers they trust or alongside other validators with which they maintain a social relationship. This connection strategy is beneficial in terms of bandwidth as an extra layer of protection against DDoS attacks. Over time, as the network usage grows, it is realistic to achieve approximately multi-gigabyte per day levels.

Key management

The Interchain Foundation does not recommend one key management solution over another. However, validators are expected to run a Hardware Security Module (HSM) that supports ed25519 keys, such as:

• YubiHSM 2
• Ledger Nano S
• https://github.com/LedgerHQ/bolos-enclave
• Thales nShield

Maintenance requirements

Validators are expected to perform regular software updates to stay up to date with the latest security patches and bug fixes. It is suggested for them to use Cosmovisor as an extra help to automate this process

Whenever there is a chain upgrade, the progress is discussed in a private Discord channel.

Other recommendations

It is recommended that validators create their own website to provide transparency and additional information to delegators, such as:

• Validator’s public key
• Validator’s name and description of operations
• Initial commission rate
• Maximum commission rate of change
• Maximum commission
• Minimum amount of self-delegation in ATOM tokens

Self-delegation refers to the amount of ATOM tokens that validators can bond to themselves.

Validators are incentivized to participate in staking to earn revenue from:

• Block rewards
• Transaction fees

The total revenue generated in the chain is divided among validator’s staking pools according to the validator weights. After that, the rewards are distributed within each validator’s staking pool in proportion to each delegator’s stake. A commission on the delegator’s revenue will be applied before the distribution (this is the validator commission).

Cosmos Hub

At the core of the “Internet of Blockchains” is the Cosmos Hub, which is the economic center that secures the ecosystem with the ATOM token. As the first blockchain to be deployed in the Cosmos network, the Cosmos Hub is designed to be a service provider to the chains that it connects to.

By acting as the decentralized marketplace that provides shared security to other chains, it is also the entry point for bridges that aim to interconnect liquidity with other external chains such as Ethereum and Bitcoin. All of these services are the main driver for other sovereign chains to connect and transfer their assets to the Cosmos Hub. As a result, the value of the Cosmos Hub is measured by the aggregate value of the blockchain economics that conduct business on the Hub through IBC (Inter-Blockchain Communication).

The Cosmos Hub is not only responsible for connecting to many other blockchains (Zones), but is also in charge of tracking the different types of tokens that are connected to each of them. To do that, the Cosmos Hub facilitates the transfer of assets from one blockchain to another in a secure manner without the need for liquid exchange to exist and intervene between Zones (all inter-zone coin transfers go through the Cosmos Hub).

The ATOM token is the native token of the Cosmos Hub. All the services provided by the Hub are secured by staking ATOM. In return, the Hub benefits and accrues value from transaction fees and staking rewards that are redistributed to the Cosmos Hub itself. Besides, the expected value from economic rewards is set to experience exponential from the introduction of additional services such as the Gravity Dex, the Gravity Bridge, or Interchain Staking, all of which will allow staked ATOM to secure other blockchains in the ecosystem.

While it is possible to use IBC to connect all blockchains in the Cosmos network, the main problem with this approach is that the number of connections in the network grows quadratically with the number of blockchains. For example, 100 blockchains in the network would require 4950 such that all blockchains were connected to each other.

To solve this problem, Cosmos proposes a modular architecture where blockchains are classified into two classes of chains: Hubs and Zones

• Hubs are blockchains whose purpose is to connect Zones while reducing the number of required connections among Zones. Hubs also prevent the double spending problem among Zones. This means that when a Zone receives a token from a Hub, it only needs to trust the origin Zone of the token and the Hub.
• Zones are the regular sovereign chains running their own validator sets that are responsible for creating connections with a Hub that is automatically accessible. This allows Zones to send and receive assets and data from every other Zone that is connected to the Hub. This means that, by establishing only a limited number of connections with a restricted set of Hubs,  each zone can maintain a line of communication with each other.

The first Hub launched in the Cosmos Network is the Cosmos Hub, a public Proof-of-Stake blockchain that uses ATOM as the native asset while allowing transaction fees to be payable in a variety of tokens. The launch of the Cosmos Hub marked the launch of the Cosmos Network.

Tendermint Core

Tendermint is the underlying technology behind Cosmos. It allows for the implementation of a Byzantine Fault Tolerant (BFT) consensus algorithm designed to ensure finality, order consistency, and optional availability.

Tendermint is technology that packages the networking and consensus layers of a blockchain into a generic engine where developers can build their applications. It is a software that securely and consistently replicates an application on a series of distributed machines.

•  The word “secure” in this context means that the application will work even if up to ⅓ of machines fail in arbitrary ways.
• The word “consistent” in this context means that every non-faulty machine will see the same transaction log and will compute the same transition state.

The Tendermint BFT engine is connected to the application layer by a socket protocol called the Application Blockchain Interface (ABCI), which can be wrapped into any programming language. This makes it easier for developers to choose the language that suits their needs.

BFT refers to the ability for a software component to tolerate machines failing to operate in a non-malicious manner.

The following properties differentiate Tendermint:

• Public or private blockchains can be built using the Tendermint BFT networking and consensus. This means that nodes can propagate the transactions that validators will agree upon to determine the correct state of the blockchain.
  • If the application defines that only a set of pre-specified and authorized entities can act as validators, then the blockchain is considered to be private.
  • If the application defines that validators are elected based on the number of tokens they have at a stake, then the blockchain is said to work as a Proof of Stake public network.
• High performant block time on the order of 1 second and that can handle up to thousand transactions per second.
• Instant finality guarantees that user transactions reach the settlement layer as soon as a block is created
• Security from the Tendermint consensus algorithm.

In classical BFT algorithms, each node has the same weight in the network. However, in Tendermint, nodes have a non-negative amount of voting power. Nodes that have a positive voting weight are called validators. Similar to other chains, validator nodes participate in the consensus protocol by broadcasting cryptographic signatures to agree upon the next block

Tendermint determines the weight of validator nodes at genesis, but it is also possible to change the weights deterministically by the blockchain depending on the functionality of the application. Validators attempt to come to consensus on a block by block basis, where a block is a list of transactions that will be included in the ledger. The process of voting for consensus is done in rounds. Every round there will be a node leader or proposer node that will propose the next block to be added. Afterwards, validator nodes will use their voting power to vote in stages and finally determine whether to accept the block or not. When a block is accepted or rejected, a new round starts. Every round, the proposer node is chosen deterministically from the ordered list of validators in proportion to their voting power.

Tendermint consists of 2 technical components:

• A blockchain consensus engine called Tendermint Core ensures that the same transactions are recorded on every machine in the same order.
• A generic application interface called the Application Blockchain Interface (ABCI) that enables the transactions to be processed in any programming language.

The BFT consensus is reached in a mostly asynchronous manner, where the protocol validators take turns proposing blocks filled with transactions and voting on them.

Light clients on Tendermint

A notable advantage of Tendermint BFT consensus is the concept of light clients, which will contribute to the network’s security by keeping up with the changes to the validator set.

A light client is an alternative solution to running a full node. Full nodes are resource heavy, because they need to execute and verify transactions. Light clients, however, have lower resource requirements, since they only verify the results of the execution of transactions. The main difference is that while full nodes need to store a lot of data (blocks, transaction results…), light clients only need to store the headers of the latest blocks.

This verification process can be achieved by two methods:

• Sequential verification, which consists in downloading the next header following a block while applying Tendermint validation rules:

• Skipping verification, which is a less bandwidth and compute-intensive process that downloads two block headers to reach a state of synchronization:

The first version of a light client was developed in 2018 by Ethan Frey. It was improved later on in 2019 with a specification led primarily by researchers at Informal Systems, and individuals like Anton Kaliaev and Callum Waters. While it was a huge improvement for the Cosmos ecosystem back in the day, the implementation currently does not support fraud proofs, which means that the verification algorithm relies solely on having at least one transaction witness.

ABCI

The Tendermint Consensus algorithm is implemented in a program called Tendermint Core. While the Tendermint BFT algorithm is an application-agnostic consensus-engine, Tendermint BFT is used to connect blockchain applications via the Application Blockchain Interface (ABCI). ABCI is an interface that defines the boundary between the replication engine (the blockchain) and the state machine (the application). Under the hood, ABCI implements a socket protocol that enables the consensus engine to run in one process and manage the application state in another separate process. Because of this, ABCI allows for blockchain applications to be programmed in any programming language. Besides, ABCI also makes it possible to swap easily swap out the consensus layer of any existing blockchain stack.

Cosmos SDK

The Cosmos SDK is the industry standard resource for building blockchains on Cosmos. It is a software kit that is built to deliver high speed and fast transaction throughput with low fees.

Transaction throughput is the rate at which valid transactions are committed by a blockchain in a defined period of time.

The Cosmos SDK is a generalized framework that simplifies the process of building blockchain applications on top of Tendermint. Its design is based on two major principles:

• Modularity. The goal of the Cosmos SDK is to create an ecosystem of modules that can be reused and implemented by community developers to easily spin-up application-specific blockchains. This will save development time, since developers will not have to build from scratch each bit of functionality of their application. Anyone can create a module for the Cosmos SDK using the readily available tools. These modules can then be imported into applications to serve a specific need.
  • For example, the Tendermint Core team is building a set of basic modules that are required for the Cosmos Hub. These modules can be used by any developer to build their custom applications.
• Capabilities-based security. Capabilities constrain the security boundaries between modules. This enables developers to better reason about the composability of the modules they are using in their code and make decisions to limit the scope of malicious code or unexpected interactions. 

In the context of Cosmos, a module is a substrate of the state-machine that lies underneath the blockchain

The Cosmos SDK also comes with tools that allow developers to build on top of the Tendermint BFT algorithm. However, the Cosmos SDK can also be used with any other consensus engine that implements the ABCI socket protocol.

The modularity of the Cosmos SDK also allows developers to port virtually any existing blockchain codebase that is written in Golang on top of it. Ethermint is an example of this. It is a project that ports the Ethereum Virtual Machine into an SDK module. This allows the codebase to benefit from the capabilities of Tendermint while also being compatible with generalized Ethereum tools such as Metamask, Hardhat…

Learn how to code applications on top of the SDK:

https://tutorials.cosmos.network/

IBC

Secularly known as the “pulse of Cosmos”, Inter-Blockchain Communication is the standard protocol for interoperability between chains in the ecosystem. This facilitates the transfer of both assets and data between each other in a frictionless and seamless manner.

Interoperability is the process by which independent and sovereign chains can communicate, interact, and exchange assets in a decentralized and trustless environment.

The Cosmos SDK enables blockchains to have their custom functionality and requirements, while the Inter-Blockchain Communication (IBC) protocol allows for the connection of those sovereign blockchains to transfer value (assets) and data between each other.

IBC leverages the instant finality of Tendermint as well. This allows for the creation of an ecosystem made out of heterogeneous blockchains with different applications and validators set. For example, this allows public and private blockchains to transfer tokens to each other.

A blockchain is considered to be heterogeneous when it abides by the following properties:

• Heterogeneous blockchains have different layers, meaning that they can differ in how they implement the networking, consensus and execution mechanisms. To be compatible with the IBC protocol, a blockchain only needs to meet a few requirements where the most important is that the consensus layer must have fast finality (this is not the case for blockchain that use probabilistic finality, such as Bitcoin and Ethereum.
• Sovereignty: Every blockchain is maintained by its own validator set.

How IBC works:

1. Tracking both validator sets of chain A and chain B. Each chain will run a light of the other.
2. Bonding when the IBC transfer is initiated, such that ATOM tokens are locked up on chain A.
3. Proof of relay to ensure that ATOM tokens are relayed from chain A to chain B.
4. Validation by verifying on chain B that chain A’s header is valid and the ATOM tokens have been bonded.

In the example above, note that the ATOM tokens that have been created on chain B are not a real representation of ATOM tokens. Instead, those ATOM tokens only exist on chain A. Those tokens on chain B are a representation of the original ATOM tokens that are frozen on chain A.

Interchain security (ICS)

Interchain security is achieved by using a shared security model that relies on Staked ATOM to secure chains other than the Cosmos Hub. In practice, this allows validators to secure chains in the Cosmos ecosystem that request this security feature. On an opt-in basis, these chains can request access to the security of the Cosmos Hub with their ATOM delegation as collateral.

V9-Lambda upgrade

On March 7 2023, a proposal to upgrade to V9-Lambda, the first version of ICS (also known as replicated security), was passed. The update is intended to go live on March 15 2023.

This upgrade allows the Cosmos Hub to provide its strong security to other blockchains, which are called “consumer chains”. The cost to censor or control a consumer chain with an economic attack is the same as the cost to censor or control the Cosmos Hub itself. This means that consumer chains can benefit from the Cosmos Hub’s security without having to maintain their own validator sets.

Replicated Security works through the IBC (Inter-Blockchain Communication) protocol.  This way, consumer chains receive periodic IBC packets containing the up-to-date validator set of the Cosmos Hub. They use this information to update their own validator sets, effectively replicating the Cosmos Hub’s validator set across all consumer chains. This means that the Cosmos Hub’s validators can validate multiple blockchains at once with the same stake.

In exchange for this service, consumer chains are expected to send a portion of their fees and inflation to the Cosmos Hub validators and delegators. These tokens will then be included as part of the Cosmos Hub’s staking rewards.

Staking

Similar to other networks, staking on Cosmos consists of locking up assets to provide economic security for a public blockchain. Since Tendermint can replicate arbitrary transactions in the network, it is possible for the consensus engine to define a currency that must be “bonded” by validator nodes to make sure that all economic guarantees are rightfully fulfilled.

Staking ATOM is a necessary condition to secure the Cosmos HUB. Also, staking ATOM grants the right to vote on proposals and make decisions on the future of the network.

When the staking transaction is complete, rewards start to accrue immediately. Stakers can send a transaction at any time to claim staking rewards. These rewards come from:

• Transaction fees collected on the Cosmos Hub
• Newly issued ATOM from inflation

When a user stakes ATOM, those tokens are locked up for an indefinite period of time. While the delegated ATOM cannot be transferred, users can trigger withdrawals to claim the rewards they earned for securing the network (this process is called “undelegating”). When a user undelegates to claim staking rewards, the user is subject to a 21 days waiting period.

Bridging non-Tendermint chains

Cosmos is not necessarily limited to Tendermint chains. In fact, any other chains can be connected to Cosmos, regardless of the underlying consensus mechanism.

Non-tendermint chains can be classified into two categories:

• Fast finality chains that use any fast-finality consensus algorithms can connect with Cosmos by adapting IBC.
• Probabilistic chains that do not have fast-finality consensus algorithms, like Proof of Work chains, require a more specific process that involves a proxy-chain called a Peg-Zone
  • A Peg-Zone is a blockchain that tracks the state of another blockchain. This is achieved by acting as a bridge between the Cosmos Network and the blockchains that do not have fast finality. The Peg-Zone would allow for example, the transfer of assets from Cosmos to Ethereum (the Cosmos tokens would become ERC-20 assets on the Ethereum chain).
  • First, the Peg-Zone needs to decide on a finality threshold for the origin chain (e.g set a finality threshold when 100 blocks are added to the chain).
  • Second, a contract is deployed to the probabilistic chain. Users will send the tokens to this contract, which will freeze the assets until the finality threshold is reached. Next, the assets are released on the Peg-Zone. A similar mechanism applies in the reverse direction.

Sending tokens to the Cosmos Hub

For sending tokens to the Cosmos Hub, each bridge-zone validator would run both a Tendermint-powered blockchain with a special ABCI bridge-app, and a full node of the “origin” blockchain.

When new blocks are mined on the “origin”, the bridge-zone validators will reach an agreement on the committed blocks. Once the bridge-zone receives the tip payment on the origin chain, a corresponding account with that balance is created on the bridge-zone.

• In the case of Ethereum, the bridge-zone and the Cosmos Hub can share the same validator set such that, on the Ethereum side, the bridge contract would allow holders of ether to send the ERC20 assets to the bridge contract on Ethereum. Once the ether is received by the bridge contract, it remains locked and will not be possible to withdraw unless an appropriate IBC packet reaches the bridge contract from the bridge zone.
• In the case of Bitcoin, the process is similar except that instead of using a bridge contract, each UTXO is controlled by a threshold multisignature P2SH pubscript. Because of technical limitations, the signers cannot be identical on the Bitcoin network and on the Cosmos Hub validator set.

P2SH refers to a set of addresses in the Bitcoin network that allow the creation of other addresses that can receive or send transactions. These addresses specify a series of conditions that must be fulfilled in order to unlock the balances.

UTXO stands for Unspent Transaction Output. It is a technical concept that describes the change in account balances after an asset transfer transaction.

Withdrawing tokens from the Cosmos Hub

• In the case of Ethereum, the bridged ether that lies on the bridge zone can be transferred from the Cosmos Hub while being destroyed later with a transaction that points to a withdrawal address on Ethereum. This is achieved by using an IBC packet that proves that the transaction has taken place in the bridge zone. This proof is then posted to the Ethereum bridge contract to allow the ether tokens to be withdrawn
• In the case of Bitcoin, because of the limited functionality of its scripting language, every UTXO will have its own pubscript such that each UTXO must be migrated to a new UTXO whenever there is a change in the set of Bitcoin escrow signers.

Investors

Business Model

Users can become validators, meaning they operate validator nodes that help secure the Cosmos Hub, and are paid in ATOM in return for their services.  People that cannot or do not want to operate validator nodes can participate in the staking process and contribute to the Cosmos Hub’s security as delegators. The requirement to be a delegator is to hold ATOM and send a delegate transaction specifying the number of ATOM tokens that they want to bond to a validator node. Later on, if the delegator wanted to get its assets back, it would submit an “unbond transaction”. When that happens, delegators are forced to wait 3 weeks before they can retrieve their assets.

Delegators share the revenue of their validators. Similarly, they are also exposed to the same risks. In terms of revenue, validators can choose to apply a commission on the income that is distributed to delegators.

Validators are incentivized to participate in staking to earn revenue from:

• Block rewards
• Transaction fees

The total revenue generated in the chain is divided among validators’ staking pools according to the validator weights. After that, the rewards are distributed within each validator’s staking pool in proportion to each delegator’s stake. A commission on the delegator’s revenue will be applied before the distribution (this is the validator commission).

Revenue Streams

When users stake ATOM, rewards start to accrue immediately. Stakers can send a transaction at any time to claim staking rewards. These rewards come from:

• Transaction fees collected on the Cosmos Hub
• Newly issued ATOM from inflation

The value of the network is often assessed by the revenue generation of the aggregate chains in the ecosystem. By assessing the total number of transactions and estimating the average cost per transaction, it is possible to estimate the total revenue generated from fees.

When it comes to the ATOM token, the asset has a current circulating supply valued at $2.86B.

Data from TokenTerminal:

 

Circuit Breaker Module

The Circuit Breaker Module (CBM) was introduced on July 18, 2023.

A single hack or bug can force a chain to shut down, causing significant losses. The CBM was developed to solve this problem. It functions like the emergency measure, when something goes wrong, the CBM can disable specific transactions, preventing disruptions to other applications built on the chain.

The initial version module is designed to focus on message types and prevent disabled messages from entering the mempool and being executed in the state machine. A message is a fundamental unit of transaction in blockchain applications, which instructs the application to perform certain actions.

The CBM enables accounts to trip or reset the circuit breaker for specific message types or all message types, depending on the permission level granted. By implementing the CBM, blockchain developers can enhance their applications’ robustness and reliability by allowing specific messages to be disabled temporarily to prevent disruptions. This, in turn, enhances the overall performance and stability of the blockchain, ensuring the continued trust and confidence of the users.

Liquid Staking Module

The Liquid Staking Module (LSM) was introduced on September 13, 2023.

With LSM the Hub unlocks new dynamics within the $ATOM Economic Zone. This upgrade allows users to directly liquid-stake their already staked $ATOM without waiting for the unbonding period. This functionality was launched with partnership from Iqlusion, Stride, and Binary Builders. The LSM introduced a new level of DeFi for the Cosmos Hub by quickly unlocking stATOM for numerous $ATOM stakers without compromising yields from staking.

To mitigate liquid staking risks, LSM introduces governance-controlled parameters, and as an additional security feature, validators who want to receive delegations from liquid staking providers would be required to self-bond a certain amount of $ATOM.

Economics

Fee Breakdown

Services provided on the Cosmos ecosystem generate fees. The more fees are paid by services, the higher the rewards for staked ATOM holders.

Cosmos Hub validators can accept a variety of assets and also a combination of multiple assets as fees for processing transactions. Besides, each validator can set whatever exchange rate it wishes as long as the block gas limit is not exceeded.

Out of all the collected transaction fees, there is a default 2% reserve tax that goes toward the reserve pool. This increases the security and economic value of the Cosmos network. The distribution of these funds can also be performed as per decided via governance voting.

ATOM holders who choose to delegate their voting power to validators in the network must take into account that they must pay a commission to the delegated node. This commission is set by each individual node.

Fee payments in assets other than ATOM are enabled by transaction tips. An example of this would be an Osmosis user who wants to vote on a proposal on the Cosmos Hub but he/she does not hold ATOM tokens. Rather than forcing the user to swap OSMO for ATOM tokens, transaction tips are a solution that solves that problem. The transaction initiator signs a transaction without specifying fees and, when the transaction is sent to a fee relayer, the relayer will choose the transaction fees and broadcast the transaction to the rest of nodes in the network. For instance, assuming 2 chains A and B, the following applies:

• The tipper will initiate the transaction execution on chain A while holding the native token of chain B (e.g. a tipper on Osmosis who wants to vote on Cosmos will initiate the transaction on chain B to execute it on chain A).
• The fee payer will relay and broadcast the transaction on chain A
• The target chain will execute the transaction.

How are fees distributed?

When a validator is selected to propose the next block, the validator must include at least ⅔ precommits of the previous block. However, there is a bonus incentive to include more than ⅔ precommits. This bonus is linear and ranges from 1% (if the ⅔ precommits minimum requirement  is met) to 5% if the proposer includes 100% precommits.

There is a tradeoff for validators that attempt to optimize for the maximum 5% bonus. If the validator waits too long or timeouts, then other validators will come up as the next proposer. Because of this, validators are incentivized to find a balance between wait-time to get the most signatures and risk of losing out on proposing the next block. This mechanism adds an extra layer of game theory to incentivize non-empty block proposals, better networking between validators, as well as mitigating censorship.

Operating Expenses

What are the slashing conditions for a validator?

If a validator misbehaves, their delegate stake is partially slashed. Two faults can result in slashing of funds for a validator and their delegators:

• Double signing. If someone reports on chain A that a validator signed two blocks with the same block height on chains A and B, then this validator is slashed with 5% of its block rewards on chain A.
• Downtime is punished when a validator misses more than 95% of the last 10,000 blocks (~19 hours). The slash amount is 0.01%.

Proof of Stake networks use a reward and penalty mechanism to incentivize good behavior of the nodes that secure the network. Validators receive rewards for both attesting and proposing blocks to the blockchain. However, bad behaviors and dishonest validation are punished with a mechanism called slashing. 

Slashing is a mechanism used by PoS networks to discourage harmful behaviors and help to keep the network secure. If there were no slashing penalties in a network, a validator could use its node to validate blocks on multiple chains, sign blocks simultaneously, or bee offline and not participate in the block attestation and proposal process.

Tokens

While the Cosmos Hub is a multi-asset distributed ledger, the ATOM token is the de-facto staking token of the Hub. Holding ATOM tokens is a requirement to participate in voting and to validate network transactions.

ATOM is an inflationary asset that is used to reward validators and delegators for their service. This is achieved by distributing inflation rewards as part of block transaction fees.

When it comes to utility, ATOM serves the following purposes:

• Act as a spam prevention mechanism by being used as the preferred token to pay for transaction fees. To avoid network congestion from spam transactions, the fee being paid is proportional to the amount of computing power required by the transaction.
• Be the staking token that can be bonded in order to earn block rewards. The economic security of the Cosmos Hub is a function of the amount of ATOM tokens staked. The higher the amount of ATOM collateral in the network, the higher the cost of executing an attack against the network.
• Serve as the governance token that is used for participating in governance proposals.

Token Distribution

The Interchain Foundation ran multiple private investment rounds that culminated in a token ICO on April 6, 2017

Upon Genesis, the initial distribution of ATOM tokens and validator rewards was allocated as follows:

• Cosmos Fundraiser: 75%
  • 67.9% for public contributors.
  • 7.1% for strategic and early adopters.
• Cosmos Network Foundation: 10% to pursue Research and Development.
• ALL IN BITS, Inc: 10% for developing the open source IP used in the Cosmos Network.
• Lead Donor: 5% for seed contributors.

From Genesis onward, every year ⅓ of the total amount of tokens is rewarded to bonded validators and delegators. In Genesis, there was an initial number of 100 validators. This number would later on increase at a rate of 13% for the next 10 years and finally settle after reaching 300 validators.

Currently, ~65% of ATOM is staked, rewarding contributors with an annualized yield of ~19% paid in ATOM. A lot of the growth in the staking ratio was fueled by the introduction of Liquid Staking derivatives, which allow users to stake ATOM with no lock-up period, while also receiving a derivative of their bonded assets that can be used all across the Cosmos network.

ATOM’s targeted annual inflation rate is recalculated on a per-block basis. This inflation rate is also dependent on the desired staking participation ratio, currently set at 67%. There is a maximum annual inflation rate capped between 7% and 20%, such that:

• If more than ⅔ of ATOM tokens are staked, the ATOM block rewards will decrease gradually down to a floor of 7% annualized inflation.
• If less than 7% of ATOM tokens are staked, the block rewards will increase gradually up to a ceiling of 20% annualized inflation.

Staking

Similar to other networks, staking on Cosmos consists of locking up assets to provide economic security for a public blockchain. Since Tendermint can replicate arbitrary transactions in the network, it is possible for the consensus engine to define a currency that must be “bonded” by validator nodes to make sure that all economic guarantees are rightfully fulfilled.

Staking ATOM is a necessary condition to secure the Cosmos HUB. Also, staking ATOM grants the right to vote on proposals and make decisions on the future of the network.

When the staking transaction is complete, rewards start to accrue immediately. Stakers can send a transaction at any time to claim staking rewards. These rewards come from:

• Transaction fees collected on the Cosmos Hub
• Newly issued ATOM from inflation

When a user stakes ATOM, those tokens are locked up for an indefinite period of time. While the delegated ATOM cannot be transferred, users can trigger withdrawals to claim the rewards they earned for securing the network (this process is called “undelegating”). When a user undelegates to claim staking rewards, the user is subject to a 21 days waiting period.

Governance

As a set of independent and parallel distributed ledgers, all ecosystem upgrades are subject to a governance system. Validators and delegators on the Cosmos Hub can vote on proposals that can change preset parameters of the system (such as block gas limits), coordinate upgrades, as well as vote on amendments to the governance policies of the Cosmos hub. This cohesive mechanism allows for the coordination of stakeholder decisions on issues such as theft, bugs, security incidents…

Cosmos gives communities the power to organize and allocate resources as per the results of token-gated decisions. The information is free to flow without being hindered by centralized entities that can censor and filter content to extract value from its users. Indeed, Cosmos empowers communities to build autonomous social networks where every user can have a voice, create value, and benefit from the value creation of others.

Each Zone on Cosmos can have their own constitution and governance mechanism. For example, the Cosmos Hub could have a constitution that enforces immutability at the Hub layer, while each Zone could set their own specific policies.

By enabling interoperability among different policy zones, the Cosmos network gives its users ultimate freedom and potential for experimentation in a permissionless fashion.

The Cosmos Hub is operated by a distributed organization that is responsible for coordinating system parameters, constitutional amendments, and software upgrades.

• All validators are responsible for participating in governance and, if they fail to vote on time, they will be automatically deactivated from the network for a period of time called the “absenteeism penalty period”, which is set at 1 week by default.
• Every proposal requires a minimum deposit of tokens consisting of a combination of assets including ATOM. For each proposal, the voters may vote to take the deposit (for example, validators may choose to take the deposit to dismiss a proposal)
  • If more than half of the voters vote in favor of taking the deposit, this deposit will go to the reserve pool and the corresponding amount of ATOM tokens will be burnt.
  • For every proposal, voters can vote one of the following options:
  • Yea
  • YeaWithForce
  • Nay
  • NayWithForce
  • Abstain
• A strict majority of Yea and YeaWithForce votes is required to pass the proposal. Similarly, a strict majority of Nay and NayWithForce votes is required to dismiss the proposal.
• When a proposal is dismissed, it is declared as “vetoed” and everyone is punished with a default penalty of 1 day worth of block fee rewards. Additionally, the party that vetoed is punished by losing 0.1% of its ATOM tokens (default value).

List of current proposals: https://www.mintscan.io/cosmos/proposals

Governance of the Cosmos Hub

The Cosmos Hub has on-chain governance responsible for passing text proposals, changing consensus parameters, and spending funds from the community pool.

The proposal period consists of 2 periods:

• The deposit period lasts either 14 days or until 64 ATOM tokens are deposited into the proposal, whichever happens first
  • Deposit amounts are at risk of being burned when the proposal is vetoed (i.e. 33.4% of the voting power backing the ‘NoWithVeto’ option as documented in the Cosmos SDK Governance Module Spec.
  • Deposits of both passed and failed proposals are returned to contributors
• The voting period is currently set to a fixed 14-day period where participants must select a vote of either ‘Yes’, ‘No’, ‘Abstain’, or ‘NoWithVeto’.
  • ‘Abstain’ means that the voter is impartial to the outcome
  • ‘Yes’ indicates approval of the proposal in its current form
  • ‘No’ signals disapproval of the proposal in its current form
  • ‘NoWithVeto’ indicates strong opposition. Voters are expected to select this option when a proposal leads to undesirable outcomes for the community. 

There are 4 criteria that determine whether a governance proposal passes or not:

• A minimum of 64 ATOM is required for the proposal to enter the voting period.
  • This deposit must be reached within 14 days since the proposal’s submission.
  • Anyone can contribute to this amount.
• A minimum of 40% of the network’s voting power (quorum) is required for a proposal to be considered ‘valid’.
• A simple majority (more than 50%) of the participating power must back the ‘Yes’ option.
• Less than 33.4% of the participating voting power votes ‘NoWithVeto’.

Voting power is determined by stake weights at the end of the 14-day period and is proportional to the number of total ATOM tokens participating in the vote. It is important to note that only bonded ATOM tokens count towards the voting power for a governance proposal (liquid ATOM tokens do not count toward a vote or quorum).

Types of proposals supported by the Cosmos Hub

• Community Pool Spend proposals seek to spend funds from the community pool on an important ecosystem project.
• Parameter Change proposals aim to change a core on-chain parameter.
• Text proposals seek to reach an agreement between participants on a certain strategy, plan, commitment, or future upgrade. Text proposals are a simple signaling mechanism and focal point for future coordination, which means that text proposals do not directly lead to any changes being made to the protocol.

Best practices for drafting a governance proposal on Cosmos

• Engage and get feedback from the community: host an AMA, bring the idea to a podcast, share the idea on Discord/Telegram chats, on the forum…
• Follow a process to assess the chances of the proposal being successful:
  • Does it make sense?
  • Are there critical flaws?
  • Does it need to be reconsidered?
• Once the proposal is on-chain, the author will not be able to change it. As such, it is recommended to follow a template with the suggested sections:
  • Who is submitting the proposal?
  • The amount of parameters that will be changed by the proposal.
  • Deliverables and timeline.
  • Reasons for the proposal and potential impacts.
  • A short summary of the solution being proposed and future expectations.
• Formatting a proposal
• Submitting the Governance proposal

Risks

Technology risk

The network has been running in production since 2019 and has continued to evolve since then. As the chain implements new upgrades and continues to improve, there are still opportunities for the unfortunate introduction of bugs, code vulnerabilities…

Smart contract risk will be present across all chains that build on top of the Cosmos SDK, Tendermint, IBC… On the positive side, the failure of LUNA and Terra was due to an intrinsic mechanism design problem inherent to that specific chain and did not have any impact on the rest of the chains.

Financial risk

As any other asset in cryptocurrency, ATOM is exposed to a volatile environment that can also be highly dependent on the macroeconomic conditions of the world at a given point in time. The Cosmos network is still in its infancy state, as reflected by the experimentation of some failed projects.

When it comes to staking, the rewards that are accrued for securing the network are not risk-free. When users delegate ATOM to a validator, or run their own validator nodes, they must be aware that validators can be partially slashed if the node misbehaves. When this happens, the delegated ATOM are forfeited (burnt) and there is no possible recovery of the funds.

On the Cosmos Hub, there are two possible reasons for slashing:

• Slashing by 5% can occur if the validator signs two different blocks at the same block height (double signing).
• Slashing by 0.01% can occur if the validator is offline for too long. If a validator does not sign a minimum of 500 blocks out of the last 10,000 blocks, the validator will be slashed for downtime.

Regulatory risk

Cosmos was initially funded by a private token sale and ICO. This can potentially expose the project to some level of regulatory scrutiny. However, the technological infrastructure and active use cases of the network might be strong enough proof to show that the ATOM token is not meant to be a security.

A security is a fungible financial instrument that represents some form of financial value in the form of ownership, usually with an expectation of profit.

Security

The Cosmos network leverages the Cosmos SDK as an alternative approach to security based on the notion of object capabilities. While no framework can completely protect developers from introducing bugs and security breaches in their codebase, application-specific chains might offer more recoverability and self-healing mechanisms in case something goes wrong. This is not the case with other blockchains, whose entire attack surface relies on the Virtual Machine they are built on top of. As a result, the security analysis is simple in application-specific chains, since developers do not have to worry about the interactions between the application and the mechanics of the Virtual Machine.

• Developers can choose to develop in proven programming languages such as Go, Javascript, Rust… (instead of being forced to use the default programming machine supported by a  given virtual machine).
• Developers are not constrained by the cryptographic functions made available by the underlying virtual machine. Instead, teams can use their custom cryptography and rely on the functionality provided by well-audited and long-term supported libraries.
• Developers do not have to worry about potential bugs and security vulnerabilities that affect the virtual machine upon which all the applications of the ecosystem are built.

Delegator Security

• Social engineering exposes delegators to attack vectors in the form of phishing or spearphishing. Both of these attacks are responsible for approximately 95% of security breaches at the individual level.
  • Users should be skeptical of unexpected emails and attachments that might redirect to a compromised site that will steal sensitive personal information from the user’s computer
  • Users should do their own due diligence before purchasing ATOM to ensure that they are buying the native asset on a reputable exchange platform
  • No one from Tendermint or the Interchain team will ever contact a user to ask for personal credentials and help them to become delegators
  • It is recommended that users protect themselves by downloading the latest software updates from official sources.
  • Supply chain attacks are also an attack vector that can affect the security of vendors and suppliers of hardware wallets

Validator Security

Validators are expected to connect only to nodes that they fully trust. Most data centers will provide direct links to the networks of major cloud providers. Validators can use those links to connect to sentry nodes in the cloud. This mitigation technique shifts the burden of denial-of-service attacks from the validator’s node directly to its sentry nodes.

Denial of Service Attacks

The most concerning attack vector for validators is Distributed Denial of Service attacks (DDoS). These attacks occur when an attacker attempts to flood a network by increasing the traffic in the network with the intent to bring down the network.

The process for executing a DDoS attack starts with a network scan where the attacker first attempts to learn the IP addresses of various validator nodes. After that, the attacker will attempt to disconnect them from their communication with each other by flooding them with network traffic.

One of the recommended ways to mitigate this risk is for validators to carefully structure their network topology by using a sentry node architecture. The Sentry Node Architecture (SNA) is achieved by deploying multiple distributed nodes in a cloud environment. This allows for easy scaling and makes it harder to scan and target validator nodes.

The proposed diagram above splits backend services in a private network for a validator in a data center. At the same time, the data center network might involve multiple subnets, firewalls, and redundancy devices. Using the private network, all sentry nodes (the frontend) can connect to the validator, which will not need to have an IP address to provide its service. By doing this, the validator will only maintain communication with sentry nodes, while sentry nodes will have the ability to talk to both the validator nodes in their private network and public nodes located elsewhere in the Internet.

Man-in-the-middle attacks

If one of the HTTP ports open to the Internet is not protected against man-in-the-middle attacks, a malicious attacker can present an altered state of the network to that given validator node and force it to behave incorrectly from a networking perspective. This does not impact the Cosmos Hub, but it can be detrimental on an individual node basis since it can lead to the slashing of the node’s tokens.

A man-in-the-middle attack is a cyberattack where the attacker secretly relays and alters the communications between two parties who believe that they are directly communicating with each other.

Project Investors

Cosmos was co-founded by Jae Kwon and Ethan Buchman in 2014. The ICO of the native ATOM token took place in 2017. Two years later, in 2019, the network was ready to use.

Cosmos raised a total of $17M in 7 funding rounds led by Paradigm, followed by 1Confirmation, IOSG Ventures, Yield Ventures, Cardinal Capital, and Kenneth Bok (managing director Blocks, a web3 advisory firm).

Other investors include Blocktree Capital, Dokia Capital, HashKey, KR1, Pantera Capital, Polychain Capital, Waterdrip Capital, Block0, Continue Capital, DragonFly Capital, Hyperchain Capital, Outlier Ventures, and SNZ.

FAQ

• Why bother creating a blockchain with the Cosmos SDK instead of deploying a decentralized application on top of a Virtual Machine blockchain?
  • This is a justified question that will depend on the use case of the application. Today, most applications are deployed on top of existing virtual machines like the Ethereum Virtual Machine. Because of this, Ethereum is the most popular blockchain when it comes to transaction volume and active users. However, up until now, it was a lot harder and resource intensive to build blockchains than to code smart contracts. With the introduction of the Cosmos SDK, this is not the case anymore. It allows developers to easily spin up application-specific blockchains that are flexible, secure, performant, and overall benefit from the modularity and composability of the SDK modules.
• What is the token of the Cosmos ecosystem?
  • As an ecosystem of independent blockchains, there is an arbitrary number of tokens that are supported on Cosmos. However, the Cosmos Hub has its own token, ATOM.
• Why is Cosmos referred to as “the Internet of Blockchains”? What’s the difference between Hubs and Zones?
  • The Cosmos ecosystem is known as the “internet of blockchains” because it enables interoperability across the different networks it supports.
  • Hubs act as the routers that facilitate the communication between chains.
  • Zones are the application-specific blockchains that are connected to the hub in order to establish a connection with other zones.
  • Altogether, this ecosystem of hubs and zones can serve as an analogy of how the Internet works.
• What are the infrastructure requirements for running a validator node?
  • For more information, it is recommended to carefully look at the different validator setups described in the Sentry Node Architecture guide.
  • A Community Forum post has been written with additional links and information with more extensive tutorials about how to set up a validator node.
• Is Cosmos a sidechain project?
  • At its core, Cosmos can be classified as a sidechain. The Cosmos SDK is the framework by which developers can easily build and spin up their own application-specific chains.
  • These chains are called ‘Zones’ in the Cosmos-speak and can be connected to the Cosmos Hub via Inter-Blockchain Communication in order to be interoperable with other chains connected to the Hub.
• Does Cosmos intend to replace Ethereum?
  • Cosmos’ main goal is not to replace Ethereum or act as a drop-in replacement for EVM-compatible or any other monolithic chain.
  • The value proposition of the Cosmos network is to provide developers with a set of tools and development frameworks that allow for innovative use cases around interoperable and modular blockchains.
• What is staking?
  • Staking is the process by which Proof of Stake blockchain bond tokens as collateral to secure the network.

• What is a full node?
  • A full node is a server on the network running a chain’s software to keep a full record of all historical activity.
• Can a validator run away with their delegated ATOM tokens?
  • By delegating to a validator, users are delegating their voting power to a node in the network. The more voting power a validator has, the higher its influence in the consensus and governance process.
  • However, this does not mean that the validator will be custodian of the ATOM tokens that have been delegated to. Therefore, a validator cannot run aways with its delegated funds.
• Are ATOM validators required to self-delegate ATOM?
  • Yes, there is a requirement for every validator node to self-delegate at least 1 ATOM. However, there is no obligation to self-delegate more than 1 ATOM.
  • If a validator’s self-delegation goes below the minimum threshold, the validator gets jailed and kicked out of the active validator set (its delegators remain bonded to it).
• How does Cosmos prevent the concentration of staking power in the hands of a few top validators?
  • The community is responsible for encouraging decentralization in a self-preserving way. This is facilitated by adding the concept of delegators. When delegators switch to another validator, they are no longer subject to the unbonding period, which removes any barrier to quickly redelegate their tokens to favor decentralization.

Community Links

• Website: https://cosmos.network/ 
• Whitepaper: https://v1.cosmos.network/resources/whitepaper 
• Twitter: https://twitter.com/cosmos 
• Telegram (community chat): https://t.me/cosmosproject
• Discord (developer chat): https://discord.gg/cosmosnetwork 
• Medium: https://blog.cosmos.network/
• Reddit: https://reddit.com/r/cosmosnetwork 
• Youtube: https://www.youtube.com/c/CosmosProject 
• Cosmos Forum: https://forum.cosmos.network/ 
• Github: https://github.com/cosmos 
• Email: hello@cosmos.network 
• Ecosystem: https://v1.cosmos.network/ecosystem 
• Contributors: https://v1.cosmos.network/contributors 
• Grants: https://v1.cosmos.network/contributors 
• Developers:
  • Developers portal: https://tutorials.cosmos.network/ 
  • Ignite CLI: https://ignite.com/ 
  • Cosmos SDK: https://docs.cosmos.network/
  • Tendermint Core: https://docs.cosmos.network/ 
  • Cosmos Hub: https://hub.cosmos.network/ 
  • IBC: https://ibc.cosmos.network/ 
• Cosmos SDK:
  • SDK Docs: https://docs.cosmos.network/ 
  • SDK Forum: https://forum.cosmos.network/c/cosmos-sdk 
  • SDK Chat: https://discord.gg/cosmosnetwork 
  • Developer resources: https://github.com/cosmos/awesome-cosmos 
  • SDK tutorials: https://tutorials.cosmos.network/ 
  • Building modules: https://docs.cosmos.network/main/building-modules/intro 
  • Running a node: https://docs.cosmos.network/main/run-node/keyring 
  • Ignite CLI: https://github.com/ignite/cli 
  • Github: https://github.com/cosmos/cosmos-sdk/
• Tendermint Core:
  • API (Go Docs): https://godoc.org/github.com/tendermint/tendermint
  • REST Docs: https://docs.tendermint.com/master/rpc
  • Developer chat: https://discord.gg/cosmosnetwork 
  • Forum: https://forum.cosmos.network/c/tendermint 
  • Starter guide: https://docs.tendermint.com/master/ 
  • Github: https://github.com/tendermint/tendermint 
  • Documentation: https://docs.tendermint.com/master/ 
  • Video content: https://www.youtube.com/playlist?list=PLdQIb0qr3pnBbG5ZG-0gr3zM86_s8Rpqv 
• IBC:
  • Starter guide: https://ibcprotocol.org/ 
  • Github: https://github.com/cosmos/ibc-go 
  • Specification: ​​https://ibcprotocol.org/documentation 
  • Video content: https://www.youtube.com/playlist?list=PLdQIb0qr3pnAFvKNxbmxhW0RHcEG1OdMe
  • Developer chat: https://discord.gg/cosmosnetwork 
• Wallets:
  • Atomic wallet (Android, Linux, MacOs, Windows): 
  • Citadel One (Android, iOS)
  • Cobo (Android, iOS)
  • Cosmostation (Android, iOS)
  • Crypto.com (Android, iOS)
  • Huobi Wallet (Android, iOS)
  • imToken (Android, iOS)
  • Keplr (web)
  • Ledger (hardware)
  • Lunie (web)
  • Math wallet (Android, iOS, web)
  • Rainbow wallet (Android, iOS)
  • Trust wallet (Android, iOS)
  • Wetez (Android, iOS)
• Block explorers: 
  • Atomscan: https://atomscan.com/ 
  • Bscscan: https://bscscan.com/token/0x0eb3a705fc54725037cc9e008bdede697f62f335 
  • Etherscan: https://etherscan.io/address/0x8D983cb9388EaC77af0474fA441C4815500Cb7BB 
  • Big Dipper: https://bigdipper.forbole.com/ 
  • Cosmos Overview: https://cosmos-overview.genesislab.net/ 
  • Cosmos Visualizer: https://nylira.net/3d 
  • Cosmoscan: https://cosmoscan.net/ 
  • Hubble: https://hubble.figment.network/ 
  • Lunie: https://lunie.io/  
  • Mintscan: https://www.mintscan.io/ 
  • Anthem: https://anthem.chorus.one/ 
  • ATOMScan: https://atomscan.com/ 
  • Stargazer: https://stargazer.certus.one/ 
  • LOOK explorer: https://cosmos.ping.pub/ 
  • Union Market: https://union.market/token/cosmos 
• Cosmos hub mainnet: https://github.com/cosmos/gaia 
• Connect chains: https://tutorials.cosmos.network/hello-world/tutorial/ 
• Exchange and wallet Integrations: https://discord.gg/cosmosnetwork 

Becoming a validator: https://discord.gg/cosmosnetwork