The Key Ideas Behind the Cosmos Network

Chorus One
Chorus One
March 11, 2019
5 min read
March 11, 2019
5 min read

Part I: PBFT, Security Bonds, Validators and Delegators

This is the first part of a 3-piece blog series on the key ideas behind the Cosmos Network.


In March 2019, one of the promising Blockchain 3.0 projects — the Cosmos Hub — goes live. It delivers the ability to build an Internet of Blockchains — myriad decentralized ledgers, hosting disparate financial applications, able to coordinate the movement of financial assets between each other. Understanding the Cosmos vision and its implementation is valuable for cryptocurrency technologists and investors, since the upside is massive. This is the story of the key ideas behind Cosmos, and how they came to be. We start off in 2014, with Jae Kwon’s vision of consensus without mining. One by one, we’ll covers five key ideas leveraged by the Cosmos team to arrive at the current system. These key concepts are:

  1. Utilization of message passing BFT consensus, instead of Proof of Work, to power a cryptocurrency ledger.
  2. The insight of restricting the participants of a BFT consensus via security bonds in a cryptocurrency token.
  3. (1) and (2) combine to define the role of a validator.
  4. The design of separating out consensus and application logic, leading to application-specific blockchains.
  5. The ability for blockchains to send authenticated value carrying messages to each other, via Inter Blockchain Communication.
  6. The construction of a “clearing blockchain”, the Cosmos Hub, to enable movement of messages between application-specific blockchains and thereby realize an Internet of blockchains.

If the above looks unfamiliar, you’re in the right place! Reading this set of two articles, will position you to follow the conversations around this quantum leap in blockchain technology. This article covers concept (1)-(3) while later articles cover concepts (4)-(6).

Humble Beginnings

Our story starts in 2014. Back then the first wave of Bitcoin 2.0 projects like Colored Coins, Mastercoin and Peercoin were in vogue. Most of these attempted to build on top of Bitcoin, but a few attempted to create Proof of Stake — a new way of securing cryptocurrency ledgers that would obviate the need for mining hardware, and reduce the operating costs of a cryptocurrency ledger. With bitcoin hovering around $600, miners were already spending over $400 million annually running their mining machines to operate the Bitcoin blockchain while concurrently delivering a capacity of fewer than 7 transactions per second. The need for a new way of coming to consensus over the balances of accounts was needed — ideally some method that would cut the annual operating costs 100-fold, so that an even more deflationary cryptocurrency could be realized. After all, these were the days cryptocurrency users watched over the inflation rates like hawks.

Out of these efforts, Peercoin and Nxt were the most prominent. The technical approach of both was to try to simulate mining using coin balances — deploy some mechanism that would scan the balances of all accounts, and randomly select some account to produce the next block. Higher the number of coins held by an account, higher the odds it would be selected to create the next block. It was as if the coins one held would become virtual ASIC miners, and periodically give one the chance to create a block and earn some reward. It was an approach headed for the dustbin of history, but we didn’t know that yet.

This is when Jae Kwon quietly entered the scene with a logical and deceptively simple idea: To leverage previous academic work around consensus protocols to build a cryptocurrency system called Tendermint. If anyone scanned the academic literature of consensus mechanisms from the last 15 years, they would have stumbled upon Byzantine Fault Tolerant consensus mechanisms like PBFT and DLS. These consensus mechanisms were built for scenarios where a group of accountants that ‘knew’ each other could jointly agree on the state of a system, for instance, a financial ledger (containing accounts and balances). These mechanisms were not suitable to build a system like Bitcoin. Bitcoin relies on permissionless entry — anyone can become an accountant for the Bitcoin network by setting up a mining pool. Academic consensus mechanisms were built for scenarios where some social/legal process would identify a known, closed set of accountants. Jae’s contribution was to marry the idea of security bonds, which we cover later, with classical consensus mechanisms to build a cryptocurrency network secured without mining.

