A Framework For Comparison: Research

Research Layer-1 Platforms:
A Framework
for Comparison
COMMISSIONED BY
PUBLISHED ON 08/11/2021
2
A Framework for Comparison
TH EB LOCK R ES E A RCH .CO M PU B LI S H DATE 08/11/21

Research Layer-1 Platforms: A Framework for Comparison
3
Introduction
Decentralization. Scalability. Security. They are words that are

thrown around a lot in the blockchain discourse. But what do they
really mean? And how should they be used to analyze different
blockchain networks?
Over ten years after the advent of Bitcoin, the quest for answers continues.
Bitcoin has thrown a monkey wrench into how we think about money.
It is radically transforming our notion of who controls it, how it is
controlled, and who can use it. It is bringing the revolutionary power
of decentralized computing to life and its digital cash network has
settled and secured trillions of dollars in value.
But Bitcoin is one part, albeit a very important part, of a broader

emerging decentralized economy. And if its introduction of digital
cash unlocked the door to this economy, Ethereum’s smart contracts
are kicking it wide open. They unleashed the power of blockchain
technology beyond payments to any application imaginable. To date,
we have caught glimpses of the impact of its technology. Foremost,
in the financial sphere with the rapid growth of stablecoins and
the explosion of activity across decentralized exchanges and lend-
ing protocols. Secondly, in the cultural sphere with the widespread
adoption and rise of non-fungible tokens (NFTs).
And who knows what new applications will emerge next year. Or the
year after that.
But the story doesn’t stop at Ethereum.
Dozens of smart contracting platforms have launched in tandem with

Ethereum’s rise. Some are seeking to offer an easily adoptable alter-
native to Ethereum and challenge its status as the de-facto platform
for launching decentralized applications. Others are taking a differ-
ent approach centered on giving developers the highest level of flex-
ibility in building their own blockchains and creating infrastructure to
facilitate cross-blockchain communication.

4
Introduction
They span platforms that very much embody the decentralized

ethos of Ethereum to others that are pushing the limits of what mini-
mal level of decentralization users will accept. They are making bold
technical design choices primarily aimed at delivering scalability; a
feature that Ethereum has historically lacked.
The breakneck pace of development and competition amongst these

platforms is not slowing down anytime soon.
Why are we writing this report?

While this emerging decentralized economy has seen exponential,
albeit lumpy, growth over the past years, we have only scratched the
surface in terms of discovering what experiences smart contracting
platforms are capable of delivering. As use cases evolve and appli-
cation development accelerates, platforms are poised to support
ecosystems orders of magnitudes larger than those we have seen to
date. Nonetheless, they already compose a material portion of the
investable crypto landscape today.
The Investable Crypto Landscape
With each passing year, the likelihood of a “one blockchain to rule

them all” outcome fades further and further into the rearview. But
analyzing these platforms continues to be a challenging task. Objec-

5
Introduction
tive and digestible comparisons amongst them are few and far
between. The lack of standards for discussing and analyzing them
causes headaches. Having a framework for comparing these plat-
forms will be important for years to come.
How we are structuring this report

Analyzing smart contracting platforms outside of the context of
Ethereum is difficult. Analyzing Ethereum outside the context of Bit-
coin is equally difficult. So, the report starts with an introduction to
Bitcoin, what it introduced, and the prospect for use cases outside
of payments on its platform. It then provides an introduction to smart
contract platforms, what they are used for, and dives into the current
state of Ethereum.
With this background, we analyze a select set of platforms. We com-

pare and contrast them across their technical designs, their block-
chain and ecosystem data, and the individuals and organizations
behind them. Finally, we use these comparisons to draw insights into
what the future of the broader smart contracting platform landscape
could look like.

6
Introduction
Commissioned by
Algorand Inc. - Algorand builds technology that accelerates the con-

vergence between decentralized and traditional finance by enabling
the simple creation of next-generation financial products, protocols,
and exchange of value. Founded by Turing Award-winning cryptogra-
pher Silvio Micali, Algorand’s platform is designed to handle the vol-
ume of transactions needed for Decentralized Finance (DeFi), finan-
cial institutions, and governments to smoothly transition into the
Future of Finance (FutureFi).
The Algorand Foundation - The Algorand Foundation is dedicated to

fulfilling the global promise of blockchain technology by leveraging
the Algorand protocol. With core beliefs in the establishment of an
open, public and permissionless blockchain, the Algorand Founda-
tion has a vision for an inclusive ecosystem that provides an oppor-
tunity for everyone to harness the potential of an equitable and truly
borderless economy.

7
Introduction
Acknowledgments
We would like to thank Algorand Inc. and the Algorand Foundation
for commissioning this research report and making its production
possible.
We are also grateful to those that shared their perspectives and

were interviewed for this report including individuals across the fol-
Author lowing organizations:
Andrew Cahill
Twitter • Algorand Inc. and Algorand Foundation (Algorand) – Keli Cal-
Linkedin
laghan, Paul Riegle, David Markley, Stephen Duignan
• Ava Labs (Avalanche) – Kevin Sekniqi, Lydia Chiu, John Nahas,
Eric Kang
• Binance (Binance Smart Chain) – Samsul Karim
• Tendermint, Interchain Foundation, Informal Systems, Sikka (Cos-
mos) – Peng Zhong, Billy Rennekamp, Ethan Buchman, Sunny
Agrawal
• Parity Technologies and Web 3 Foundation (Polkadot) – Peter
Mauric, Joe Petrowski
• Solana Labs (Solana) – Anatoly Yakovenko, Raj Gokal, Ben Sparango
Finally, we thank everyone at The Block who helped with its produc-
tion including Larry Cermak, Mika Honkasalo, and Igor Igamberdiev.
Additionally, we thank Aleksander Hamid for designing the report.
The author, Andrew Cahill, has holdings in the following tokens men-
tioned in the report: ALGO, ATOM, BTC, and ETH.

8
Introduction
Bitcoin Origins
There are many unknowns regarding Bitcoin’s pseudonymous cre-
ator(s), Satoshi Nakamoto. But a few certainties can be gleaned.
Satoshi was not living in a vacuum. And Bitcoin was not conceived
out of thin air.
Anonymous digital cash and pseudonymous reputation systems were

being designed in the 1980s. Proof of Work, a core design feature of
Bitcoin, was introduced as an anti-spam measure in the 1990s. And, at
the highest level, Satoshi put the two together to create Bitcoin in 2008.
The Bitcoin network is best described in a few select words.
It is censorship-resistant and decentralized. Bitcoin is not owned by

any single entity. While governments can enact legislation prohibiting
mining or transacting in Bitcoin, there is no universal “off switch” for the
network as it is operated by a global, distributed base of computers.
It is permissionless. Anyone can send, receive, and hold bitcoins

(“BTC”) from virtually anywhere on a 24/7 basis. Anyone willing to
invest in computer hardware can contribute to securing the network
through mining.
It is pseudonymous. The closest thing to identifiable people on the

network are strings of alphanumeric characters which in some cases,
can be mapped to certain individuals, but in other situations repre-
sent groups of individuals or corporations.
It is secure. Bitcoin miners are economically incentivized to secure

the Bitcoin network and they earn BTC in return for doing so. BTC’s
disinflationary issuance schedule introduced a new-found model
for bootstrapping network security and has allowed the network to
achieve a high level of security early in its life.
Beyond BTC: Omni Layer and USDT

Bitcoin’s most prominent use case to date has been settling and
storing value with its native asset, BTC. But its programming lan-

9
Introduction
guage, Script, allows for more complex transactions. Multi-signature

functionality can be used to restrict access of funds until a certain
number of distinct entities, such as two out of three, sign or approve
transactions. Data storage functionality allows users to write up to
80 bytes worth of data onto the Bitcoin blockchain and use it as an
immutable data ledger.
Accordingly, decentralized securities trading, property rights, and

self-sovereign identity were all concepts being explored in the Bit-
coin community as early as 2011.
Founded in 2012, the Omni protocol (originally named Mastercoin)

has been one of the most prominent users of Bitcoin’s capabilities as
an immutable ledger. It created a protocol for asset issuance using
Bitcoin’s data storage capabilities and has facilitated the creation of
hundreds of assets directly on the Bitcoin ledger.
Tether’s stablecoin, USDT, is the most prominent asset issued using

Omni. USDT is backed by a basket of assets that help it achieve a
peg to the value of the US Dollar. Among other use cases, traders
rely on it as a stable asset to park funds in on exchanges that do not
support traditional currencies.

10
Introduction
“At Tether, we truly care for Omni,

since it was the first protocol that
made Tether possible, and it also
relies on Bitcoin security. But we
had to give traders what they were While USDT was historically issued exclusively on
asking for” Omni for ~3 years, it started making its way onto
— Ethereum in 2018 and onto another smart contract
Paolo Ardoino, CTO at Tether platform, Tron in 2020. It has also been issued on
several other platforms including Algorand, Ava-
lanche, Solana, and EOS. As of today, only about 2% of the ~$63BN
worth of USDT in circulation resides on the Bitcoin blockchain.
Not all USDT are created equal

USDT is backed by the same basket of assets regardless of where
it is issued. Nevertheless, it inherits the performance and secu-
rity characteristics of whichever blockchain it is issued on and user
experience can vary widely on a chain-by-chain basis.
So, there are multiple reasons why USDT has become less popular
on Omni:
i. The cost to transact in USDT on Omni is high relative to other

chains as it necessitates effecting data storage transactions on
the Bitcoin blockchain.
ii. Confirmation times, or the amount of time before USDT trans-
actions are considered final, are high on Omni due to Bitcoin’s
10-minute block time and probabilistic finality.
iii. Ecosystem growth on other chains is driving demand for USDT on
their respective chains.
So, yes, USDT can be issued and transacted with on the Bitcoin
blockchain. But the more appropriate question to ask is: “does it
really need to be”. The numbers are speaking for themselves. Smart
contract platforms with lower fees and faster confirmation times,
albeit with different security profiles, are becoming a more popular
venue for USDT.
Beyond Payments: Sidechains and Smart Contracts

More generally speaking, changes to the Bitcoin software have his-
torically and will likely continue to be handled very conservatively.
Bitcoin does not rapidly adapt to the new demands of the market.

