On building a blockchain

33 minute(s)

Introduction

The design space for L2s, L3s, and alt-L1s has exploded over the past months, pushing the boundaries of throughput, cost-efficiency, and customization. With hundreds of networks already live (and many more on the horizon), I'm feeling a bit of "new chain fatigue", but it's clear that building new chains isn't a fad - it's a new paradigm for how teams bring products to the market.

The teams building these blockchains have to make countless choices, and in this guide I try to walk through as many of them as possible. We'll start by exploring why someone would want to do this in the first place, and then dive into the strategic, technological, and go-to-market considerations that come along with building a blockchain. Throughout, we'll explore the decision criteria that a team needs to take in standing up their core stack. I'll outline the choices made by leading chains in small callout boxes throughout.

Table of contents

• Why launch a new network
• Strategy
  • Mission
  • Differentiation
  • Edge
• Technology
  • Core stack
    • Rollup or alt-L1
    • Bitcoin or Ethereum
    • Framework
  • Network setup
    • Implementation path
    • Execution
    • Data availability
    • Sequencer
  • Dev tooling
    • RPC
    • Oracle
    • Indexer
    • Block explorer
    • Wallets
    • APIs
• Ecosystem
  • Anchor projects
  • Broader ecosystem
• Closing
• Credits

How to build a blockchain

Before jumping in, let's take a very quick, simplified look at the steps. This guide will walk through these 5 steps in significant detail.

Why launch a new network

Before jumping into launching a blockchain because it's trendy, it's important to consider the pros and cons of doing this in the first place. Regardless of which approach you're taking (Ethereum L2/L3, Bitcoin L2, or alt-L1), the core advantages of building a new network vs. operating on an existing one are one of three:

• Greater throughput: L2s and L3s reduce the amount of data that needs to be stored and processed on the (expensive) lower-level chain, allowing for more transactions per block. Alt L1's can be designed with greater throughput in mind from a much more fundamental level, allowing for the same outcome.
• Lower costs: L2s and L3s bundle transactions together and decrease the underlying cost-per-transaction, making it more affordable for users to interact with the network. Alt L1's similarly can achieve lower costs by making different upfront choices on throughput and other configuration parameters.
• Customization: Rollups allow for low-level customization of core chain mechanics while benefiting from the security of the underlying chain (as compared to launching a net-new L1). Alt L1's trade off this security piggybacking for even greater degrees of customization.

For companies that already have a footprint in crypto, there are some more advantages that can factor into the decision on whether to build a blockchain or not:

• Adding token utility: Networks can be configured to use custom gas tokens, allowing teams to add utility to their existing assets (presumably driving prices up).
• Repositioning: Operating a blockchain repositions teams from building products/services to becoming "a platform", which typically can grow to capture much larger markets.

However, launching a new network comes with disadvantages as well.

• Complexity: Executing a new blockchain successfully can be technically complex, introducing a new layer of challenges (eg. data availability) into an already-complicated developer experience.
• Adoption: In addition to the potential UX challenge mentioned above, new networks need to work from the ground up to attract users rather than participating in an existing ecosystem with a pre-built user base, liquidity, etc. all while paying fees (to the L1 in the case of a rollup, or general node operating costs) to operate the network.
• Security: In most cases, it is difficult for new networks to achieve the same level of security as major existing L1s such as Ethereum. For applications where this is important, it's a difficult challenge to overcome.

Strategy

Given these pros and cons, the first step in launching a blockchain is defining your strategy, which can be broadly simplified into three key questions:

• What do you achieve with this blockchain that couldn't be done before? (your mission)
• Why should users care? (your differentiation)
• How will you compete against other networks? (your edge)

Mission

Your mission is the one-liner on what you're hoping to accomplish. For example...

• to solve a sector-specific need that isn't met by existing chains (eg. enforcement of NFT royalties and creator earnings at the protocol level)
• to solve for a functionality not addressed by other blockchains (eg. 10K+ transactions per second for trading applications and other high-throughput use cases)

Differentiation

Your differentiator is your pitch - how you get users to care and to attract activity onto the platform. This can be across an infinite number of dimensions...

• incentives (eg. native yield)
• superior performance (eg. greater TPS, lower fees)
• net-new functionality (eg. privacy)
• community (eg. other users on the network are high-value, socially aligned)

Edge

