This is a chapter from the book Token Economy (Third Edition) by Shermin Voshmgir. Paper & audio formats are available on Amazon and other bookstores. Find copyright information at the end of the page.
Bitcoin’s success sparked a renaissance in P2P networks, leading to the development of numerous alternative blockchain networks and complementary Web3 protocols. The Bitcoin source code was modified multiple times, serving as a template for new blockchain networks that aimed to improve privacy, scalability, or network functionality.
The open-source nature of Bitcoin allowed developers to modify its system architecture. Some early projects sought to create faster or more private payment networks, such as “Litecoin” (which increased block speed by adjusting the consensus algorithms) or “Zcash” (which introduced alternative cryptographic proofs to enhance privacy by design). Other projects moved away from Bitcoin’s financial focus entirely. “Sia,” for example, built a decentralized file storage network, while Steemit built its own blockchain infrastructure to power a tokenized social media platform. Some networks were even created without a clear utility or just for fun, such as “Dogecoin,” which began as a meme but later gained traction as an internet tipping currency.
Eventually, the idea emerged to move away from single-purpose blockchain networks. Developers sought more flexible architectures that could handle any type of P2P transaction. Early projects like “Mastercoin” (now “Omni”) and “Colored Coins” experimented with using Bitcoin’s transaction metadata to represent assets or contracts, but these solutions were inefficient. Vitalik Buterin, who briefly contributed to these projects, recognized that Bitcoin’s scripting limitations made general-purpose applications difficult. He started the Ethereum project, which separated application execution from the core transaction processing layer, enabling easily programmable decentralized applications.
Ethereum’s innovative blockchain architecture and success inspired many projects. Some closely replicated Ethereum’s design with minor modifications, while others took inspiration from its versatility but diverged significantly in architecture. Notable examples include “Avalanche,” “Binance Smart Chain,” “Cardano,” “EOS,” “Polygon,” “Solana,” “Stellar.” While some of these networks gained significant market traction, others struggled to attract sustained adoption from developers, node operators, or users.
From a technological perspective, alternative blockchain networks tried to stand out by modifying different parts of Bitcoin’s original system architecture: the consensus mechanism, permissions, data structure, cryptographic primitives, or abstraction level. However, a key challenge for any new blockchain project is attracting developers, node operators, and users. Without a robust and engaged ecosystem, blockchain networks struggle to sustain themselves. While technology matters, community and network effects matter just as much. The proliferation of alternative networks has therefore been marked by varying degrees of success. Many failed to establish a compelling value proposition, suffered from poor execution, or faced competition from established ecosystems like Bitcoin and Ethereum, even in cases where the technological value proposition was sound.
Alternative Consensus Mechanisms
One way to alter a blockchain protocol was to modify the consensus mechanism by tweaking it here or there. Over time, radically different consensus mechanisms emerged, most notably Proof-of-Stake and its variations. Few blockchain networks today use identical consensus mechanisms, which must always resolve and balance the following challenges: (i) How to achieve consensus on a unified history of transactions? (ii) How to align scarce resources with network security to deter malicious actors? (iii) How to mitigate security risks and attack vectors? (iv) How to avoid the concentration of power? Variations of Proof-of-Work, Proof-of-Stake, and Byzantine Fault Tolerant systems have been among the most widely adopted.
- Variations of Bitcoin’s Proof-of-Work were implemented in many early blockchain networks to create more privacy-preserving or faster networks. The first version of Ethereum also used Proof-of-Work but with different parameters, such as a different hashing algorithm (Ethash instead of SHA-256), shorter block time targets (~15 seconds instead of 10 minutes), and additional reward mechanisms such as compensating so-called Uncle blocks to incentivize miners and reduce chain centralization. In spite of improvements, Proof-of-Work networks require vast computational resources and can process only a limited number of transactions per second, which led to the development of less energy-intensive and more scalable consensus mechanisms.
- Proof-of-Stake (PoS) was developed as a more energy-efficient and scalable alternative to Proof-of-Work. Unlike Proof-of-Work, validators in Proof-of-Stake are chosen based on the amount of network tokens they are willing to stake as collateral. In this process, validators lock up their assets for a chance to add new blocks to the ledger, earning rewards in the form of newly minted tokens as well as transaction fees. The staked tokens serve as a security deposit that may be slashed if validators act maliciously or fail to follow protocol rules. While Proof-of-Stake promised to reduce energy consumption, it introduced new challenges: ensuring equitable token distribution to prevent validator centralization and addressing the nothing at stake problem—where validators might attempt to validate multiple conflicting transactions without financial consequences. The first project to implement Proof-of-Stake was “Peercoin” in 2012, which initially combined Proof-of-Work and Proof-of-Stake in a hybrid model before fully transitioning. Other networks that adopted Proof-of-Stake include “Tezos,” “Cardano,” or “Avalanche.” Ethereum also transitioned from Proof-of-Work to Proof-of-Stake in 2022.
- Delegated Proof-of-Stake (DPoS) is a more radical variation of Proof-of-Stake first implemented by “BitShares” in 2014. It combines Proof-of-Stake with elements of representative democracy, where token holders delegate voting power to a smaller group of validators, known as block producers. This model improves transaction throughput and scalability but introduces a higher degree of centralization by limiting the number of active validators. Other early blockchain networks that adopted variations of DPoS include “Steem,” “EOS,” and “Lisk.”
- Proof-of-History (PoH) is a cryptographic technique developed by “Solana” to enable high-speed transaction ordering. It is not a standalone consensus mechanism—it functions as a timekeeping system that works alongside Proof-of-Stake to increase throughput. It establishes a verifiable historical record that timestamps transactions before they are validated. This allows Solana’s validators to agree on the order of transactions without continuous communication, reducing latency and improving network scalability. Proof-of-History has faced criticism, primarily due to concerns about its high-performance hardware requirements, which some argue may lead to validator centralization. Critics also point to potential security risks associated with its unique timestamping approach, which some believe could introduce new attack vectors.
- Other variations of Proof-of-Stake: Many variations of Proof-of-Stake have been proposed over the years, but few have seen widespread adoption. Some of them were only implemented by a single network, while others remain conceptual. Examples include Leased Proof-of-Stake, Transactions as Proof-of-Stake, Proof-of-Importance, Proof-of-Capacity, Proof-of-Weight, Proof-of-Authority, and Proof-of-Elapsed-Time.
- Byzantine Fault Tolerance (BFT) mechanisms ensure network security even when some nodes act maliciously. In many implementations, BFT-based protocols can tolerate up to one-third of dishonest nodes before network security is compromised. While BFT is more resource-efficient than Proof-of-Work, it is also more centralized. One widely used BFT implementation is Tendermint, the consensus mechanism for “Cosmos,” which combines BFT principles with Proof-of-Stake validator selection to enhance scalability and security. Federated Byzantine Agreement (FBA), used by “Ripple” and “Stellar,” allows validators to select trusted peers instead of requiring full network agreement. Practical Byzantine Fault Tolerance (PBFT) is implemented in “Hyperledger Fabric,” primarily used for enterprise applications. Delegated BFT (dBFT), used by “NEO,” modifies BFT by introducing elected validators who reach consensus through multiple voting rounds.
Alternative Data Structures
Protocol developers not only modified the consensus mechanism but also explored alternative data structures to address challenges related to network capacity, ledger data availability, and levels of decentralization. As previously explained, in traditional blockchain networks, the ledger is represented by a data structure of cryptographically linked transaction blocks that grows over time. Every node in the network must continuously synchronize its copy of the ledger, requiring constant broadband connectivity and increasing disk space to store the ever-expanding ledger. These issues are magnified in data-intensive networks like Ethereum, which requires additional metadata for processing much more complex applications. Compounding the problem, neither Bitcoin nor Ethereum (before the transition to Proof-of-Stake) provided direct economic incentives for operating full nodes, which only maintain a copy of the ledger but do not participate in the resource-intensive consensus process, leading to reduced participation in maintaining complete ledger copies and thus contributing to network centralization.
Efforts to address these challenges include dividing the ledger into smaller and more manageable partitions distributed across network participants (sharding), as well as mechanisms to prune or archive less critical ledger entries. Sharding was initially incorporated into Ethereum’s scalability roadmap as part of its transition to Proof-of-Stake. However, Ethereum shifted its focus toward other solutions (rollups and data availability sampling) rather than implementing full execution sharding in the near term (read more on this topic in the chapter “Scalability Challenge.”)
Other blockchain networks experimented with completely different data structures, such as Directed Acyclic Graphs (DAGs), to address the issue of ledger maintenance by removing the sequential confirmation bottleneck of blockchains. Unlike the data architecture of a chain of transaction blocks, DAGs do not bundle transaction data into sequential blocks. Instead, newly added transactions must reference and validate previous transactions, forming a network of interconnected data points. Each new transaction typically references two prior transactions, creating a graph that converges as validations occur. Nodes validating incorrect transactions find their additions rejected by other participants. Not all DAGs work the same way—some use parallel validation of transactions rather than linear confirmation.
A related innovation is the InterPlanetary File System (IPFS), which employs a Merkle DAG to structure content-addressed data, allowing for the efficient representation of hierarchical relationships, such as links between file directories. IPFS provides a decentralized data storage solution, complementing blockchain networks. It is not a blockchain network but a distributed file system for off-chain data storage. It does not provide on-chain consensus but is often used alongside blockchain-based solutions (i.e., Filecoin, Arweave) for decentralized file storage.
Permissioned Networks
Yet another variation of blockchain networks was private and permissioned networks that started to emerge—primarily developed by industry consortia. They restricted network access to invited members only. While both permissioned and permissionless networks share the common feature of a collectively maintained ledger, they fundamentally differ in the way trust is established. Public and permissionless networks like Bitcoin or Ethereum rely on cryptoeconomic incentives and decentralized consensus mechanisms to maintain security. By contrast, permissioned networks rely on legal agreements between a controlled set of known participants. These networks are invite-only and do not require resource-intensive consensus mechanisms because trust is enforced through legal contracts and reputation rather than cryptoeconomic incentives.
Permissioned networks were initially driven by efficiency goals and regulatory concerns, as early public blockchain networks faced scalability issues and because the regulatory landscape was still very uncertain. Hybrid networks emerged over time, allowing public access to certain functions while restricting others to approved participants. Depending on a participant's role, certain rights may be granted upon invitation, while other rights could be open to everyone without requiring explicit permission. The most important questions in this context are:
(i) Who can validate transactions?
(ii) Who is allowed to manage the ledger and add transactions?
(iii) Who is allowed to read data?
(iv) Who is allowed to use the network?
Critics of permissioned ledgers argue that the concept of "trust by authority" contradicts the decentralization ethos of blockchain networks. Furthermore, many early blockchain advocates predicted that permissioned networks would ultimately resemble the "Intranets" of the 1990s—temporary solutions that were eventually overtaken by the widespread adoption of public Internet infrastructure. Recent developments support this view, with financial institutions increasingly building on public blockchain networks like Ethereum, Bitcoin, and Solana as they grow more familiar with their applications and as regulatory clarity improves. However, permissioned ledgers are not obsolete in all cases. They remain valuable in scenarios that require high security, privacy, or industry collaboration, where data confidentiality and controlled access are crucial. Examples of permissioned networks are “Hyperledger Fabric,” “Corda,” or “Quorum.” Examples of hybrid networks are Polygon's Supernets or Ethereum's private rollup solutions.
Smart Contract Network
Unlike the Bitcoin network, which was designed to facilitate peer-to-peer electronic cash transactions, the Ethereum network was conceived as a decentralized computing network capable of issuing any type of token—not just currencies—and settling more complex social and economic interactions. While Bitcoin follows a single-purpose logic of transferring BTC from one user to another, Ethereum’s architecture was designed to be more versatile. Its system architecture decouples the processing of so-called “smart contracts” from the underlying blockchain network that secures transactions. This was achieved by creating a decentralized virtual machine—the Ethereum Virtual Machine—which enables a flexible development environment where any type of programming logic can be executed peer-to-peer. Ethereum was the first network to provide a standardized infrastructure for smart contract development, allowing developers to create self-executing agreements with minimal effort and without modifying the core blockchain protocol. This architectural innovation had a profound impact, inspiring numerous projects to develop alternative smart contract networks, each introducing its own specialized system architecture with unique features and optimizations.
The term “smart contract” was originally coined by Nick Szabo in 1994, during the early days of the web, to describe how digital transactions could be used to formalize economic and social relationships. This was two decades before Ethereum launched and reintroduced the concept into mainstream discourse. Szabo justified the term “smart” by emphasizing that digital contracts could be automatically executed and verified without requiring intermediaries. He defined smart contracts as digital transaction protocols that automatically enforce contractual agreements, with the goal of reducing uncertainty and minimizing enforcement costs. Unlike traditional contracts, which rely on the legal system to enforce contractual terms retroactively, smart contracts were envisioned to provide proactive security mechanisms, ensuring compliance through predefined, automated execution rules. Szabo acknowledged that while smart contracts could significantly reduce the need for legal enforcement mechanisms, they could never fully eliminate the need for human discretion in complex legal matters.
Szabo was very specific in outlining how smart contracts could be technically implemented. He described how various cryptographic methods—including public key cryptography, digital signatures, blind signatures and zero-knowledge proofs—could be used to secure agreements. He also stressed that for smart contracts to be reliable and functional in real-world applications, they must be trustworthy and resistant to both deliberate attacks and unintentional disruptions. However, at that time, Szabo had not yet devised a method to fully decentralize trust and make such a system resistant to Sybil attacks. In 1998, he came up with an idea for electronic cash that would be as inflation-resistant as gold, which he called “Bit Gold.” As previously mentioned, Bit Gold was never implemented because Szabo did not find a way to replace the trusted intermediary with a Sybil-attack-resistant system—the issue that Bitcoin’s Proof-of-Work finally resolved.
Ethereum smart contracts function as agreements formalized in code. The smart contract acts as the core governance/business logic of any decentralized application, containing a set of predefined rules under which participants agree to interact. Smart contracts are executed and verified by all participating network nodes—enabling transparent and verifiable governance structures, allowing agreements to be publicly auditable and enforced without intermediaries. Unlike traditional contracts that require legal enforcement after a breach occurs, smart contracts reduce risks by automating enforcement upfront, making breaches either impossible or economically costly.
Think of them as a cryptographic lockbox that unlocks digital assets, access rights, or governance privileges only if predefined conditions are met. These conditions are triggered by on-chain or off-chain data inputs (aka “oracles”), which are verified collectively by the network. Instead of relying on human oversight, execution is automated and collectively enforced. If implemented correctly, smart contracts can provide higher security guarantees than traditional legal agreements, as they reduce the coordination costs associated with auditing and enforcement. A primitive example of a smart contract is a vending machine. The rules of exchange are programmed into the machine: a user selects a product, inserts money, and receives the product if the conditions are met. If the inserted amount is insufficient, the machine does not dispense the product. If the selected item is out of stock, the machine automatically refunds the money. Similarly, smart contracts automate digital agreements using predefined rules, without requiring manual intervention. All network nodes collectively validate the rules.
The scope of smart contracts ranges from simple bilateral agreements to complex multi-stakeholder governance structures. They can be used to facilitate token issuance or steer complex decentralized organizational bylaws—encoding intricate decision-making frameworks. DAOs represent one of the most complex applications of smart contracts, where an organization's bylaws, statutes, and governance rules are enforced through self-executing code rather than traditional management structures. Smart contracts enable collective management of tasks, payments, and agreements, reducing the risk of fraud or human bias. Additionally, they can mitigate agency problems in organizations by enforcing transparent governance mechanisms and minimizing bureaucratic inefficiencies. Use cases for smart contracts that represent different types of assets and financial applications are explored in the second part of this book (Money, NFTs & DeFi), while smart contracts governing decentralized organizations are examined in the third part (DAOs & Purpose-Driven Tokens).
Unfortunately, the term "smart contract" is somewhat misleading, as smart contracts are neither inherently intelligent nor equivalent to legal contracts. A smart contract can only be as "smart" as its original programming, meaning it is simply an automated ruleset that enforces predefined conditions. Instead of being flexible or adaptable, a smart contract functions like a dumb robot bureaucrat that strictly enforces conditions without human discretion. The integration of AI tools into smart contracts could make them actually “smart.” Furthermore, smart contracts do not inherently replace the legal system, even though they make contract enforcement much more effective. Many unresolved techno-legal challenges remain, particularly in ensuring that smart contracts are legally binding and compliant with jurisdictional requirements. For smart contracts to function as legally enforceable agreements, collaboration between lawyers, developers, and policymakers is necessary. Advanced decentralized dispute resolution mechanisms are also required to introduce flexibility and human oversight, enabling exceptions and arbitration when needed.
Smart Contract Example
If two people don’t know and don’t trust each other, they usually need a trusted third party to serve as an intermediary to verify economic transactions and enforce them. Take the example of buying and selling a car: if Alice wants to purchase a car from Bob today, a series of intermediary services are required to verify and authenticate the deal. The process differs from country to country but always involves at least one—and usually more—trusted third parties, such as a motor vehicle registration authority, a notary, and/or an insurance company. Buying a used car can be a complicated, lengthy, and costly process. If and when all involved authorities and companies migrate to blockchain infrastructure, smart contracts could be used to formalize all the rules of a valid car sale, including the settlement for add-on services like purchasing a car insurance policy.
If Alice wanted to buy the car from Bob using smart contracts, the potential process could look like this:
- Bob will use the internet to find a service where he can post his used car and define the terms of sale using some decentralized version of eBay, for example. This step is no different from today, but one or several smart contracts are at the core of the decentralized application displaying the website. Bob needs to open the decentralized application on his device and connect his wallet for identification and authentication.
- Meanwhile, Alice searches the web and opens the decentralized version of eBay where Bob posted his car. Once she finds a car that she likes—Bob’s car—she needs to connect her wallet and click on “buy.” The smart contracts will communicate with all nodes in the blockchain network to verify whether Bob is the owner of the car and whether Alice has enough funds available. The information about both states—the ownership titles of the car Bob claims to sell and the amount of tokens Alice has—is recorded on the ledger of one or several blockchain networks. If several blockchain networks are involved, inter-blockchain communication will also be initiated. Upon clicking the “buy” button, additional smart contracts communicate with the blockchain infrastructure of the insurance company, giving Alice the option to select an insurance plan from selected providers. The insurance plan could be calculated on the fly, with rates based on the car’s data and Alice’s driving history.
- If the network nodes confirm that both conditions are met—that Alice has sufficient funds and that Bob is indeed the owner of the car—the balance of the payment tokens as well as the tokens representing the car’s deed are updated on every node in the network. Alice is registered as the new owner of the car, and their funds are adjusted accordingly: Bob now has 20,000 more tokens in his account, while Alice has 20,000 fewer tokens. Alice also receives an access code to the smart lock for the garage where she can pick up the car. If she registered with a car insurance company upon buying the car, another smart contract is triggered, and the network nodes would collectively register the issuance of a tokenized insurance certificate.
- The car—which has a unique blockchain identity—was previously parked in the garage of a licensed mechanic who performed inspections. Once the funds are transferred, Alice receives a notification about the address of the garage where the car can be picked up, sending her an access code to the smart lock of the garage. The smart lock also has a blockchain identity and can communicate with the smart contract and the rest of the network. With the access code, Alice can unlock the garage, activating her wallet, which confirms her as the rightful owner of the car. All network nodes update the status to reflect that the car has been picked up.
Using smart contracts, manual intervention by institutions such as motor vehicle authorities, insurance companies, and, in some countries, notaries can be avoided—but only if the regulatory environment permits it and all participants in this scenario are using blockchain infrastructure. Certain automated processes would require additional data from external software and hardware—for example, photographs taken in the garage to monitor the state of the car. Smart contracts could also manage access rights to one’s car if it is equipped with a smart lock that has its own blockchain identity and can communicate with the blockchain network. Every computer running the blockchain protocol can verify whether someone is the rightful owner or user of a car.
In spite of all the potentials of such a use case, smart contract security is a big issue that needs to be considered when designing such highly automated execution processes as described in this example. Careful procedural security considerations are required when conceptualizing and implementing decentralized applications and their contracts:
Oracle security: Ensuring that data from off-chain sources is trustworthy.
Secure coding & formal verification: Utilizing computer-aided tools to verify that the code is free from loopholes and functions as intended.
Procedural security & dispute settlement: Establishing additional on-chain and off-chain mechanisms to resolve complaints or unforeseen situations. Alternative smart contract programming languages—as well as the merging of smart contracts with legal contracts—are also key topics that will require further cross-disciplinary solutions.
The use case presented is a good example of any decentralized applications that require integration with the physical world, to reliably connect objects to the internet in general and blockchain networks in particular. Such technological interplay paves the way for entirely new products, services, and asset classes over the coming decades. However, it also raises socio-political questions. Once all objects are tagged with unique blockchain addresses and can be uniquely referenced in a blockchain network—and if they are managed by increasingly intelligent software—these devices could become autonomous economic agents in a man–machine economy. The questions of (i) whether and how we will transfer decision-making authority from humans to machines, (ii) what socio-political implications such a transition could have, and (iii) how we, as a society, want to shape these phenomena must be publicly discussed before such systems are designed.
Decentralized Applications
Smart contracts are the hearts and brains of any decentralized application, which define its business/governance logic. Decentralized applications differ from centralized applications in that they operate on publicly maintained infrastructure (P2P networks) rather than private internet infrastructure (servers). Although decentralized applications existed before Bitcoin—such as Tor, BitTorrent, Popcorn Time, and BitMessage—these systems still required some form of central coordination for governance, content distribution, or user management.
- Centralized applications are the predominant type in Web2, developed and controlled by either private or public institutions. These institutions employ individuals to develop and maintain internet-based services. They unilaterally determine strategic software development goals, governance rules, and access policies. The code is often closed-source and proprietary, preventing users from auditing or modifying it. These institutions manage servers, databases, and IT infrastructure, funding operations through user or advertiser payments. Users pay service fees directly or indirectly with personal data and ads. They have little control over their data and cannot influence platform rules, making them dependent on provider decisions. Security is trust-based, enforced through contracts and system administrators. While some offer APIs (Application Programming Interfaces), access is not guaranteed and can be revoked.
- Decentralized applications are often co-developed by autonomous individuals and institutions. Their governance structures fundamentally differ from Web2-based institutions. Participating individuals and institutions can collectively decide on the network rules and collectively execute application services. The code is typically open source and publicly auditable, and the process of code contributions is also public. Application developers don’t have to ask permission from a private company or public institution to use blockchain infrastructure or build services on top of another decentralized application. They can build their product on top of any Web3 protocol without the threat of revocation. A decentralized application is executed on a public blockchain infrastructure and complementary Web3 protocols. Contractual relationships between participants of a decentralized application are automated through smart contracts, which provide procedural security without necessarily requiring traditional legal contracts—although legal agreements may still be necessary for compliance with government regulations. Despite their different backend infrastructure, decentralized applications visually resemble traditional applications because they use the same front-end technologies for rendering web pages or mobile applications. However, instead of interacting with centralized servers, they communicate with blockchain networks, smart contracts, and other Web3 protocols for decentralized off-chain data storage, etc. The front-end data, including audio, video files, and documents, can be collectively stored and managed using decentralized storage networks such as IPFS or Arweave, but they could also be centrally stored on server infrastructure. The backend of a decentralized application represents the core business logic, which is formalized in one or several smart contracts that process all data feeds—aka blockchain oracles—from inside and outside the network to manage the state of all network actors. A decentralized application either provides a wallet or requires users to use a compatible wallet to interact with the application and all other nodes of the underlying blockchain infrastructure used. Account management is also decentralized, provided by the blockchain infrastructure and the wallet application. Users and operators of decentralized applications pay network fees to blockchain node operators and other relevant protocol operators whenever they execute a transaction rather than investing in private server infrastructure. In practice, off-chain data processing in decentralized applications often involves trade-offs between decentralization, scalability, and cost, leading to varying degrees of decentralization.
While some decentralized applications use decentralized solutions like decentralized oracles, decentralized storage, and Layer 2 networks to maintain trust-minimized data integrity, many others still rely on centralized off-chain servers (such as traditional APIs or cloud services) for efficiency and fast response times. Full decentralization is often expensive and inefficient, which is why many application developers have adopted hybrid models, where critical logic remains on-chain while computation, storage, and indexing are handled off-chain, introducing varying degrees of reliance on trusted third parties or distributed networks.
Next: Challenges of Blockchain Networks →