11
Introduction
For instance, the Taproot upgrade, which is expected to take effect

in November 2021 is the first major Bitcoin software upgrade in over
four years.
Given this conservatism and the relatively limited set of programma-

bility within Bitcoin software, the concept of creating auxiliary block-
chains, referred to as sidechains, was being researched in depth as
early as 2014. These separate chains typically aim to enhance per-
formance and provide a higher level of customizability than the core
platform, in this case, Bitcoin. They also leverage the core platform’s
established security profile to varying degrees. Rootstock (“RSK”) is
one example of these sidechains.
RSK leverages the security mechanisms of Bitcoin through a pro-

cess called merge mining. Through merge mining, miners who are
dedicating computing (hashing) power to securing the main Bitcoin
blockchain can opt-in to mining a secondary chain, in this case, the
RSK sidechain, and earn transaction fees generated on RSK. During
this process, data from blocks mined on the RSK sidechain is period-
ically hashed and inserted into the blocks of the primary blockchain.
Currently, the RSK sidechain is being merge mined by around 40% of
the hashing power on Bitcoin.
RSK also “re-uses” BTC as an asset on its sidechain. The network has
a two-way peg mechanism whereby BTC is exchanged for RSK Smart
Bitcoin (RBTC) on a 1:1 basis. This is facilitated by “pegging-in” BTC
by sending it to a multi-signature wallet on the Bitcoin blockchain
and minting RBTC on RSK. RBTC can then be “pegged-out” from RSK
to BTC on Bitcoin when nodes running the RSK pegging module, RSK
PowPeg, validate the withdrawal request. This allows RSK to leverage
BTC in a more flexible environment but introduces reliance on node
infrastructure independent of the Bitcoin network to facilitate these
pegging processes.
What can be built on RSK?

The RSK blockchain is compatible with the Ethereum Virtual Machine
(“EVM”) which executes transactions on the Ethereum blockchain.

12
Introduction
Hence, any applications supported on Ethereum can theoretically be

built on RSK.
Launched in December of 2020, Sovryn is one of the more promi-

nent projects building on RSK. The protocol is aiming to bring many
of the decentralized finance (“DeFi”) functions such as decentralized
exchange and lending, to the Bitcoin ecosystem by employing RSK
smart contracts. While it has seen some adoption since its launch,
other platforms such as Ethereum and Binance Smart Chain are sup-
porting DeFi ecosystems orders of magnitude larger than what RSK
has achieved to date.
Ethereum as a Bitcoin sidechain

In one sense, Ethereum has been Bitcoin’s biggest sidechain to date.
While it does not leverage Bitcoin’s security framework, it is the big-
gest venue for “re-using” BTC in a more flexible environment with
smart contracts.
Upwards of 245,000 synthetic BTC (assets whose value is tied to

BTC and issued on Ethereum through similar pegging mechanisms),
worth ~$8.5BN, have been ported to the Ethereum blockchain. This
far exceeds the current amount of BTC that can be ported onto RSK
as its PowPeg is currently capped at 3,000 BTC.

13
Introduction
Nonetheless, the quantity of BTC that has been ported over to Ethe-
reum is a powerful signal of the value and network effects that BTC
possesses. BTC represents a several hundred-billion-dollar pool of
capital. To date, it has seen widespread adoption as a store of value
asset but yield generating strategies directly within its ecosystem
and security framework have been limited. The evolution of projects
like Sovryn will provide insight into how much value sidechains such
as RSK can deliver within the Bitcoin ecosystem. Whether or not RSK
and other sidechains can become a contender in the smart contract
landscape will likely be determined by the success of what is built on
top of them.

A Framework for
Comparison
II
Introduction to
Smart Contract
Platforms
15
Introduction to Smart Contract Platforms
Smart Contracts Defined
The basic idea of smart contracts,

according to their initial proposer,
Nick Szabo is that "many kinds Why work within the confines of the Bitcoin ecosys-
of contractual causes (such as tem at all when you can start from scratch? The most
collateral, bonding, delineation successful “start from scratch” blockchain to date
of property rights, etc.) can be has been Ethereum. In contrast to Bitcoin’s limited
embedded in the hardware and base layer programmability, Ethereum launched with
software we deal with, in such customizability and programmability as a first prin-
a way as to make a breach of con- ciple. It introduced smart contracts, which had been
tract expensive (if designered, proposed as early as the 1990s, and expanded the
sometimes prohibitively so) for reach of blockchain technology to an unbound num-
the breacher. ber of disciplines, not just payments.
What are smart contracts?

In today’s vernacular, smart contracts refer to computer programs
that are deployed and executed on blockchain networks. They are
being used to facilitate all kinds of functions from decentralized
asset exchange to decentralized lending to blockchain-based asset
issuance and tokenization. They were initially proposed by com-
puter scientist and cryptographer Nick Szabo in the 1990s. He called
vending machines a “primitive ancestor of smart contracts,” since
they take coins and dispense a product and the correct change
according to the displayed price.
Smart contracts execute under a predefined set of conditions and

once they are deployed to a blockchain, they cannot be “unde-
ployed”. Anyone with the technical expertise to code them can
deploy them. And theoretically, anyone with sufficient funds to cover
transaction fees can interact with them once they are deployed.
What are smart contracting platforms?

Smart contract platforms, unironically, provide a venue for deploy-
ing smart contracts and decentralized applications. They are owned,
operated, and secured by distributed bases of token holders and
computer hardware operators which makes them difficult to censor
and provides for their 24/7 operation. They serve as the base secu-
rity layer of this emerging “decentralized economy stack” presented
below. And everything that is built on top of them inherits their secu-
rity, performance, and censorship-resistance characteristics.

16
Defining the Layers of the Decentralized Economy Stack

Layer 1 Smart Contracting Platforms are the topic of this report.
They set the rules for how networks are secured and how they come
to agreement on the state of the blockchain(s). They span gener-
al-purpose blockchains such as Ethereum which provide a platform
for launching applications deployed as smart contracts to Polkadot
which resembles a “Layer 0” platform as it provides developers a
security framework for deploying their own Layer 1 blockchains.
Sidechains and Application-Specific Chains such as RSK, are block-

chains with distinct consensus processes and security profiles from
Layer 1s. Application-specific chains are one example of blockchains
that are deployed under the development framework of a Layer 1 platform
such as Cosmos, yet nonetheless have independent security models.
Scalability solutions are typically referred to as Layer 2 solutions. They

aim to enhance the performance of Layer 1 platforms by offloading
transaction execution onto separate chains. They leverage the security
frameworks of their underlying Layer 1s to varying degrees and when
they rely heavily on their own security frameworks rather than those of
their related Layer 1 platform, they qualify as sidechains.

17
Crypto Native Protocols and Token Issuing Companies are the “gas
guzzlers” that consume the computational resources of Layer 1 plat-
forms and scaling solutions. They allow users to tap into the decen-
tralized economy by building blockchain based products and services.
Crypto native protocols exist as smart contracts on blockchains and
are typically owned and governed by online blockchain communities.
Token issuers are one example of traditional companies that leverage
Layer 1 platforms for asset issuance among other use cases.
Blockchain-based assets are issued on top of Layer 1 platforms.

Native tokens are used to secure Layer 1 networks, pay transaction
fees on them, and in some cases grant holders a degree of say in
platform governance. Stablecoins and NFTs are two examples of the
many types of assets that are being issued on top of Layer 1s.
How do Layer 1 platforms provide security?

Layer 1 networks need to provide security in an environment where
anyone, with good or bad intentions, can participate in operating
the network. Sybil resistance mechanisms are how they achieve
this security. They create incentive structures that aim to pre-
vent one or few “malicious” entities from being able to temporarily
subvert or stall the network for their own gain to the detriment of
other network participants.
To date, there have been three major sybil resistance mechanisms

employed: Proof of Work (PoW), Proof of Stake (PoS), and to a lesser
extent, Proof of Authority (PoA). They all typically aim to achieve
security by:
i. Encouraging participants to come to consensus (agreement) on

the state of the blockchain through a competitive process
ii. Rewarding some or all participants for coming to agreement
iii. Punishing participants that make efforts to stall the network from
reaching agreement or for more directly trying to subvert it
The table below provides an overview of these different mechanisms

and how they are operationalized.

18
To date, the majority of activity in the greater blockchain ecosystem

has been secured by PoW blockchains such as Bitcoin and Ethereum.
In these networks, computational work must be performed to earn
rewards, and security is typically quantified by measuring how diffi-
cult it is to obtain 51% of the total computing power on the network.
Once one or few entities accumulate 51% of this computing power,
they are capable of censoring the network and intentionally exclud-
ing transactions or, in some cases, double spending coins.
The vast majority of smart contract platforms employ PoS or some

variation of it. In these networks, economic incentives surrounding
staking are employed to achieve security. Security is often quantified
by how difficult it is to obtain 33% of the aggregate financial stake
being used to secure the network. Once one or few entities accumu-
late 33% of the stake in a PoS network, they are capable of censor-
ing the network and can stall it from coming to agreement.
In summary, computational power defines network influence in PoW

and financial capital defines network influence in PoS. This diver-
gence has important implications for one of the most hotly debated
topics in the blockchain discourse: energy consumption.
Sybil resistance and sustainability

PoW is by far the most energy-intensive sybil resistance mechanism.
Performing more computational work in PoW networks translates to a
higher likelihood of gaining rewards from block subsidies and transac-
tion fees. So, it is not surprising that miners have competed to perform

19
more work to earn more rewards; especially as BTC and ETH’s prices
have risen over the past years and increased the value of these rewards.
How much electricity do Bitcoin and Ethereum actually consume?

The Cambridge Center for Alternative Finance estimated that Bitcoin
accounted for ~0.30% of global electrical energy consumption as of
the end of June 2021. As seen in the chart above, Bitcoin and Ethe-
reum’s estimated electricity consumption are both in the range of
small nation-states.
Nonetheless, the topic of energy consumption for PoW blockchains

has layers of nuance and complexity.
Energy sources, opportunity costs, and security

Electrical energy consumption and carbon footprint are not synony-
mous. Electricity is generated from several different energy sources
such as coal, natural gas, hydro, and solar power that all have dif-
ferent carbon footprints. Estimating the total carbon footprint of a
PoW network necessitates pinpointing the mix of energy sources
employed by the operators of these networks.