These two elements (mission + differentiation) together should tie very closely to your edge: why you are uniquely suited to build and operate this rollup. Other teams may land on the same “why” as you (as the “why” is typically an industry-wide unmet need). Other teams may even try to differentiate on the same basis, but should not be able to copy your edge. Let's take a look at several recently-launched & upcoming chains and their mission, differentiation, and edge.

While deeply defining the strategy for a new chain is outside of the scope of this guide, having a clear articulation of your mission, your differentiation, and your edge is critical, and will inform a number of downstream technical / GTM decisions.

Technology

Core stack

The first technical choice - what technology stack you will operate - is actually a set of 3 very tightly intermingled choices:

1. whether to build a rollup or an alt L1
2. if a rollup, whether on Bitcoin or in the Ethereum world
3. if in the Ethereum world, which settlement layer & stack

Let's consider these choices one by one.

Rollup or alt-L1

Deciding between launching a rollup or an alt-L1 really comes down to one key question: can you do what you want to as a rollup? I mentioned above the three primitive reasons someone would build a blockchain: better throughput, cost, and customization. For the most extreme expression of each, you'd need to build an L1.

If you don't NEED to be an alt-L1, you're probably better off operating a rollup. Building a net-new blockchain is harder, more expensive, and more time-consuming; that investment is only worthwhile to unlock something truly net-new that couldn't be done as a rollup.

Bitcoin or Ethereum

Framework

The specific rollup mechanism (optimistic or ZK) and settlement layer (Ethereum or another L1 making the rollup an L2, or an L2 itself making the rollup an L3) drive blockchains into one of 5 primary "frameworks": Arbitrum Orbit, OP Stack, Polygon CDK, StarkEx, or ZK Chains. It's impossible to decouple the rollups mechanism and settlement layer choices from each other, so instead let's consider them in tandem across a number of driving factors:

• Scalability: Different solutions offer varying degrees of scalability. You'll want to consider the transaction throughput each solution can handle and how it aligns with your project's needs. L3's typically offer more throughput than L2s. Separately, StarkEx is optimized for financial applications offering significantly higher throughput compared to other scaling solutions but for a narrower domain of use. Alternative L1's are completely unconstrained from the burdens of previous blockchain's design choices, and can thus be built for significantly greater scalability than L2s or L3s.
• Security: Typically, a rollup will inherit key properties from the chain that it settles to. Optimistic rollups heavily inherit the security of the chain they settle to (Ethereum mainnet in the case of OP-Stack, or Arbitrum in the case of Orbit), while ZK-based rollups introduce additional security elements to the equation. Polygon zkEVM and ZK-Stack both use ZK-SNARKs while StarkEx uses STARKs, offering post-quantum security.
• Compatibility: All but StarkEx are fully EVM compatible, meaning that most existing tooling designed for Ethereum mainnet can be simply translated over to the rollup. This may sound like a downside with no upside for StarkEx, but this results in the benefit of focus: the environment and tooling can be optimized for the use case without the overhead of general-purpose smart contract support. Even within the EVM-compatible world, there are differences in the level of tooling support. For example, OP-stack chains have explicit maintainers on viem, geth, and other low-level tools.
• Community: A strong community and ecosystem can provide better support and resources for development; assessing the presence of other rollups building on the chain and their alignment to your project is key. This is challenging to make “summary” assertions on the differences between chains here, and requires you to embed yourself in each ecosystem.
• Cost: The cost of transactions can vary between solutions. Depending on your project's needs, a solution with lower transaction costs might be more desirable. This is usually available at a tradeoff to one or more of the other factors to consider (eg. security). This can also be optimized in a downstream choice around data availability. In general, optimistic stacks (Optimism, Arbitrum) tend to be cheaper to run.
• User Experience: The impact of the solution on user experience, including transaction speed and cost, can be a significant factor. This again is usually a trade-off against other elements such as security. The key variables at the chain-level that impact UX are speed, throughput, cost, and withdrawal times.
• Sponsoring ecosystem benefits: Different chain ecosystems provide different levels of support and benefits to network builders on their stack. We can't dive into all of the differences here, but assessing the types of support offered and how they align to your needs can be a critical input. Optimism and Arbitrum are the most mature in this regard, but zkSync Era, Polygon, and others are hot on their heels.

Network setup

Once you've decided on where to play, your next set of key technology choices is on your core network setup: how will the network be configured?