These academic mechanisms, the most notable of which is Practical Byzantine Fault Tolerance, are best imagined as glorified roundtable voting systems. Imagine a roundtable with a lot of seats; each seat populated by an accountant as in the diagram below. In reality, these accountants are not humans but software running on disparate computers on the internet. These accountants carry their own individual copy of a financial ledger being maintained by the group. This ledger, the blockchain, is a set of ordered pages (also known as blocks) with each page containing user transactions. The role of PBFT is to ensure that books carried by the accountants stay synced up with each other and that there always is a single authoritative version of the book. One accountant is selected as a leader, and its role is to collate user transactions, package them up in a page, sign the page digitally and propose that the page is added to the ledgers of the other accountants. Accountants have communication channels open with each other. Other accountants receive the proposed page, verify the veracity of the accounting in it; sign and broadcast affirmative votes provided the accounting is correct. Once an affirmative quorum of ⅔ of the accountants is reached, the leader collects the affirmative votes and proposes the next page. The next page can contain proof that the previous page had sufficient affirmations. When the PBFT leader becomes unavailable, a new leader can be elected. This is the basic mechanism of updating the ledger — by the slow addition of pages containing user transactions, each page requiring a roundtable voting cycle.

Figure 1. An anthropomorphized rendition of Practical Byzantine Fault Tolerance. The leader is indicated at the top. Pink books indicate the shared authoritative ledger with each accountant possessing an individual copy. Page in the center represents the current proposal by the leader, tick marks represent affirmative votes for the proposal.

The beauty of PBFT is that it tolerates up to ⅓ of the accountants, including the leader, to be actively malicious. Below this threshold, actively malicious accountants cannot create invalid ledgers, and ledger users are safe against their malicious behavior. Another powerful property is that pages, once added to the ledger, are final and cannot be reversed. This is in contrast to Bitcoin where blocks added to the blockchain, can be replaced by new ones provided a sufficient number of miners actively work towards such an outcome. Finally, the system naturally has a few orders of magnitude lower operating costs per transaction as compared to Bitcoin.

Therefore, PBFT and its derivatives were the perfect building block for consortium blockchains. Consortia are able to select a set of its own members to run the accountants on their individual infrastructures, and be able to deliver a financial ledger to consortium users. Many permissioned blockchain projects, such as Hyperledger Fabric, Symbiont etc. have taken similar paths. One of the earliest permissioned ledger companies was Monax (previously called Eris Industries). Monax wanted to build a permissioned version of the Ethereum Virtual Machine and looked to replace Proof-of-Work with something more suitable. They discovered Tendermint in 2014 and became its first real user. So a short aside is that Tendermint has seen considerable usage among consortium blockchains for many years.

But let’s get back to the topic of cryptocurrency networks. The design we described does not work to build a cryptocurrency for it is infeasible to agree on a definitive set of accountants for a distributed, mutually untrusting, cryptocurrency community. In other words, we needed a mechanism that could allow anyone to spin up an accounting server, and be able to join the accounting set of a PBFT based cryptocurrency.

Security Bonds

A second key insight paved the way forward. Let’s first state the equivalent idea, in the world of human relationships. In situations where we need to trust other people/counterparties to behave well, security deposits are often instituted to guarantee good behavior. For example, in order to let an apartment, a landlord asks for financial value to be put into escrow. If the renter misbehaves, say by trashing some equipment in the apartment, the landlord has the recourse of using the escrowed financial value to make themselves whole. The act of putting financial value in escrow, with the threat of never receiving it back, creates economic incentives for good behavior for the renter.

The original Tendermint paper from 2014 applied the same dynamic to the scenario of sourcing accountants from a cryptocurrency community at large. Let’s say we had a cryptocurrency token at our disposal for escrow. Could we source a diverse group of accountants by requiring prospective accountants to place security deposits, in the form of this token, into escrow on the cryptocurrency ledger itself? Further, could one punish these accountants by destroying their security deposits if they misbehaved? Both of these have been demonstrated possible in a beautiful application of economic incentive design.

The Cosmos Hub has Atoms, with a starting supply of around 220 million, as its internal token. Accounts and Atom balances of the accounts are maintained in the ledger (the blockchain) of the Cosmos Hub. In order to select the accountants that would maintain the ledger, an option is created for any account holder to post its Atom balances as a security deposit and become an accountant for the ledger. Witness the beautiful circularity in the design: One has a ledger of Atom balances; particular holders of Atom balances are able to (voluntarily) use those balances as security deposits and become accountants; and the set of accountants chosen thus maintain and update the ledger. This is how the fundamental problem of selecting a group of accountants for PBFT flavored consensus algorithms was resolved in the Tendermint paper from 2014.