20
Additionally, the opportunity cost of using energy to secure PoW

networks is an important consideration. In some instances, PoW
mining is being used to monetize energy that would otherwise
be stranded and potentially never put to productive use. In other
instances, there is a case to be made that PoW mining is competing
with other “more legitimate” uses of energy and pushing up the cost
of energy across certain regions.
Blockchain security is also an important consideration. All else equal,

more electricity being dedicated to mining PoW chains makes them
harder to attack and increases their censorship resistance. PoW
chains with very low levels of electricity consumption have consis-
tently been exploited in attacks and are less secure environments for
deploying applications.
What is the outlook for energy consumption for PoW chains?

Ethereum’s energy consumption will be significantly reduced when
its network transitions to PoS, which is estimated to happen some-
time within the next 18 months.

21
"The mechanics of measuring the

environmental impact of a global
decentralized and widely used
blockchain are nuanced and com-
plex. That's why we are teaming How much energy Bitcoin and other PoW blockchains
up with ClimateTrade to continue will consume in the future will be impacted by several
and double-down on our eco-con- factors. The future price of their native assets, their
scious efforts...We find it crucial to issuance schedules, the efficiency of mining equip-
operate at a carbon-negative level" ment, where mining is concentrated geographically,
— and execution or lack thereof on initiatives to move to
Silvio Micali, Founder at Algorand more sustainable energy sources are all variables that
need to be considered.
Historically, higher prices of native assets, such as BTC and ETH,

have raised the breakeven cost for mining and, with a lag, resulted in
increased electricity consumption. But whether this relationship will
persist in the future is dependent on the intersection of the factors
mentioned above.
Is the electricity consumption worth it?

Whether or not Bitcoin and Ethereum, or any other PoW chains, are
worth their energy consumption depends on how the services pro-
vided by their networks are valued.
To those who think that PoW blockchains, and Bitcoin, in particu-

lar, provide critical financial access to individuals, it is a worthy con-
sideration for energy use. In that case, comparing the energy con-
sumption of these PoW chains to use cases that they are potentially
absorbing or providing superior alternatives to is the appropriate
analysis. The resources required to extract gold, run payments and
banking infrastructure, or more broadly, the costs suffered by indi-
viduals living under hyperinflationary monetary regimes could all
serve as appropriate measuring sticks.
To those who think PoW chains solely serve as arenas for excessive
speculation or are used extensively for money laundering, they do
not provide value and are a wasteful use of energy.
Finally, there are many who think PoW networks provide valuable
services yet view current levels of energy consumption as unaccept-
able. Some are taking initiatives to increase reliance on renewable

22
sources of energy for PoW mining. Others are employing less energy
intensive sybil resistance mechanisms such as PoS.
How much less electricity do PoS networks consume?

Given that participants in PoS networks compete on accumulat-
ing financial stake rather than performing computational work, they
consume far less electricity than their PoW counterparts. The Ethe-
reum Foundation estimates that Ethereum’s move from PoW to PoS
will result in a 99.8% reduction in its network’s electricity consump-
tion. This is a good starting point for quantifying just how much less
energy PoS networks consume.
Additionally, PoS networks such as Algorand are pushing the pace

of blockchain sustainability even further. Algorand has committed
to being carbon negative and is purchasing carbon offsets for the
energy consumption of its entire network. It will do so by employ-
ing a sustainability oracle that periodically notarizes the network’s
carbon footprint on-chain and purchases carbon credits, which are
tradable as blockchain-based assets, from partner ClimateTrade.

A Framework for
Comparison
III
The Current
State of
Ethereum
24
The Current State of Ethereum
Ethereum is the first major smart contracting platform. To date, it

has seen the highest level of adoption and usage. And while the
broader smart contracting platform landscape is rapidly evolving,
developments within the Ethereum ecosystem have repercussions for
the entire crypto market.
To say a lot is going on in the Ethereum ecosystem would be an under-

statement. Its network is routinely facilitating the transfer of tens of
billions of dollars of value daily. Over $50BN of value is currently sit-
ting in smart contracts on its network to facilitate decentralized asset
exchange, lending, insurance, and payments among other use cases.
And on the technical front, an array of solutions are being developed
to tackle the biggest challenge facing its community: scalability.
Ethereum’s Scalability Challenge

Ethereum’s scalability challenge is not a new phenomenon.
The advent of CryptoKitties NFTs and the activity surrounding them

gave us a glimpse of the scalability limitations of the platform as
early as 2017. But this time around, the explosion of DeFi activity is
driving a more pronounced and sustained increase in fees that has
brought these limitations center stage.

25
According to data from Coin Metrics, the average fee a user paid to
execute a transaction on Ethereum was around $0.08 at the start of
2020. It has been as high as $68.00 on certain days over the past
year. And depending on the type of transaction being executed,
many have cost in the hundreds of dollars. Wow.
For some users, high fees have gone from being an inconvenience to
an outright deterrent to transacting on the Ethereum platform. Many
have started exploring the greener pastures of other platforms that
offer similar applications with lower transaction fees, albeit with dif-
ferent and oftentimes inferior security profiles. On the development
side, applications have begun deploying their technologies on Ethe-
reum Layer 2 scaling solutions and sidechains to provide users lower
transaction fees while still leveraging Ethereum’s established decen-
tralization and security characteristics to varying degrees.
Ethereum’s Technical Roadmap

To overcome these scalability challenges and provide better user expe-
riences, while also not compromising on the network’s decentralization,
there are several development initiatives underway in the Ethereum
community. The visualization below by Trenton Van Epps captures the
concurrent and intertwined nature of the technical roadmap.

26
The roadmap can be broken down into two workstreams:
i. Scaling at Layer 2, which does not require any changes to the

underlying base Ethereum layer
ii. Scaling at Layer 1, which, at a minimum, involves changing the
network’s sybil resistance mechanism from PoW to PoS, and
changing its architecture from a single blockchain to a multi-chain
network, referred to as Ethereum 2.0
Phase 0 marked the preliminary launch of the Ethereum 2.0 network.

Ethereum 2.0’s architecture will consist of a beacon chain and 64
homogenous chains referred to as shards. The beacon chain will
manage organizing the network’s validator set into committees and
nominating block proposers for each of these respective commit-
tees. It will also serve as an anchor point on which the shards regis-
ter their states to facilitate cross-shard communication. The beacon
chain officially went live in December 2020 after the network reached
16,384 validators who had collectively staked 524,288 ETH.
Phase 1 will kick off the data sharding of the Ethereum network.
This is when the 64 homogenous shard chains will be formed. While
these shards will not perform transaction execution initially, they will

27
"The Ethereum ecosystem is like-

ly to be all-in on rollups (plus
some plasma and channels) as a
scaling strategy for the near and
mid-term future" increase the amount of data the Ethereum network
— is capable of storing and deliver performance gains
Vitalik Buterin, Ethereum in connection with Layer 2 scaling solutions. While
Co-Founder Phase 1 was originally slated to occur before “the
merge” which is described below, it has since been
postponed until after the merge.
Phase 1.5, also referred to as “the merge”, will mark the Ethereum
network’s official move from PoW to PoS. In this phase, the Ethe-
reum network in its current state will be ported over to Ethereum 2.0
as a shard. The merge is slated to happen over the coming 6 to 18
months according to estimates from the Ethereum Foundation.
Phase 2.0 would mark the final phase of the Ethereum network
upgrade and take transaction execution into the shards of the Ethe-
reum 2.0 network. It is still uncertain whether phase 2.0 will happen
or if the future will be “roll-up-centric”. If the future is indeed roll-up-
centric, the Ethereum 2.0 network will solely be used for security and
data availability rather than transaction execution.
The scaling solutions patchwork

Irrespective of the changes to the Ethereum 2.0 data structure,
a patchwork of different scaling solutions are being employed to
enhance the performance of the Ethereum network in its current, sin-
gle chain state. They all aim to offload transaction execution from the
main Ethereum blockchain and increase scalability, but they do so in
a diverse range of ways. Notably, these scaling solutions are not spe-
cific to Ethereum and could be adopted across other networks.
Key considerations for analyzing these scaling solutions include:

(i) to what degree they inherit the security and network effects of
their underlying Layer 1 and (ii) whether they impose additional
requirements on users that are more stringent than what is expected
on the base layer. The graphic below outlines four of the more
popular approaches.

28
Rollups
Rollups are solutions that perform transaction execution outside
Layer 1 but make transaction data available on Layer 1.
In optimistic rollups, batches of transaction data are posted to the

main chain and presumed to be valid (optimistic) but can be chal-
lenged. Theoretically, anyone can challenge them by submitting a
claim, also known as fraud proof, to prove that a batch committed
to the chain contained invalid state transitions. If the fraud proof is
valid, these invalid state transitions would be rolled back. Addition-
ally, the proof publisher would be entitled to collateral (bonds) posted
by the sequencers who batch the data. Thus, there is an economic
incentive for users to monitor the validity of this transaction data.
Batches posted to the main chain can be disputed for several days
(typically 1 week) during which funds on these Layer 2s cannot be
withdrawn back to the main chain which could create a challenge
from a usability perspective. However, several projects are work-
ing on providing liquidity to Layer 2 users to bridge this withdrawal
period. Importantly, existing smart contract languages are supported
in optimistic rollups, which allows for existing applications to easily
be ported over to these solutions.

29
Zero-knowledge rollups are similar to optimistic rollups in that

they post all transaction data onto the main chain. However, they
use zero-knowledge succinct non-interactive arguments of knowl-
edge (zk-SNARKs) to validate transactions. Once these validation
proofs are completed and posted to the main chain, all the transac-
tions included in them are considered final. The computational power
required to generate these proofs by the Layer 2 nodes is higher
than optimistic rollups as they are cryptographically intensive. Imple-
mentations with Ethereum compatible smart contract support are
a subject of active research and development but some have made
significant steps towards Ethereum compatibility.
Validium and Plasma