Shared decision criteria

For the setup of your network, there is a consistent set of decision criteria that can be used to evaluate your options regardless of the specific need being solved (RPC, oracle, indexer, etc.). These are outlined below:

• Cost: Upfront vs. ongoing, direct costs vs. costs to devs, fiat vs. token, scaling levers
• Performance: Throughput, latency, autoscaling capabilities, global replication
• Reliability: Uptime & availability, auditability & inspectability
• Sustainability: Maintainers are funded, profitable, long-term-oriented
• Guidance: 24/7 support, SLA guarantees, documentation, expertise
• Developer experience: End-user feedback, value-add functionality

In the sections that follow where I break down the various choices in your network setup, I'll summarize these six constant factors as CPRSGD, as they'll come up often.

Implementation path

You can either build and operate the core node infrastructure yourself, or partner with a RaaS (rollup-as-a-service) provider. The decision-making criteria here is a bit more generic, following the classic build vs. partner decision framework.

Advantages of building

1. Customization: You have complete control over the features and functionality of your chain. You can tailor it to your specific needs and preferences, without dependencies to an external service provider to ensure compatibility.
2. Lower cost at scale: You can potentially save on costs as you don't have to pay a RaaS provider. However, this doesn't account for the time + resources you'll need to invest instead.

Advantages of partnering

1. Ease of use: A service provider will handle the technical aspects of creating and maintaining the rollup. This can make the process much easier and more straightforward.
2. Support: You'll have access to professional support and resources, and a team that operates multiple chains (ergo, has expertise), which can be critical if you don't have it in-house.
3. Speed: A service provider can typically get your rollup up and running much faster than if you were to build it yourself, with suggested presets and integrations that simplify setup.
4. Focus: Partnering with a RaaS provider allows your team to focus more on core business activities and application development rather than the complexities of infrastructure management.

The lower upfront cost, complexity, and time investment offered by RAAS providers make them the de-facto standard for all but the largest companies (eg. Base, Immutable). A number of players have emerged in this category over the past few months:

• Alchemy
• Altlayer
• Caldera
• Conduit
• Gateway
• Gelato
• Lumoz
• Snapchain
• Vistara

When selecting a RaaS provider, there's a number of criteria to consider.

• CPRSGD
• Productization: Some RaaS providers have highly productized offerings and allow for self-serve deployments, customization, etc., while others follow a "managed services" model; the better fit depends on what your team needs and how you prefer to work
• Compatibility: Support for the framework for your choice can be a nonstarter - there are no RaaS options for Bitcoin L2's for the moment, nor for "alt-L1's in a box". In the Ethereum-scaling world, you may prefer one chain stack vs. another and not all RaaS support all frameworks. This applies not only at the framework level but for some of the downstream decisions you'll be making as well (eg. data availability).
• Experience: Most RaaS providers are relatively new, and even the largest are still learning - rapidly iterating on their offering, and running into new challenges as their earlier networks scale up. When deciding between providers, investigate their respective expertise with your framework specifically, and examine their other deployments (considering scale metrics such as TVL, reliability metrics such as uptime, etc.)
• Integrations: Building a blockchain is about more than just the nodes (the rest of this guide is about all of these other components). RaaS providers should have a core minimum set of integrations including a bridge and a block explorer. Beyond this minimum, RaaS providers may have native integrations or first-party support for other necessary infrastructure, simplifying the process of getting online while lowering costs. As you make other decisions in your network setup, consider which RaaS can integrate those selected elements easily.

Execution

The execution layer has historically been dictacted by the settlement layer and framework, but there's no technical reason these elements can't be decoupled: we could see SVM-based rollups that settle to Ethereum, and many other "frankenstein" mixes in the future. Options include:

• EVM: Most widely used, with extensive tooling, a large developer community. Limited by it's single-threaded nature.
• SVM: Designed for high throughput, low-latency use cases, with parallel transaction processing. Steeper learning curve.
• Move: Designed for safety in execution and resource management. Smaller ecosystem than others but growing rapidly, with major players such as Movement Labs and Fluent coming to market.
• CosmosWasm: Highly flexible, easy to integrate with other environments.
• zkVM: Provides enhanced privacy and scalable transaction verification. Typically more complex and costly to implement.
• CairoVM: High throughput, designed for narrower set of use cases. Relatively small but growing developer ecosystem.
• FuelVM: Modular execution layer designed for performance.