Of course, different accountants will post different amounts of security deposits. Those posting larger security deposits (like 10 million Atoms) have greater value at stake than those supplying smaller security deposits (like 1 million Atoms). If both these parties were to have an equal say in deciding which pages get added to the ledger; then there would be an enormous incentive for the larger security deposit accountant to split their deposit into smaller amounts, and get a bigger say. The only logical conclusion, therefore, is for the say, or voting power, of each accountant to be proportional to the security deposit posted by them.

Security bonds solved a separate, titanically important, problem in the cryptocurrency space — the problem of how to punish accountants for their misbehavior. Systems, prior to early Tendermint, had relied on attracting a set of accountants (miners) via the promise of inflationary rewards. One can think of these block rewards as a carrot — individual miners ran accounting systems for cryptocurrency in the expectation of inflationary rewards in the native tokens of the networks. In 2014, the Bitcoin system printed new bitcoin, worth $400 million plus, and awarded them to its set of functional accountants in 2014 — the Bitcoin miners. However, Bitcoin has no mechanism to actively punish a miner if they try to, say, include a fraudulent transaction in the network. Bitcoin possesses only carrots but no sticks!

Tendermint based cryptocurrencies including Atoms, however, institute mechanisms to punish misbehaving accountants — destroy part of their security bonds! It also rewards accountants the same way as Bitcoin, by inflating the token supply and distributing inflated tokens to the accountant set. This might seem like an innocuous difference, but it will become a centerpiece in our later blogs.

For example, one of the ways an accountant can misbehave is to attempt to vote twice, for two different pages, to be added at the same place in the ledger. Unlike a normal voting system, there is no central party like the Government to ensure that an accountant votes only once. Accountants are able to place two contradictory votes when two leaders propose pages concurrently. The ability to punish accountants is critical to disincentive such behavior. Other misbehaviors include the inclusion of invalid transactions in pages proposed by an accountant and being offline for extended durations of time. Each of these misbehaviors attracts penalties of varying amounts.

The Validator and the Delegator

This unique combination of security bonds for accountants, and the need for accountants to run open source software to maintain the blockchain created a new role, and a business opportunity. This new economic opportunity is to build infrastructure in order to be a validator — a party that supplies security bonds, and operates infrastructure to maintain different Tendermint blockchains as an accountant. Chorus One is one of those accountants: a validator for the Cosmos Hub.

This means that, if the Chorus accountant were to misbehave in any way, the firm stands to lose a significant amount of capital. Misbehavior can occur due to configuration faults, external attacks or rogue insiders. The difficulty of running a validator stems from the need to build a secure system that can ward off these different attack vectors through an intelligent design. We summarized part of our design, that leads us to be confident enough to post a large security bond, in this article.

The concept of a validator has existed since 2014 — it has taken half a decade to go from theory to practice to commercial business opportunity! The passage of time has introduced a new role in cryptocurrency systems based on Tendermint — the delegator. The fundamental issue that emerged with validation, is the disjointedness between the set of parties capable of running a validator; and the set of parties that held atoms. For instance, a hedge fund might hold millions of Atoms, but be unwilling to run validation infrastructure since it is not their core competency. Tendermint based cryptocurrency systems, including the Cosmos Hub, solve this problem by allowing accounts to delegate, or transfer, their voting power to other parties running a validator. Rewards from running the validator, are then split between delegators and validators. You can find out more about the validation-delegation relationship here.


In this article, we’ve covered the 3 keys ideas that Jae Kwon presented as a vision in 2014 — the decision to build a PBFT-inspired cryptocurrency design, the usage of security bonds to adapt the consensus mechanisms to a cryptocurrency setting, and the wholesale creation of the validation/delegation ecosystem.

It has been a long journey to go from ideation to a practical working system. The reward of the Tendermint design is a cryptocurrency ledger design (plus open source implementation) with low operating costs that can process hundreds of transactions a second. This in itself is a big contribution to the blockchain ecosystem.

But, the true revolutionary implications of the design are still to follow! In the next article, we will cover the business opportunities presented by application-specific blockchains. Someday in the future, the implementation of shared security or sortition security networks with the Atoms as a base currency will also be presented. All of these are key to understanding the opportunities in the Cosmos ecosystem. Stay tuned, and let us know your questions.

If you want to discuss Cosmos further, stop by our Chorus One Telegram and say hi. And, of course, we’re happy to answer any questions about delegating to Chorus One.

 Join our mailing list to receive our latest updates, research reports, and industry news.
Thanks for subscribing. Watch out for us in your inbox.
Oops! Something went wrong while submitting the form.