Validium works very similar to ZK rollups except data is stored off-
chain. Since transaction data is not published on-chain, this intro-
duces new trust assumptions as users must trust an operator to
make data available when it is needed. This is typically achieved
through a committee of known entities who stake their business rep-
utation on being reliable data providers. If an L2 node operator stops
servicing withdrawal requests, this committee will make its copy of
the data publicly available.
Plasma users, on the other hand, do not have to trust operators and
always have the option to retrieve their funds, even in cases where
operators are malicious or uncooperative. While Plasma generated
much excitement in the Ethereum community upon its introduction,
it introduced several complications. The combination of new data
availability attack vectors, the need for users to monitor transactions
to detect malicious behavior, and concerns around data capacity on
the main chain should many users try to exit plasma chains simulta-
neously has stifled deployment of Plasma solutions.
What does this patchwork mean for Ethereum?

Over the near to medium term, rollups are expected to be the most
popular scaling solution. Many of them are just being implemented
today for the first time. Given how far away the advent of a full-
fledged Ethereum 2.0 is, they are likely here to stay.

30
Optimistic rollups, given that they effectively allow developers to

“copy and paste” their Ethereum applications onto a Layer 2 have
seen the most attention and adoption thus far. Some of the lead-
ing applications on the Ethereum mainnet such as Uniswap and Syn-
thetix have already started deploying their applications on Optimis-
tic rollup solutions. Likewise, ZK rollups and Validium solutions, while
they have limited support for general-purpose smart contracting to
date, are also actively being deployed.
What will happen to composability, one of the biggest drivers behind

Ethereum’s network effect and growth, remains to be seen. Com-
posability allows anyone in a network to easily build on top of and
around existing products and services to devise new use cases;
use cases that many did not know were possible until they were
invented. Not only has this fueled innovation and growth on the
Ethereum network, but it has allowed users a high degree of freedom
in being able to affect relatively complex transactions under one
security framework, on one chain, and with relative ease.
Layer 2 solutions, while they will undoubtedly enhance user experi-

ence through lower fees, come with the possibility of separate exe-
cution environments. And in a scenario where several competing
solutions are adopted, this composability that has been so central to
the Ethereum network could become fragmented.
To date, there has been a high level of indecisiveness on the deploy-

ment side as application developers wait and see which Layer 2
solutions gain adoption before deciding which platform to deploy
on. Whether or not there will be convergence amongst one or a few
Layer 2s will be an important development going forward. It has
implications for not just the network effects of the larger Ethereum
ecosystem, but the broader smart contract platform landscape.

A Framework for
Comparison
IV
Framework for
Layer One
Platform
Comparison
32
Framework for Layer One Platform Comparison
While Ethereum is the largest Layer 1 platform, dozens of platforms

have emerged over the past years. Some are rapidly innovating and
bringing new consensus algorithms, blockchain architectures, and
execution environments. Others have brought very little innovation
and would pass as “zombie” chains that have had very little active
development for the past few years. Below are the top 30 of these
platforms sorted by market capitalization.
Nearly 6 years after the inception of Ethereum, comparing and ana-

lyzing these different platforms remains challenging.
The technical jargon surrounding them causes headaches. Most

analysis on them is written by individuals and entities that, while
extremely knowledgeable and informed, have vested interests in
the success of one platform or the other. This makes digestible and
objective comparisons between platforms few and far between. In

33
this section, we aim to cut through some of

that noise by stacking up several platforms
side by side.
The platforms we compare are Algorand, Ava-

lanche, Binance Smart Chain (BSC), Cosmos,
Ethereum/Ethereum 2.0, Polkadot, and Solana.
The categories we compare them across are
technical design, on-chain and ecosystem
data, native token design, and key ecosystem
members and fundraising histories. Collectively,
this gives us a “look under the hood” at how these platforms differ.
Our selection of individual platforms is qualitative. It comprises a

range of platforms with differing levels of ecosystem growth and
maturity, different approaches to scaling, and different approaches
towards decentralization. The combination of these factors makes
them a useful sample set for drawing conclusions about the broader
smart contract platform landscape. Inclusion or exclusion of platforms
from our sample set does not constitute support or disapproval.
Technical Design & Performance

There are many ways to construct a decentralized network.
Getting a large, distributed base of computers to agree on many

transactions quickly and with a high level of security is no small feat.
Add in the fact that theoretically anyone, including actors inten-
tionally trying to subvert the network, can participate and it makes
sense why there are so many platforms taking so many different
approaches.
Decentralization
Decentralization is the core technical design feature that sets block-
chain technology apart from its centralized counterparts. It is a key
consideration for any network that refers to itself as a blockchain.
But assessing whether a blockchain network is decentralized or not
ultimately depends on how the assessor defines decentralization.

34
While there is no universal definition for decentralization, it can be

thought of as a spectrum. Pinpointing where on this spectrum differ-
ent projects lie is best achieved by analyzing one of the core stake-
holders in decentralized networks: nodes.
What are nodes?

Nodes are the “boots on the ground” of blockchain networks. They
are the physical computer hardware that runs their respective plat-
form’s blockchain software.
They serve several critical functions:

i. They vote on and validate blocks of transactions
ii. They communicate with other nodes to agree on the state of the
blockchain
iii. They store the history (state) of the blockchain as a universal
source of truth
iv. They are the endpoints of the network that enable users to
access and interact with applications built on the network.
Different classes of them perform different functions, but a few dis-

tinctions are common:
i. Validator nodes participate in consensus to finalize transactions
and agree on the state of the blockchain
ii. Archival nodes typically store the entire state of the blockchain
iii. Light nodes only store a small portion of the state of the blockchain
The categories are not mutually exclusive. Some validator nodes are
light nodes while others are archival nodes. For the sake of analyzing
decentralization, the number and distribution of validator nodes that
participate directly in consensus provides useful context.
Decentralization as a spectrum
Given that there is no universal definition for decentralization, the
spectrum is best described at the extremes.
At one end is “decentralized bliss”:

• There are millions or billions of independent nodes geographically
dispersed across the globe

35
• The hardware needed to run a node is accessible and produced

by many different independent manufacturers
• None of the individuals running the nodes have any intention to
form cartels or collude in any way
• The financial stake (native tokens) used to secure the network is
widely distributed
At the other end is “centralized dystopia”:

• There are one or few nodes geographically concentrated in one
datacenter
• The hardware needed to run a node is difficult to source and only
produced by one manufacturer
• The individual(s) running the nodes should be expected to collude
into a few small groups that, if combined, can easily constitute a
large enough share of the network to subvert it for their own benefit
• The financial stake (native tokens) used to secure the network is
narrowly held
Decentralization as a journey
Building out a distributed base of validator nodes

does not happen overnight. And the goalpost for
what constitutes decentralization will continue to
move.
But striving to achieve decentralization should

be a persistent and mission-critical goal for
communities building blockchain infrastructure.
It is how security and censorship resistance are
achieved and it has far-reaching consequences
for entire ecosystems.
How can decentralization be assessed?

Decentralization can be assessed by trying to answer two questions:
i. What are the requirements to run a validator node?
ii. How distributed is the current validator set?

36
Answering the first question gives us a sense of the flavor of decen-

tralization that the platform is capable of delivering. Answering the
second question provides insight into how these requirements are
being reflected in market data.
The requirements to run a node can be broken down into:

i. The computational requirements to run a validator node
ii. The minimum financial stake required to enter the validator set.
While PoS networks are substantially less com-

putationally intensive than their PoW counter-
parts, they nonetheless require upfront and
ongoing spend on computer infrastructure to
run blockchain software. Depending on how
networks are structured, requirements can
vary substantially. They span inexpensive con-
sumer-grade hardware such as Raspberry Pis
and laptops that cost around $100 to $1,000
to industrial-grade hardware setups that cost
thousands of dollars and require substantial
recurring maintenance spend. The table nearby outlines the required
specifications for the platforms in our sample set.
All else equal, lower hardware requirements lower the barrier to

entry for directly participating in consensus and are conducive to
building out larger and more distributed validator sets.
"Do we need to optimize so Nonetheless, hardware is also an

that every chain can run on important consideration for plat-
a Raspberry Pi? My answer form performance. For example, on
is: no." a single chain with the same num-
— ber of validators, identical sybil
Anatoly Yakovenko, CEO
resistance mechanisms, identical
at Solana
consensus processes, and identi-
cal execution engines, a network with more performant hardware will
be able to process more transactions in a set amount of time. Hence,
while the computational requirements to run a node are a consid-

37
eration for decentralization, they are one of several variables that

impact platform performance.
In addition to procuring hardware to run blockchain software, val-

idators in PoS networks are typically required to “lock-up” a min-
imum amount of financial stake to enter the validator set. As dis-
played in the table below, requirements vary substantially on a
network-to-network basis.
In instances where there is no cap on the total number of validators,

platforms define the minimum level of stake necessary to become a
validator. In other cases, where the platform places a limit on how
many validators are accepted into the active set, the minimum stake
required to become a validator is dictated by the market and approx-
imated as the stake of the active validator with the least stake.
In addition to these financial requirements, there are other important

considerations for joining the validator set. The risk of having stake
forfeited (slashed) and how long validators and delegators typi-
cally need to have their tokens staked before they can remove them
(unbond) are two of the major considerations.
Slashing
Slashing is a mechanism built into most PoS networks designed to
explicitly discourage validator misbehavior and incentivize secu-
rity, availability, and network participation. The two main misbehav-

38
iors that incur slashing are downtime (if your validator goes offline)
and double signing (submitting conflicting votes on blocks). Penal-
ties for these actions vary on a platform-by-platform basis, but they
can result in temporary or permanent removal from the validator set
and forfeiting some or all the stake that was “locked up”. Penalties
for double signing are typically much larger than downtime penalties.
Algorand and Avalanche do not have slashing built into their net-
works and thus rely on the implicit byzantine fault-tolerant proper-
ties of their networks to discourage these behaviors.
"Without decentralization, Overall, the combination of these