When selecting your execution environment, there's a number of factors to consider:

• CPRSGD
• UTXO vs. account-based model: In blockchain architecture, the two primary models for managing balances and recording transactions are the UTXO model and account-based model. Exploring the differences between them in detail is out of scope for this guide, but UTXO models lend themselves well to high security and traceability while account-based models enable (easier) smart contract functionality & development.
• Language support: Ensure the environment supports the programming languages your development team is proficient in (eg. Solidity for EVM, Rust for SVM). This can significantly impact development speed and security.
• Parallelization: Parallel transaction processing can vastly improve throughput and performance. Consider how well the execution environment supports parallel execution, and whether that's important to your intended userbase.
• Privacy: If privacy is a primary concern, environments like zkVM or CairoVM that integrate zero-knowledge proofs may be needed.

Data availability

Up until very recently, data availability was natively and integrally tied to the settlement layer (ie., OP Stack settling to Ethereum, etc.). However, alternative Data Availability (DA) layers have emerged that allow for off-(settlement-)chain data storage and validation, thereby enhancing scalability without compromising the security and integrity of the blockchain network.

A shortlist of these options below:

• Eigen DA
• Celestia
• Avail
• Espresso
• NEAR
• DACs (Data Availability Committees)

Factors to consider:

• CPRSGD
• Liveness: This overlaps substantially with "reliability" in CPRSGD, but is specifically important to DA so worth expanding on. Redundancies, the robustness and expertise of the P2P network, and their general performance history are all critical inputs in assessing liveness.
• Safety: How the DA layer is able to ensure that data stored and retrieved from the network is correct. The types of proofs generated (and thus the security they provide against attacks), how frequently they are generated and checked, and consistency guarantees differ between various options, and often come at a tradeoff to the other factors in the list.
• Decentralization: Beyond the crucial benefit of enhancing safety, decentralization of the DA layer is key for enhancing the trustworthiness of the network. A broad distribution of nodes and open governance models help enhance decentralization.
• Integration: Different DA systems have different levels of first-party support on various frameworks and RaaS providers. This is already mentioned there as 'Compatibility' but worth highlighting again here as it can be a non-starter for certain DA frameworks. Eventually I expect the playing field to generally level here (at least between Avail, Celestia, and Eigenlayer).
• Foundation support: The foundations building DA systems are all in the early stages, focused on acquiring networks to use their DA layers with a mix of incentives and support. These can be critical inputs into your decision when other minimum thresholds on the factor above are met, based on your team's specific needs.
• Simplicity: DA systems are often complex and introduce a new host of complexities to the chain's operations. Where the benefits of DA aren't immediately clear, it's worth considering a simple DAC (at the cost of trading off the other elements mentioned above).

Sequencer

Dev tooling

RPC

If you're working with a RaaS provider, your RPC needs at the onset are typically already solved for. However, over time you'll need to bring additional RPC nodes online for diversification / resilience. The major players to think about are some of the best-known names in crypto, but there's dozens if not hundreds of options:

• Alchemy
• Ankr
• Blast
• Chainstack
• Helius
• Infura
• Nirvana
• QuickNode
• Triton

I've chosen this shortlist as the names I've come acrss most often in conversations for hosted RPC node services, though there's many more. To evaluate your options, the boilerplate CPRSGD will play a huge role as there's not a huge amount of differentiation between node providers. That being said, those factors are broken down in a bit more detail specific to the RPC layer (and a few others added on) below:

• Cost: It's worth thinking about costs not just to yourself (boilerplate CPRSGD considerations there), but to your end developers as well, given that most RPC providers will also enter 1-on-1 agreements with projects on your network.
• Performance, Reliability: Most RPC node providers are hosted on the same cloud platforms as most of web2: AWS and GCP. As a result, they inherit the same underlying performance and reliability (and pass on the same costs), with the exception of a few players that have built their own cloud from scratch.
• Sustainability: Some RPC providers are underpinned by token-based business models where the end node operators are at least partially incentivized by token airdrops and other incentive programs that can't be sustained forever (or maybe they can?). When selecting an RPC vendor, you want to be conscious of the unit economics on the nodes they're running.
• Guidance: RPC providers are typically tightly involved in the design of the network and ongoing upgrades; you'll want to know that the vendors you select have successfully executed major protocol upgrades in the past and can work alongside the core protocol team effectively.
• Developer experience: Key builders on your network may have a preference for one RPC vendor over another; while the core functionality is broadly the same, some have invested in value-add functionality like notifications, webhooks, and custom API endpoints.
• Framework expertise: Different operators specialize on different frameworks (eg. Helius and Triton are focused on SVM, Nirvana on EVM, and some like Alchemy on both).
• Roadmap: Again, given the limited user-facing differentiation between different RPC vendors, you'll want to understand their roadmaps at least at a high-level and assess how it aligns to your own. Some RPC vendors such as Alchemy and Moralis are investing in premade APIs while others like Ankr are investing in gaming-specific SDKs.

Oracle

Oracles provide the critical function of providing external, offchain data to onchain applications. This external data can include anything from price feeds to weather information, and some oracle operators also provide VRF (verifiable random functions) to enable onchain randomness as well which is similarly critical to many blockchain apps (eg. unbiased NFT drops). Key players today include:

• API3
• Arpa
• Chainlink
• DIA
• Pyth
• RedStone
• Supra
• Switchboard

Key factors to consider:

• CPRSGD
• Push vs. pull: Oracles can be either push (eg. RedStone, Chainlink) or pull based (eg. Pyth), and they have different tradeoffs. Typically, push-based oracles are used in situations where prices don't need to be updated as frequently (eg. lending protocols), while pull-based oracles are used when prices need to be pushed on chain as often as possible (eg. perpetuals). Depending on the types of applications you're looking to onboard onto your network (and if they have any predispositions to a specific oracle provider), you can usually narrow down the options significantly.
• Accuracy: Different oracles have different methods for ensuring data accuracy, such as multi-source aggregation, cryptographic proofs, and validation mechanisms. Ensure the oracle's methodology aligns with your project's needs.
• Granularity: The level of granularity can be further broken down into refresh rate (ie. how often a given data feed is refreshed), sensitivity (ie. the thresholds that must be exceeded in order to trigger an on-chain refresh), and precision (ie. to how many decimals feeds report exchange rates and other data).
• Breadth: The number of "off the shelf" feeds that are available by integrating a given network. While additional breadth is always good, usage likely follows the pareto principle where a surprisingly small number of data feeds (my finger-to-the-wind guess is under 100) can cover 80%+ of developer needs.
• Security: Oracles can be a potential attack vector, so considering the security measures and network resilience an oracle provider has in place to protect against data tampering (and their track record in successfully doing so) are a key input.
• Customization: Some oracle solutions have a narrow band of customization and offer only plug-and-play solutions for specific blockchains or frameworks. Depending on the specific focus of your blockchain, you may need to create new types of oracles with customized parameters that may not be covered by standard fees, and different providers will have different levels of cost & complexity in enabling you.

Indexer

Indexers provide organized, queryable, decoded access to blockchain data, enabling devs to build applications efficiently. There are three main players in the indexing space:

• Alchemy
• Goldsky
• TheGraph

Key factors to consider:

• CPRSGD
• Scope: There are numerous approaches to indexing blockchain data: subgraphs (which most if not all indexers support) are well known but alternative approaches can also be used. Goldsky offers a streaming solution called Mirror, and Alchemy's own streaming solution, Pipelines, is currently in beta. Builders on your network may have a preference for/against different approaches to indexing (ETL vs. ELT) and on whether to host the data themsleves or not
• Completeness: In the case of an indexer, support for your network is only a piece of the story as builders continue to build more and more cross-chain applications. Checking that your indexer supports the other networks builders need access to ensures that you simplify their experience in building these more complex apps

Block explorer

Users on your network need a way to explore and make sense of what is happening on the network, a job for block explorers. Most RaaS providers offer Blockscout out of the box - list of other options to consider:

• Blockscout (for completeness)
• Dora
• Etherscan
• Otterscan
• Parsec
• Routescan
• 0xPPL
• 3xpl

The key question to ask when deciding which block explorers to bring to your network is "which types of users do I want to empower?". An off-the-shelf, "generic" explorer like Blockscout checks the box on common use cases for the general user:

• verify transaction details such as sender, recipient, amount, timestamp
• track the progress of transactions in realtime
• monitor network activity, mining performance, transaction volume, etc.
• view the current state of the chain, incl. latest blocks & transactions