we remain in the financial hardware requirements, minimum
system that already exists stake requirements, and parameters
today: exclusive and secre- on slashing and unbonding paint a
tive." picture of how easy it is to partici-
— pate in consensus. Of the platforms
Silvio Micali, Founder at analyzed, Algorand has some of the
Algorand
lowest hardware and stake require-
ments, does not impose slashing, and has no unbonding period, thus
making it the easiest to participate in consensus. On the other hand,
Binance Smart Chain has relatively high hardware requirements, the
highest minimum stake requirements, and its network currently caps
its validator set at 21. The combination of these factors makes its
network the most restrictive in terms of participating in consensus.
Assessing Decentralization
The requirements to run a validator provide insight into what the
composition of the validator set could look like. The actual num-
ber and the distribution of stake amongst these validator nodes pro-
vide quantitative estimates of their current levels of decentralization.
The table below provides an overview of some of the most important
metrics for analyzing the state of these networks.

39
Comparing the aggregate financial stake being used to secure these

networks is a valuable starting point for assessing network secu-
rity. Abstracting away the complexities that the actual distribution
of stake introduces, networks that have more financial stake secur-
ing them have higher attack difficulty as an attacker would need to
expend more financial resources to accumulate the required stake to
censor the network.
Comparing the number of validators that a network currently has is the

most simplistic method for assessing decentralization. While they may
not always map to one distinct entity, they are proxies for the number
of independent decision-makers in the ecosystem. Having more inde-
pendent validators is conducive to a higher level of decentralization.
Analyzing the distribution of validators and their respective finan-

cial stake provides a second degree of insight into a network’s level
of decentralization. The Herfindahl score (the sum of the squares of
each validator's stake for each respective network) approximates the
distribution of the network’s validator set. The lower the score, the
more distributed the validator set is.
Quantifying Decentralization
In PoS, 33% is the most important number for assessing blockchain
security and liveness. PoS networks reach agreement and transac-
tions are finalized when 2/3 or 66% of the aggregate financial stake
in the network agree that a block or a series of blocks are final. So,

40
anyone that can accumulate 33% of the total value staked on the
network can censor it and prevent it from finalizing transactions and
coming to agreement. Depending on the consensus algorithm of the
individual network, this could result in the network stopping (i.e.
ceasing to produce blocks until it gets 66% agreement on the block)
or continuing to produce blocks, but not reaching final agreement on
the content of the blocks.
In the table below, we calculate the minimum number of validators that

account for 33% of the aggregate value staked on the network. This is
one way of quantifying how difficult the network would be to attack.
Considerations for quantifying decentralization

While the analysis above contains some adjustments to most closely
approximate the distribution of “unique controlling entities” within
each validator set, pinpointing who actually runs these validators,
and what their relation to one another is challenging. Additionally,

41
the degree to which these validators source their stake through del-
egation adds another degree of complexity to the equation. Even if
stake is distributed across a wide base of validators, one or few enti-
ties could potentially be delegating the majority of this stake, thus
making validator shares of stake a less reliable metric.
Additionally, the data presented above is as of a certain point in time

and collected over several weeks. Tracking it over time within and
across networks would provide the best insight into the evolution of
decentralization for these networks.
Nonetheless, the analysis above does provide some insights for the
outlook for the decentralization of these platforms. For example, the
stake securing Binance Smart Chain’s network is fairly evenly dis-
tributed across all 21 of its validators, but only 7 validators account
for over 33% of the active stake of the network. Barring any changes
to Binance Smart Chain’s platform that would increase the size of its
active validator set, the prospects for higher levels of decentralization
on its platform are limited.This stands in contrast to other platforms
analyzed that support larger and in many cases uncapped validator
sets, which will allow them to achieve higher levels of decentralization
as more validators enter the set and stake becomes more distributed.
Network Architecture
While decentralization is an important factor, it does not exist in iso-
lation. Performance and usability are also important considerations
for these networks. How networks are structured helps shed light on
the intertwined nature of all of these attributes.
Structure is most easily assessed by examining how security is pro-

visioned and where transaction execution takes place. In the table
below, we identify three distinct network structures: (i) networks
with one validator set and one blockchain, (ii) networks with one val-
idator set and multiple blockchains, and (iii) networks with multi-
ple validator sets and multiple blockchains. Additionally, we highlight
some of the most apparent tradeoffs associated with each of them.

42
One Validator Set, One Chain

Employing one validator set and one blockchain is the most battle-
tested architecture. Algorand, Binance Smart Chain, Ethereum, and
Solana are all currently employing this strategy. Abstracting from
layer 2 scaling solutions, all transactions in these networks are executed
on one chain under one security framework. This is conducive to gener-
ating network effects within their ecosystems as all applications on the
chain can easily interact with other applications on a synchronous basis.

43
One Validator Set, Multiple Chains

Ethereum 2.0, and Polkadot are examples of platforms employing one
shared validator set that validates multiple chains within a “walled
garden” ecosystem.
In the case of Ethereum 2.0, its metadata chain is the beacon chain
and other chains represent its 64 homogenous shard chains. More
detail on the structure of the Ethereum network can be found in sec-
tion 3 of this report.
"Substrate's actual reason is In the case of Polkadot, its metadata chain is the relay
to be the antithesis of blockchain and ~100 heterogeneous parachains are slated to be
chain maximalism... the used for transaction execution. In contrast to Ethereum 2.0
whole point of Substrate is where applications are deployed using smart contracts,
to make making new chains Parity Technologies' Substrate framework is designed to
really, really easy." allow developers to deploy application-specific block-
— chains or other Layer 1 platforms referred to as parachains.
Gavin Wood, Founder at
While these parachains rely on the security and finality
Parity Technologies
guarantees of the global Polkadot validator set, they have
their own native tokens and are optimizing for certain use cases.
Parachain slots are secured through competitive auction processes
whereby candidates are required to bond a certain amount of DOT
tokens to effectively rent their parachain slots.
Multiple Validator Sets, Multiple Chains

Cosmos and Avalanche are examples of platforms that can support
multiple validator sets and multiple chains. Both networks provide
frameworks that allow for blockchains to be created and intercon-
nected. They also allow developers the highest level of customizabil-
ity for designing their own chains with their own security models.
To date, the majority of the activity with the Avalanche ecosystem has
occurred within its the Primary Network which spans one validator
set that currently validates three separate blockchains: (i) a platform
chain that coordinates validators, keeps track of active subnets, and
allows for the creation of new subnets, (ii) an exchange chain which is
a decentralized acyclical graph (DAG) that enables the creation of new

44
assets, exchange of assets and cross-subnet transfer, and (iii) a con-

tracts chain which is an Ethereum compatible linear blockchain.
To date, the Cosmos Network has seen the most activity within
Zones, or chains that were launched using Cosmos SDK, but maintain
their own validator sets and native tokens. Dozens of chains securing
billions of dollars in value have been deployed using Cosmos SDK
technology including Binance Chain (not to be confused with Binance
Smart Chain), Terra, and Thorchain. While they retain their own vali-
dator sets, there is a possibility that Cosmos Hub validators will serve
as validators of other Zones should governance processes dictate.
Cross-chain communication both within and across multi-chain eco-

systems will become an increasingly important consideration that we
discuss in the final section of this report.
Sybil resistance and consensus

Sybil resistance and consensus mechanisms lie at the heart of all
blockchain networks. They determine how networks are secured and
how they reach agreement on the state of the blockchain.
Sybil Resistance
With the exception of Ethereum, all of the platforms in our sample
set employ some variation of PoS whereby security is achieved by
having distributed bases of token holders stake their native tokens.
Nonetheless, they have subtle differences.

45
Particularly, in the case of networks with capped validator sets, they

have different parameters around how validators are elected into the
active set. Through delegation, token holders who are not operating com-
puter hardware can participate in consensus by assigning their tokens
to active validator nodes. Delegation processes span those where dele-
gation is facilitated at the protocol level and facilitated through on-chain
processes to others where delegation is conducted off-chain through
third party staking pools and staking as a service providers.
Consensus
Blockchain networks are inherently redundant. The truth, or the state
of their ledgers, is maintained locally on individual nodes. The global
network truth is formed through internode communication which is
operationalized by consensus algorithms. While the ins and outs of
each algorithm are highly technical, there are several distinctions
that help differentiate them.
Probabilistic vs Deterministic Finality

Finality defines how long users typically have to wait until there’s a
reasonable guarantee their executed transactions cannot be “rolled
back”. Consensus protocols provide two main types of finality: prob-
abilistic and deterministic.
In probabilistic finality arrangements like Ethereum’s Nakamoto con-

sensus, once a block is propagated, several additional blocks need
to be built on top of it such that the probability of a longer chain
forming, which would invalidate said block, is sufficiently low. Partic-
ipants in these networks typically agree to a “rule of thumb” number
of blocks that need to pass before transactions are considered final.
Importantly, networks with probabilistic finality can reach consensus
without full knowledge of the total active set of miners/validators.
In deterministic finality arrangements, there is a notion of validator

identity. While networks have different fault-tolerance thresholds,
finality is typically irrevocably achieved when 2/3 of the active vali-
dator set attest to the validity of a block(s).

46
Favoring safety over liveness

Algorand and Cosmos achieve finality in lock-step with block pro-
duction and favor safety over liveness. If these networks are not
capable of reaching consensus, they cease producing new blocks
until ⅔ of the network reaches agreement on the latest block. In
Avalanche consensus, transactions are grouped into vertices. If a
vertex includes conflicting transactions, all transactions in it are
rejected and re-issued for execution. Thus, when transactions on
any of these safety favoring networks are executed, they are consid-
ered final.
Favoring liveness over safety

In contrast to platforms that favor safety, platforms favoring live-
ness decouple block propagation from finality. These chains execute
transactions optimistically and finalize them after they have been
sufficiently and provably audited.
For example, in Ethereum 2.0, leaders propagate shard blocks within

their respective committees that are periodically linked back to the
beacon chain and finalized by beacon chain committees. In Pol-
kadot, the network’s Blind Assignment for Blockchain Extension (
BABE) coordinates block propagation and leader selection. Through
Polkadot’s GHOST-based Recursive Ancestor Deriving Prefix Agree-
ment (GRANDPA) finality gadget, validators reach agreement on the
state of chains rather than individual blocks. Solana’s Proof of His-
tory (PoH) works as a “clock before consensus” in that each validator
runs a sequential hashing function that generates a data structure to
provide guarantees on time and order of events. Leaders in Solana
rotate based on a predetermined schedule and the blocks they prop-
agate are finalized by the network’s Tower BFT consensus algorithm.
If these liveness favoring networks are not capable of coming to

agreement on a block, they will continue to propagate new blocks
and execute transactions but will not achieve finality.
Chain reorgs
Reorganizations or roll-backs of previously executed transactions
are not feasible for networks that favor safety. Any violation of sin-

47
gle block finality would require that more than ⅓ of the validator set
be slashed (if the network supports slashing). Accordingly, only in
rare instances, (i.e. If an attacker caused two conflicting blocks to
be finalized by controlling 67% of the stake), would these chains be
reorganized through social intervention.
On the other hand, networks favoring liveness make progress when

the network is unstable and tolerate partitions in their networks that
could cause reorgs before finality is reached. Nonetheless, these
networks employ checkpointing schemes whereby transactions that
occurred before a certain point in time (i.e. such as ~12 minutes or
two epochs prior in Ethereum 2.0) cannot be reorged.
For PoW networks, small reorgs are a frequent occurrence as multi-

ple proposers can and do broadcast blocks at the same height that
can result in temporary partitions of these networks.
In addition to the previously mentioned factors, consensus algo-

rithms share several commonalities that are worth exploring.
Random sampling or partitioning of the validator set

In Algorand’s Pure Proof of Stake consensus, a committee and a
leader are randomly selected from the global validator set via a ver-
ifiably random function (VRF), and consensus is achieved within
these committees that are rotated each block. In Avalanche’s Ava-
lanche consensus for its directed acyclic graphs (“DAG”), nodes
repeatedly perform their own random samples of the network and
periodically update their states until the majority of the network is in
agreement. In Ethereum 2.0, validators will be randomly sorted into
committees that reach consensus within their respective shards.
In all these scenarios, consensus is periodically reached within sub-

sets of the global node base which nonetheless inherit the decen-
tralization characteristics of the broader set, provided that it is suffi-
ciently large. This results in lower communication overhead between
nodes and thus speeds up consensus.

48
Capping the size of the validator set

Binance Smart Chain, Cosmos, and Polkadot all currently cap their
validator sets at 21, 125, and ~300, respectively. In contrast to other
networks that employ sampling strategies, these networks reduce
communication overhead by design. Cosmos’s Tendermint consensus
was designed as early as 2014 and has become one of the most pop-
ular consensus algorithms employed across several leading chains.
Assessing platform performance

While consensus algorithms are a critical component of how net-
works operate, they also impact one of their most important attri-
butes: performance. Performance is best measured through two
metrics: throughput levels and finality.
Throughput defines how many transactions a network can handle in

a set amount of time and is typically measured in transactions per
second (TPS). Finality defines how long a user typically needs to
wait until there is a reasonable assurance that their transactions will
not be rolled back.
Mainnet Results
How many transactions per second a network has processed on its
mainnet provides the highest degree of certainty of its capabilities.
Ethereum and Binance Smart Chain have achieved ~20 TPS and ~220
TPS in a live production environment, respectively. Algorand has

49
achieved ~1,100+ TPS in a production environment, although these

transactions represent asset transfers which are less computationally
intensive than smart contract transactions. Accordingly, this through-
put level is likely overstated on an apples-to-apples basis compared to
Binance Smart Chain and Ethereum mainnet results.
While these throughput levels have been achieved to date, there is

a potential for much higher throughput on these platforms. With
rollups, Ethereum community members have estimated that ~4,800
TPS is achievable on the network in its current state. Likewise,
developer estimates of maximum throughput, with certain techni-
cal changes, are estimated at ~46,000 for Algorand and ~1,000 for
Binance Smart Chain.
Testnet Results
Testnet throughput levels provide a moderate degree of certainty into
how many transactions a network is capable of processing in a pro-
duction environment. They are performed in controlled environments
that abstract away many of the complexities and risks associated
with public blockchains and thus likely overstate performance com-
pared to live mainnet results. Nonetheless, they are a useful metric.
Avalanche has achieved upwards of 4,500 TPS in a testnet environ-

ment with 2,000 nodes. Avalanche’s Primary Network is currently
composed of three separate chains with distinct consensus algo-
rithms which achieve different throughput levels. Accordingly, these
estimates of 4,500 TPS likely refer to its lightweight X-Chain which
is structured as a Directed Acyclic Graph (DAG) and facilitates asset
creation and exchange. Throughput levels achievable on its Ethe-
reum compatible C-Chain, which facilitates smart contracting trans-
actions, are likely materially lower than these testnet levels.
Cosmos Hub employs Tendermint consensus. In testnet simulations

with 64 nodes, Tendermint has regularly processed around 4,000
TPS. Cosmos Hub’s validator set is currently comprised of 125 nodes.
Hence, communication overhead in a production environment is
likely higher and testnet levels could be slightly overstated.

50
Solana has achieved approximately 50,000 TPS in a testnet envi-

ronment. However, its execution engine does not delineate between
messages such as votes cast in consensus (which nonetheless
require payment of transaction fees) and more typical peer-to-peer
value transfers and smart contract transactions. Hence, testnet lev-
els are likely overstated compared to other platforms due to how
transactions are defined. Additionally, this throughput was achieved
with about 200 nodes which is about 1/3 of the nodes currently on
its mainnet, and communication overhead in a production environ-
ment is likely higher.
Developer estimates
Developer estimates provide the lowest level of certainty of a plat-
form’s capabilities in production. Nonetheless, given that the multi-
chain, shared security structures employed by Ethereum 2.0 and
Polkadot have never been employed in production environments
before, they are the best estimates we have.
Ethereum Foundation researchers estimate that the move to Ethe-

reum 2.0 (with transaction execution in shards) would result in
100,000 TPS. Likewise, Polkadot community members have esti-
mated the platform’s throughput in the range from 100,000 to as
high as 1 million transactions per second.
Considerations for assessing throughput and finality

As many networks have not achieved their theoretical TPS limits in
live production environments, it is difficult to pinpoint what their
maximum levels are. Even for networks that have reached these
maximum levels, the technical changes they are making have import-
ant implications for throughput levels in the future.
Additionally, the definition of what constitutes a transaction can

vary widely across networks and creates challenges for comparison.
Some transactions represent computationally intensive smart con-
tracting interactions. Others represent simple value transfer trans-
actions. And some represent votes or messages that are recorded in
conjunction with the network’s consensus process.

51
Layer 2 solutions will add another layer of complexity to assess-

ing throughput and finality for Layer 1 platforms. Depending on how
transactions are executed on these Layer 2 solutions and finalized
on Layer 1 platforms, there could be material impacts on throughput
and finality times that are not reflected in the data above.
4.2 On-Chain and Ecosystem Data

Irrespective of their theoretical capabilities, on-chain data provides
a look at what blockchain networks have actually achieved in live
environments. How this data is evolving both within and across ecosys-
tems can provide valuable insight into the state of these networks.
In this section, we present five series of blockchain data for the net-
works in our sample set. The data series we present are (i) daily
transaction counts, (ii) daily transacted value, (iii) average fees per
transaction, (iv) daily aggregate fees, and (v) total value locked in
decentralized finance (if applicable).
Differences in how on-chain data is tracked and defined across net-

works create challenges for apples-to-apples comparison. Accord-
ingly, we highlight these instances in the footnotes of the figures.

52
Daily transactions represent the number of transactions processed

by each chain on any given day. Depending on how transactions are
defined across networks, these metrics can vary substantially and
range from the tens of millions of transactions to the thousands.
Daily Transacted Value is the total value that was moved in the plat-
form’s native token on a daily basis. It does not include payment vol-
umes of assets issued on top of these platforms such as stablecoins.
On any given day, tens of billions of dollars of value are transacted
on the Ethereum network while other networks are routinely trans-
ferring tens of millions to billions of value on any given day.
Fees Per Transaction represent how much it costs, on average, to

effect a transaction on each of these respective networks. Fees paid
on an individual transaction will differ substantially depending on the
computational resources (“gas”) consumed by the individual trans-
action. Average fees on Ethereum have risen as high as $68 over the
past year while other chains such as Algorand and Solana are regu-
larly seeing fees as low as one-tenth to one-hundredth of a penny.

53
Daily Aggregate Transaction Fees is the total amount of fees paid

to effect transactions on the network in a given day. Ethereum and
Binance Smart Chain have generated millions of fees on a given day
while most other platforms are generating in the hundreds and thou-
sands of dollars.

54
Value Locked in DeFi represents the amount of funds locked in

a platform’s smart contracts to facilitate DeFi functions such as
exchange and lending. The amount of value locked varies substan-
tially based on the capital intensity and efficiency of each of the
functions that it is being used to facilitate. Nonetheless, it provides
useful insight into the relative size of the DeFi ecosystems across
these platforms.
Ecosystem Data
In addition to on-chain data, trends in community data are useful for
estimating the relative size and growth of platform ecosystems. In
this section, we provide data on social media followings and estima-
tions of development community size.
Social media followings approximate community size and growth

over time. They also provide a quantitative estimation of the reach
platform organizations have to promote ecosystem growth initiatives,
disseminate educational materials, and make announcements across
their respective ecosystems.

55

56
Development Community
Developer time is a relatively expensive resource. If platforms have
high levels of developer engagement it is a positive sign that the
community is confident in the prospects of the project and could
be an indicator that the project will be shipping more features or
improvements. Blockchain development activity is heavily skewed
towards Ethereum today, partly due to the platform’s longevity. But
development communities outside of Ethereum are already substan-
tial as evidenced by the Github and Discord data below.
GitHub is a code hosting platform for version control and collabora-

tion. “Starred” repositories represent workstreams that users have
followed in the past and are one simplistic method for gauging rela-
tive levels of developer engagement. Discord is an online chat room
primarily used by platform engineers and community participants to
discuss core platform technology, coordinate validator and user sup-
port, and make announcements.

57
Native Token Overview

Disclaimer: The content in this section does not constitute invest-
ment advice. Anyone considering investing should perform their own
diligence or consult a financial advisor.
Native tokens sit at the center of all POS networks. They are typi-
cally the only tokens eligible for staking and paying transaction fees.
And in most cases, they grant holders varying degrees of influence
in governance decisions of their respective platforms. The table
below provides an overview of these native tokens and what they are
used for across platforms.
Defining Native Token Basics
Token supply
Some native tokens have a capped supply whereby no new tokens
will be issued after a certain point. For these networks, development
organizations typically post detailed schedules outlining when they
will be emitted into circulation and for what use. Other platforms do
not put a formal limit on their native token’s supply and hence there
is no formal limit on how many tokens could eventually be issued.
Not placing a cap on total supply gives these communities the flex-
ibility to modify token inflation and staking payouts over the longer
term. Nonetheless, tokens with uncapped supply come with weaker
assurances over the scarcity of the native token as holders have no
guarantee on what percentage of total tokens their current holdings
could account for in the future.

58
Staking
Staking payouts compensate holders for using their tokens to par-
ticipate in securing the network. Networks are bootstrapping their
security models by issuing new tokens or transferring those that
are currently in circulation to stakers in return for “locking up” their
tokens. Actual all-in returns from staking vary substantially from
nominal payout rates as native token prices fluctuate and variable
token inflation rates reduce or in many cases eliminate real returns.
Due to this inflation, nominal staking payouts also represent an
implicit tax on token holders who do not stake their tokens and suf-
fer dilution of their stake.
Governance
The debate surrounding on-chain governance has been raging for
several years. Different platforms have different approaches to gov-
ernance that range from informal coordination on online forums and
chat rooms to formal voting processes conducted on-chain. Changes
to core technical design features, token inflation rates and eco-
nomics, and how treasury funds are allocated are all examples of
decisions that, to varying degrees, are starting to be coordinated
through on-chain governance processes.
Transaction fees
Native tokens are generally the only form of payment accepted to
cover fees on their respective networks. Exceptions to this rule in
our sample set include ATOM and DOT. ATOM can be used to cover
Cosmos Hub transaction fees, but several different tokens can also
be used to pay fees on the Hub. Additionally, while DOT is required
to be bonded to rent parachain slots, Polkadot’s parachains will likely
issue their own native tokens that are used to pay transaction fees.
How are transaction fees treated?

Transaction fees have several destinations depending on the plat-
form but are typically paid to validators, burned, or recycled. Most
networks employ a strategy whereby a portion of fees are remitted
to validators and a portion of the fees are either burned or recycled.
The table below provides an overview of how these networks cur-
rently treat fees.

59
Ethereum’s EIP 1559: Socializing transaction fee rewards

ETH’s token structure was recently overhauled with the introduc-
tion of Ethereum Improvement Proposal 1559 (EIP-1559) in August
2021. Among other changes (such as making the network's gas limit
more dynamic), the proposal changed the network’s fee model such that
a portion of the total fees paid by users are burned and permanently
removed from circulation rather than paid to miners, or in the case of
Ethereum 2.0, validators.
This change is particularly interesting in the case of Ethereum due

to the large quantities of transaction fees that it has been generat-
ing. Monthly aggregate transaction fees on the network recently sur-
passed $1 billion for the first time last May.
Under EIP 1559, fees are bifurcated

into a base fee and a miner tip. The
base fee portion represents the
floor for transaction fees and will be
burned and permanently removed
from supply while the tip will con-
tinue to be paid out to miners or vali-
dators. Leveraging historical fee data
and applying assumptions to what
the split of the base fee and the tip
are, we can estimate historical hypo-
thetical token burns that would have
occurred had EIP-1559 already been activated. The table below
shows these hypothetical burns over the past 4 quarters.

60
Based on these hypothetical burns, the impact of this proposal

could be material. In the quarters analyzed, token burns offset quar-
terly inflation (ranging from 1.0% to 1.1%) by 0.40% to 0.90%. None-
theless, several factors will impact whether this proposal will make
ETH deflationary and increase its scarcity, as many have posited.
The split between base fees and miner tips will ultimately be depen-
dent on the state of the Ethereum network in the future and our esti-
mates used above could be inaccurate. Additionally, Layer 2 scaling
solutions and sidechains are already offloading transaction execu-
tion off the Ethereum mainnet, and thus aggregate fees on the Ethe-
reum mainnet are likely to continue falling over the coming months.
Accordingly, it is highly unlikely that EIP-1559 will make Ethereum’s
supply deflationary in the near term.
Notably, this burning mechanism is not specific to Ethereum. Solana,

for example, also burns transaction fees. Likewise, recycling mech-
anisms effectively decrease circulating supply which could have
material impacts over the long-term should networks generate large

61
and recurring bases of fee revenue.
Native Token Distribution

Tokens are generally created in initial sales to either venture capital
firms or, in some cases, the general public to raise funds to support
development. Additionally, there are several other categories for which
token supply is typically “earmarked” at the token creation event:
i. Staking Rewards / Incentives represent tokens slated to be paid
out to validators and delegators or emitted in airdrops.
ii. Foundation / Ecosystem Support tokens are typically reserved for
building out infrastructure, securing strategic partnerships, and
supporting projects that are looking to deploy apps on these net-
works.
iii. Development Organization and Team tokens incentivize develop-
ers tasked with developing core platform technology and con-
ducting ongoing research.
Irrespective of how tokens were initially segmented, how they are

emitted into circulating supply is an important consideration. Tokens
sold to venture capital firms or granted to development team mem-
bers typically come with vesting periods that introduce them into

62
circulating supply over several years. Development organizations and

foundations typically retain large holdings of native tokens. Some of
these organizations publish transparency reports detailing the actions
taken with tokens under their custody while others have limited trans-
parency surrounding token holdings and related actions taken.
Why is valuing native tokens challenging?

Some crypto assets, such as DeFi tokens lend themselves well to
traditional financial analysis. Native tokens do not. While they have
specific use cases within their respective environments, they are
issued in censorship-resistant environments and can ultimately be
used for whatever users want to use them for.
In the case of PoS networks, they are always used to

secure the network through staking. Sometimes they are
used as a medium of exchange for transferring value.
Other times they are used as a collateral or reserve
asset. And in a scenario where one or many of these
platforms gain mainstream adoption with billions of
active users, it is difficult to predict how their use cases
and value capture mechanisms could evolve.
Staking payouts, tokenomic models like EIP-1559, and gov-

ernance privileges all create incentives for holding tokens
over the long term. Nonetheless, the intersection of these
features against a backdrop of token inflation, which is
necessary to bootstrap platform security, makes valuation
a challenging task.
Additionally, native token value has a unique relationship with plat-

form security; especially when it comes to PoS networks. In PoS net-
works, the aggregate value of staked tokens serves as a proxy for
how costly it can be to attack the network. Networks with native
tokens that are more valuable, more widely distributed, and more
commonly used for staking are more difficult to attack.

63
All else equal, higher attack difficulty makes platforms more attrac-
tive venues for deploying applications which could, in turn, drive
more usage and incremental token value. Hence, native token value
and platform security are intertwined and there is a potential for
positive feedback loops. The opposite effect is also true. If a native
token has little to no value, its platform provides weak censorship
resistance and security guarantees. And it will most likely not be an
attractive venue for deploying applications that could drive incre-
mental token value.
Price performance of native tokens can be found in Appendix A.

Appendix B provides an overview of traditional investment products
that offer direct exposure to native assets.
Ecosystem Members & Organization Fundraising

While there is no formal executive management team for smart con-
tracting platforms, individuals play a critical role in their operation.
They design platforms and tooling, develop applications on top of
them, and perform ongoing technical research and development.
Certain individuals typically have significant influence over major
design decisions of their respective platforms; especially in commu-
nities that are in their early growth stages and still developing for-
malized governance processes.
Pinpointing the most influential individuals within a blockchain eco-

system is an art and not a science. Nonetheless, we make an effort
at pinpointing these individuals below. The prior work experience
of these individuals and the financial backing of their networks pro-
vides context on how these platforms came to life and how their
visions could unfold over the future.

64

65

66
Company and Foundation Fundraising

While smart contracting platforms are native to the internet, they
are typically developed by for-profit companies and supported by
related non-profit organizations. These organizations tap the capital
markets through a combination of equity financing (selling ownership
stake in their companies) and token sales (selling the native tokens
of their respective blockchain networks) to support the development
of platform technology and the growth of their respective ecosys-
tems. These organizations and their related fundraising histories are
shown in the table below.

A Framework for
Comparison
V
Conclusions
&
Outlook
68
Conclusions & Outlook
Comparing different smart contracting platforms requires a

multi-disciplinary analysis of their technical design, related block-
chain and ecosystem data, and an understanding of the people and
organizations behind them. Our analysis of seven of the more active
and differentiated platforms serves as a blueprint for comparison. It
also provides context for drawing conclusions about the outlook of
the broader platform landscape.
Conclusions
As more products and services are delivered on top of smart con-
tract platforms, attempting to quantify decentralization will become
an increasingly important task. The requirements to participate in
consensus provide insight into what flavor of decentralization plat-
forms are capable of delivering. Market data allows us to make quan-
titative estimations of real-time levels of decentralization. Never-
theless, the true composition of validator sets is opaque, and thus
quantifying decentralization is more of an art than a science.
How networks are architected is one of their biggest differentiating

factors. Some are employing the battle-tested one-chain approach
and optimizing their networks to provide the highest level of per-
formance. Others are deploying multi-chain frameworks and forging
full force into the land of asynchronous networks where cross-chain
communication facilitates interaction between and within applica-
tions. Both approaches come with their own sets of pros and cons
that have implications for their performance, decentralization, and
usability characteristics.
Throughput and finality times provide insight into platform perfor-

mance. They can be sourced from live results, testnet results, and
developer estimates which come with differing levels of certainty.
On-chain data can serve as a sanity check for comparing actual per-
formance vs theoretical performance but has limitations as many
networks have yet to see sufficient adoption to hit theoretical limits.
Due to different data tracking methods, examining on-chain metrics
over time both within and across networks is necessary for extract-
ing signal.

69
Native tokens sit at the center of all PoS networks. They have a
unique and intertwined relationship with their respective networks’
security profiles that creates the potential for feedback loops. Toke-
nomic models such as EIP-1559 provide an early look at what the
longer-term value capture mechanisms of these platforms could be.
Nonetheless, the combination of incentives for longer-term token
holding against a backdrop of token inflation, and in some cases
uncapped supply, makes valuing them challenging.
Trends of ecosystem engagement and developer activity are use-

ful for analyzing the growth prospects and the state of platform eco-
systems. While these networks are owned and operated by distrib-
uted bases of token holders, select individuals will play an important
role in the direction of these platforms for years to come; even in
instances where they employ on-chain governance.
Outlook
PoS sybil resistance mechanisms have been around for several years
now. But Ethereum’s move from PoW to PoS is a watershed moment
for its network. Tens of billion dollars of value are being transacted
on Ethereum on any given day and its move to PoS will significantly
alter how the network delivers decentralization and security. On the
performance and usability front, rollups and scaling solutions will
likely alleviate the congestion on the Ethereum mainnet over the near
to medium term and reduce transaction fees. How these solutions
will affect Ethereum’s composability, which has been central to gen-
erating network effects, remains to be seen.
To date, compatibility with the Ethereum development environment

(Solidity and the Ethereum Virtual Machine) has allowed many com-
peting platforms to leapfrog the typical obstacles associated with
developing applications and tooling for their ecosystems. In particu-
lar, Binance Smart Chain’s ecosystem growth has largely been attrib-
utable to “copy and pasting” applications from Ethereum onto its
chain and providing users similar services at lower transaction fees.
While this has driven significant adoption of its platform, it has come
at the expense of lower security.

70
Blockchain Security
Security is an important consideration at both the base consensus
layer and application layer of blockchain ecosystems.
Concerns over the centralization and thus the lack of censorship

resistance at the base layer of networks like Binance Smart Chain are
well founded. With a small number of nodes and concentrated finan-
cial stake, networks like BSC could more easily be censored by a
third party such as a government agency and forced out of opera-
tion. Hence, networks with low levels of decentralization pose risks to
their stakeholders; regardless of whether or not they are aware of it.
On the other hand, security vulnerabilities at the application layer

of smart contract platforms are less subtle. As early as 2016, a vul-
nerability in the DAO smart contract resulted in a $60MM hack that
caused a permanent divide between the Ethereum and Ethereum
Classic communities. And just over the past 18 months, applications
deployed on Binance Smart Chain and Ethereum have seen upwards
of $400MM worth of value compromised in hacks.
Notably, these application hacks are primarily attributable to devel-

oper oversight (missing sanity checks, math logic errors, errors
transferring applications across chains, etc...) rather than vulnerabil-
ities with the base layer of these platforms. And there is an element
of adverse selection in highlighting Binance Smart Chain and Ethe-
reum as they have seen the most activity and thus have the larg-
est attack surfaces. But as platforms support more economic value,
the costs associated with vulnerabilities at the application layer are
also set to increase; especially if applications reach mainstream user
bases. Accordingly, what development environments platforms sup-
port could become a more important consideration going forward.
Development Environment
Ethereum’s flagship smart contract language, Solidity, and its exe-
cution environment, the Ethereum Virtual Machine, are far from the
only frameworks available for deploying decentralized applications.
As seen in the table below, many platforms support different smart

71
contracting languages that come with unique attributes. For exam-

ple, smart contracts on Algorand can be coded in Python and com-
piled down to lower-level smart contract languages such as Teal.
Additionally, languages such as Clarity are “decidable” and provide
assurances on how smart contracts will function before they are per-
manently deployed into live production environments, thus reducing
the attack surface of applications.
"There's something in the Cosmos, Polkadot, and Solana also support coding of smart
neighborhood of 100,000 contracts in more familiar languages such as Rust with
developers working on different execution environments including WebAssembly
blockchain today. There's (“WASM”) and Sealevel. WASM is a lightweight and plat-
close to 20 million (develop- form-independent instruction set standard for web brows-
ers) who aren't... Developer ers developed by the W3C workgroup that includes Google,
experiences need to improve Mozilla, and others. Sealevel is Solana’s runtime that allows
dramatically for mainstream for parallel processing whereby non-overlapping transac-
applications to take hold." tions can be executed concurrently.
—
Steve Kokinos,
CEO at Algorand Over the near term, this Ethereum-centric development
environment appears to be here to stay. Building out plat-
form developer bases and tooling infrastructure does not happen
overnight and many competing platforms will continue to offer Ethe-
reum compatible alternatives to bootstrap ecosystem growth. Over

72
the medium term, the evolution of new language constructs and exe-
cution environments bears watching. They hold the potential to not
only broaden the addressable universe of blockchain developers but
also deliver performance gains at the execution level.
Interoperability
The smart contract platform landscape is fragmented across several
dimensions.
i. Layer 1 platforms continue to carve out their own single-chain
and multi-chain networks
ii. Layer 2 solutions are going to take transaction execution off
Layer 1 platforms and onto their own chains
iii. Sidechains with their own security models are being launched
To date, cross-chain asset transfers via bridges such as RSK’s Pow-

Peg have been the most tangible examples of what interoperability
looks like. They have enabled users to port assets across chains and
leverage them in different environments.
"Imagine every blockchain But with the advent of multi-chain networks with sharded
right now as a small tribe states such as Ethereum 2.0 and Polkadot, cross-chain
living on an island in a vast communication will be required not only to agree on the
archipelago. So, what IBC global blockchain state but also to facilitate interaction
enables is the discovery of between applications that reside in one or multiple shards/
shipbuilding, which allows parachains with other applications in other shards/para-
these tribes to travel between chains. Polkadot will employ a Cross-Chain Message Pass-
each other" ing (XCMP) protocol for parachains to send arbitrary
—
Peng Zhong, messages between each other within its ecosystem. If
CEO at Tendermint Ethereum does indeed go the route of transaction execution
in shards, it would need to employ a similar mechanism to
facilitate cross-shard messaging, although this is likely years away for
its network. As these cross-chain communication technologies have
not been deployed at scale in production environments, their impend-
ing deployments and the associated impact on users bears watching.
Cosmos’s Inter‑Blockchain Communication Protocol (“IBC”) is one

of the most detailed specifications for interchain communication to

73
date. At its core, it is a messaging protocol that is often analogized

to the TCP/IP layer of the blockchain. IBC is agnostic to the actual
content messages which could include fungible token transfers,
cross-ledger voting, account delegation, and cross-ledger decen-
tralized exchange order and settlement information. It went live in
production earlier this year and could provide insights into the future
of interoperability. It is currently being adopted by several zones that
leverage Cosmos technology with the potential to be adopted by
other chains that reside outside of the Cosmos ecosystem.
Closing thoughts
From different network architectures to different consensus algo-
rithms to different native token designs, there are hundreds of ways
to construct a smart contract platform. Based on our analysis of just
seven different platforms, the likelihood of a “one chain to rule them
all outcome” appears all but impossible. Indeed, the more analyt-
ical rigor these platforms are assessed with, the more apparent it
becomes that predicting which platform(s) will succeed over the long
term is challenging. In many respects, they are very similar. In other
respects, they could not be more different.
Appendix:
Figure A: The table below displays YTD performance for the native
tokens of platforms in the sample set analyzed.

74
Figure B: The table below provides an overview of traditional invest-

ment products that offer exposure to native assets of smart contract
platforms.

75

A Framework For Comparison: Research

Uploaded by

Copyright:

Available Formats

A Framework For Comparison: Research

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Framework For Comparison: Research

Uploaded by

Copyright:

Available Formats

Research Layer-1 Platforms:

TH EB LOCK R ES E A RCH .CO M PU B LI S H DATE 08/11/21

Decentralization. Scalability. Security. They are words that are

But Bitcoin is one part, albeit a very important part, of a broader

But the story doesn’t stop at Ethereum.

Dozens of smart contracting platforms have launched in tandem with

Research Layer-1 Platforms: A Framework for Comparison

They span platforms that very much embody the decentralized

The breakneck pace of development and competition amongst these

Why are we writing this report?

The Investable Crypto Landscape

With each passing year, the likelihood of a “one blockchain to rule

Research Layer-1 Platforms: A Framework for Comparison

How we are structuring this report

With this background, we analyze a select set of platforms. We com-

Research Layer-1 Platforms: A Framework for Comparison

Algorand Inc. - Algorand builds technology that accelerates the con-

The Algorand Foundation - The Algorand Foundation is dedicated to

Research Layer-1 Platforms: A Framework for Comparison

We are also grateful to those that shared their perspectives and

Research Layer-1 Platforms: A Framework for Comparison

Anonymous digital cash and pseudonymous reputation systems were

The Bitcoin network is best described in a few select words.

It is censorship-resistant and decentralized. Bitcoin is not owned by

It is permissionless. Anyone can send, receive, and hold bitcoins

It is pseudonymous. The closest thing to identifiable people on the

It is secure. Bitcoin miners are economically incentivized to secure

Beyond BTC: Omni Layer and USDT

Research Layer-1 Platforms: A Framework for Comparison

guage, Script, allows for more complex transactions. Multi-signature

Accordingly, decentralized securities trading, property rights, and

Founded in 2012, the Omni protocol (originally named Mastercoin)

Tether’s stablecoin, USDT, is the most prominent asset issued using

Research Layer-1 Platforms: A Framework for Comparison

“At Tether, we truly care for Omni,

Not all USDT are created equal

i. The cost to transact in USDT on Omni is high relative to other

Beyond Payments: Sidechains and Smart Contracts

Research Layer-1 Platforms: A Framework for Comparison

For instance, the Taproot upgrade, which is expected to take effect

Given this conservatism and the relatively limited set of programma-

RSK leverages the security mechanisms of Bitcoin through a pro-

What can be built on RSK?

Research Layer-1 Platforms: A Framework for Comparison

Hence, any applications supported on Ethereum can theoretically be

Launched in December of 2020, Sovryn is one of the more promi-

Ethereum as a Bitcoin sidechain

Upwards of 245,000 synthetic BTC (assets whose value is tied to

Research Layer-1 Platforms: A Framework for Comparison

Research Layer-1 Platforms: A Framework for Comparison

Smart Contracts Defined

The basic idea of smart contracts,

What are smart contracts?

Smart contracts execute under a predefined set of conditions and

What are smart contracting platforms?

Research Layer-1 Platforms: A Framework for Comparison

Defining the Layers of the Decentralized Economy Stack

Sidechains and Application-Specific Chains such as RSK, are block-

Scalability solutions are typically referred to as Layer 2 solutions. They