Some other block explorers (eg. Etherscan, Routescan) are loosely solving the same need plus or minus a few APIs or features, albeit with some slight differentiation:

• Etherscan: Premium brand that historically projected "this chain is legit". This is being eroded over time and no longer commands the price premium it used to.
• Routescan: Focused on harmonized, cross-chain views. This is valuable for end users, and helps chains get discovered by users of other networks as well.

Meanwhile, there are a number of other explorers that are solving an entirely distinct user need:

• Dora: Contextualized and human-readable layer on top of raw onchain events. Targetting mass-market users for whom Blockscout/Etherscan/Routescan are too much.
• 3xpl: Offering advanced data APIs. Targetting builders, academics & researchers, and other power users for whom Blockscout/Etherscan/Routescan are not enough.
• Parsec: Offering advanced visualization tools, as well as highly custom, public dashboards for specific projects/events. Targetting users (and chains) looking for custom views.
• 0xPPL: Social explorer that allows for commenting and discussion. Targetting mass-market users who want to see what the people they care about are doing on chain.

Beyond CPRSGD, the key factor to consider is which users are critically important to keep happy, and which block explorer(s) are needed to make that happen.

Wallets

Wallets are critical infrastructure and the primary interface for end users to manage their assets and perform transactions. Wallets can be broadly categorized into three core types: user-facing wallets, embedded wallets, and account abstraction wallets. Each category has its unique use cases and features, with several high-quality players competing in the space.

Account abstraction

Account abstraction simplifies the user experience by abstracting away the complexities of managing private keys and executing transactions. This can involve features like meta-transactions, gasless transactions, social logins, passkeys, bundled transactions, and more.

Key players include:

• Biconomy
• Gelato
• Pimlico
• Safe
• ZeroDev

Embedded wallets

Embedded wallets - which can overlap with account abstraction to some degree - integrate directly into applications, providing builders with a seamless onboarding mechanism and giving end users a seamless and frictionless way to manage their assets without needing to leave apps.

Key players include:

• Dynamic
• Magic
• Privy

User-facing wallets

The title really says it all - these are the wallets you know and love and use. Key players that have a track record of supporting new networks:

• Coinbase Wallet
• Phantom
• Rainbow
• Rabby
• Zerion

APIs

Beyond these above categories, there's a significant number of other dev tools that can help bolster your ecosystem. This is an ever-expanding list as infrastructure investment in crypto continues to flow; some of the most frequent names listed down below:

• Noves
• SimpleHash

Defining a decision criteria for each of these beyond CPRSGD is out of scope for this guide, especially as these are typically "1-of-1" decisions that deeply rely on your chain's specific context.

Ecosystem

Once you've got a good core framework and tech stack together for your chain, the hard part begins - building a thriving, self-sustaining, and differentiated ecosystem of developers, applications, and users.

All three of these components to the ecosystem come together and feed off each other in a virtuous cycle: more users attract more developers, who build more applications, attracting more users, and the cycle continues. However, this also presents a cold-start problem: how do you get the flywheel going in the first place?

Anchor projects

The critical answer - anchor projects: legitimately distinctive and unique projects that are NOT found elsewhere. Apps that DRIVE users to your network because they can't experience the same product anywhere else. I've seen teams generally take a two-pronged approach to incubating such projects:

• Building them in-house: Teams typically build at least one if not several canonical apps themselves (in the case of appchains, these may be the ONLY apps on the network)
• Incentivizing and supporting devs: Whether via grants, technical support and internal resource augmentation, or fiat venture-style investment

Broader ecosystem

If you are building a general purpose chain as opposed to an appchain, you will need to stand up a standard "core ecosystem" of projects and functionality that users expect from any crypto ecosystem. This can be broken down into primary, secondary, and tertiary application categories.

Primary

• Bridges: enable interoperability between different networks, allowing users to transfer assets and data seamlessly to your chain. They make your chain more usable and accessible. Players include SuperBridge, Decent, Connext, Hyperlane, and more.
• DeFi: a broad category that could probably be broken down into many more, but the primary functionality to enable would be all of those available in traditional financial systems (lending, borrowing, trading, insurance) and then some (perps, yield farming). Players include Camelot, 0sum, and others.
• NFTs: Like DeFi, could probably be broken down into multiple categories but the two core functionalites to enable are the creation of NFTs (via launchpads such as Thirdweb, Zora, Manifold, etc.) and their exchange (via Opensea, tofuNFT, and other NFT marketplaces)
• Governance: allow stakeholders in the ecosystem to participate in decision-making processes regarding protocol upgrades, policy changes, and other important matters.

Secondary

• On/off ramps: facilitate the conversion from fiat currency to your networks tokens and vice versa. Users today are used to bridging from other networks, but on/off ramps can be considered "primary" application categories if you plan to bring brand new users to crypto, or generally have ambitious user acquisition goals. Options include Moonpay, Halliday, Ramp, Transak, and more.
• Stablecoins: tokens pegged to the value of a stable asset; in many cases wrapped / bridged versions of stablecoins on other networks will spring up organically; enabling native issuance from central stablecoin teams (ie. Tether and Circle) is incredibly difficult and has only been done by the largest chains in the space.
• Analytics: to inform their activity on your network, developers and builders seek analytics tooling that makes sense of the macro on the chain as well as allows for more sophisticated analysis of activity. Options include Dune, Flipside, Artemis, Token Terminal, Nansen, and more.
• Incentives: mechanisms to encourage user participation and growth, and get the flywheel kickstarted; can easily be a footgun if not leveraged properly. Designing and implementing effective points systems would be a whole separate blog post, for now I'll keep it to a list of options to explore: Galxe, JokeRace, Port3, Boost, QuestN, Layer3. It's worth highlighting that the biggest and most successful teams build and execute incentive programs in-house (eg. AnimeChain, Blast) in addition to leveraging off-the-shelf options.

Tertiary

For tertiary applications I don't have categories with multiple applications within each, but rather one-off projects that I've seen various chains integrate in the past:

• Gashawk
• EthSign
• Shutter
• Syndicate

Closing

If you've made it to this point, your head might be spinning with a mix of thoughts, some of which might be saying:

• "This is going to be EXPENSIVE."
• "There are a LOT of choices to make."
• "Just starting takes a million pieces."

After having seen dozens of teams go through this process: some succeeding and some failing, I'll try to leave you with 3 key takeaways - in response to the above and in general:

Takeaway #1: Be sure you want to do this.

Building a blockchain takes a LOT: of effort, time, and money - and that's just the cost of entry. To actually win and have a shot of building a self-sustaining (let alone profitable) blockchain network in the long-term is hard. Before starting on the journey, ask yourself why it's worth doing and if you have the resources necessary to win.

Takeaway #2: Go step-by-step.

Too often I've seen teams try to do everything all at once. I mentioned above that this can be expensive to get started and get the flywheel going: it might be even more expensive when you realize that a mature-state chain likely mas MULTIPLE providers in each dev tooling category, ecosystem category, etc. The good news is you don't need to incur those costs right away and can stage-gate your spend (time/effort/money). Focus first on proving demand for your differentiation, and that you have an edge, in the cheapest way possible. This can usually be an app on an existing chain or some other significantly smaller task than building an entire chain.

You can de-risk your bet to launch a chain, and then even take that launch step-by-step, onboarding only what is needed at each step of the way to unlock your next milestones.

Takeaway #3: Don't go alone.

Building a blockchain is a team effort. You'll of course have your core internal team and investors, but crypto is an incredibly collaborative community so be sure to take advantage of that. Especially as the nature of the problems you deal with evolve over time (from the zero-to-one guide outlined here, to longer-term considerations around scalability and reliability, progressive decentralization, etc.)

Outside support can come from advisors + experts, ecosystems + foundations, and/or simply your friends and family reminding you to touch grass once in a while.

For what it's worth, my DM's are open. I've seen teams build out blockchains from scratch and go on to build multi-million MAW networks and raise hundreds of millions of dollars, and I've also seen them go to zero in weeks. I've tried to document as much of my learning and framework here, but if you have questions or want to dive deeper into anything, don't hesitate to reach out.

---

Credits

This guide has been a heroic effort with significant contributions from many people donating time out of their very busy schedules to contribute their experience and expertise. Heartfelt thankyou's to...

• David @ Alpen
• Dominik @ BOB
• Matt @ Caldera
• Liz & 2pmflow @ Chiru
• Bunny @ Dora
• Ella @ Gelato
• Dan @ Nirvana
• Will @ Parsec
• Matt @ RedStone
• Jaack @ Routescan
• Ryan @ Xai

... and many others who have contributed to this guide over the past few weeks.