Blockchain Mainnet Development: Components, Build Approaches, Genesis Launch, Security and Upgrades

What is blockchain mainnet development?

A mainnet is a blockchain's main public production network. On Ethereum, for example, it is where actual-value transactions are recorded on the distributed ledger [1]. Mainnet development is the engineering and operational work needed to get such a network from design to a live launch and to keep it running afterwards. Underneath, a blockchain is a tamper-evident, tamper-resistant digital ledger. It runs in a distributed way, usually without a central authority, so the protocol itself has to decide which participant publishes the next block [2]. Most of mainnet development deals with that problem and with the software, testing and coordination around it.

The term covers both new standalone blockchains (layer 1s) and chains built on top of other chains, such as rollups. It also covers the ongoing work after launch: coordinated software upgrades, security response and client maintenance.

Mainnet vs testnet vs private networks

Development normally moves through several network types before and after a mainnet goes live. Ethereum's developer documentation groups them like this [1]:

Network type	Purpose	Ethereum example
Mainnet	Production network with real-value transactions	Ethereum Mainnet
Public testnet (applications)	Testing smart contracts and applications in a production-like setting	Sepolia, the recommended default testnet for application development
Public testnet (staking/protocol)	Testing validator operations and protocol upgrades before mainnet	Hoodi, which has an open validator set
Ephemeral testnet	Short-term testing on a chain that resets regularly	Ephemery, which resets every month
Development network	Local chain run by a single developer	Local client instances
Consortium network	Chain run by a predefined set of trusted nodes	Permissioned deployments

Testnets are retired as well as launched. Ethereum's Holesky testnet was deprecated as of September 2025, and staking operators were directed to Hoodi [1][11].

Core components of a mainnet

Consensus model: the rule for choosing who publishes blocks. NIST's overview covers proof of work, proof of stake, round robin, proof of authority and other models, each with trade-offs for different use cases [2].
State machine and transaction logic: the rules for how transactions change the ledger's state, including accounts, fees and any smart contract execution.
Node and validator software (clients): the programs that peers run to relay, validate and produce blocks.
Genesis configuration: the initial state and parameters that every node must share (see below).
Token economics and initial allocation: balances assigned at genesis and the rules for issuing and spending the native asset.
Ecosystem tooling: wallets, block explorers, remote procedure call (RPC) endpoints and bridges that let users and applications reach the chain.
Governance and upgrade process: how rule changes are proposed, agreed and put into effect.

Build approaches: fork a client, use a framework, deploy a rollup, or build new

How much a team has to build depends on which approach it chooses. The main options are:

Approach	What the team does	Documented example	Main trade-off
Fork or configure an existing client	Runs an existing client with its own genesis file, chain ID and consensus settings	Geth private networks set `chainId`, fork activation blocks, initial allocations and consensus parameters in `genesis.json` [7]	Proven code and compatible tooling, but the team inherits the upstream design and must track upstream fixes
Application-specific chain from a framework	Combines ready-made modules with custom business logic on top of a consensus engine	Cosmos SDK chains that run business logic at the protocol level with the CometBFT consensus engine [5][6]	More control over fees, governance and execution, but more operational work than deploying a smart contract [5]
Rollup / layer-2 stack	Deploys contracts on a base layer and runs sequencer, batcher, proposer and node software	OP Stack chain operator configuration [8]	Relies on the base layer for data availability and settlement. Many parameters cannot be changed after deployment [8]
New protocol	Designs and implements consensus, networking and execution from scratch	Ethereum's original clients. Its first code commit came about 18 months before launch [3]	The most design freedom, but also the highest engineering, audit and coordination cost

CometBFT describes itself as providing "the equivalent of a web server, database, and supporting libraries" for blockchain applications. It performs Byzantine fault-tolerant state machine replication for deterministic applications [6]. Frameworks like this let a team concentrate on application logic instead of writing consensus from scratch.

Typical development lifecycle

Requirements and protocol design: choose the consensus model, permissioning, block parameters, fee model and token economics.
Client implementation or configuration: write, fork or configure the node and validator software.
Local and development networks: run single-machine or small multi-node networks for functional testing [1].
Security review: run internal testing, external audits and, often, a public bug bounty.
Public testnet: let outside validators, wallets and applications practise under production-like conditions [1].
Genesis preparation: finalise the genesis file, initial validators and allocations, and publish the client releases.
Mainnet launch: nodes start from the shared genesis state and begin producing blocks.
Operations and upgrades: monitor the network, respond to incidents, and schedule hard forks through testnets.

Genesis launch

The genesis block defines a chain's starting state. In Geth-based networks, genesis.json sets the chain ID, the block numbers at which protocol features turn on, the initial balances (alloc), the block gas limit and the consensus-specific fields. Every node joining the network must use the same genesis configuration [7]. A network ID that no other network uses means the nodes can only connect to each other [7]. For OP Stack chains, the deployment configuration "defines the behavior of your network at its genesis". Operators are warned that many of these values cannot be changed after deployment, or can only be changed through a complex process [8].

Ethereum's mainnet went live on 30 July 2015, when participants generated and loaded the genesis block of Frontier, the first live release [3]. Its proof-of-stake Beacon Chain had a separate genesis on 1 December 2020 (epoch 0) [4].

Security: audits, bug bounties and client diversity

Mainnet security goes beyond auditing code before launch. Three practices appear in Ethereum's public documentation:

Bug bounty programmes: Ethereum's programme covers the execution clients (Besu, Erigon, Geth, Nethermind, Reth), the consensus clients (Grandine, Lighthouse, Lodestar, Nimbus, Prysm, Teku), the Solidity and Vyper compilers, the Beacon Chain specifications and the deposit contract. Critical findings can earn up to US$1,000,000, and every submission must include proof-of-concept code [10].
Client diversity: running several independent client implementations limits the damage a single bug can do. According to ethereum.org, a bug in a consensus client used by more than 33% of nodes could stop the chain from finalising. A client with a two-thirds majority could cause the chain to split and finalise incorrectly [9].
Historical evidence: in the 2016 Shanghai denial-of-service attacks, attackers exploited the dominant client, Geth. The network kept running because alternative clients did not share the vulnerability [9].

Teams that launch with only one client take on this concentration risk from the start. This is common when a team forks a single codebase.

Network upgrades after launch

A mainnet's rules change through forks. On Ethereum, a network upgrade requires clients to ship updated software. Validators and nodes must then produce and check blocks under the new rules. Upgrades usually start as Ethereum Improvement Proposals (EIPs) and are agreed in advance so that all clients switch at the same time [4]. Selected upgrades:

Upgrade	Date	Activation point
Frontier (genesis)	30 Jul 2015	Genesis block
Homestead	14 Mar 2016	Block 1,150,000
DAO fork	20 Jul 2016	Block 1,920,000
Beacon Chain genesis	1 Dec 2020	Epoch 0
Paris (The Merge)	15 Sep 2022	Block 15,537,394
Dencun	13 Mar 2024	Block 19,426,587
Pectra	7 May 2025	Block 22,431,084
Fusaka	3 Dec 2025	Block 23,935,694

Source for table: [4].

Testnet rehearsals can catch problems before they reach mainnet. When Pectra went live on the Holesky and Sepolia testnets in early 2025, it exposed client problems with deposit contract configuration. Sepolia recovered, but Holesky went through extensive inactivity leaks. Exited validators on Holesky would have taken about a year to leave the validator set, so developers launched a new testnet, Hoodi. Pectra activated on Hoodi on 26 March 2025, before the mainnet activation [11][4].

Evaluating a mainnet development project or service

Whether a team builds its own chain or hires a development service, these questions help check the plan:

Which consensus model is used, and what are its fault-tolerance assumptions [2]?
Is the chain a fork, a framework-based chain, a rollup or a new protocol? Who maintains the upstream code?
How many independent client implementations exist [9]?
Which genesis and deployment parameters are permanent once the chain launches [8]?
Is there a public testnet, and has the upgrade process been rehearsed on it [11]?
Are audit reports and a bug bounty publicly available [10]?
Is there a documented process for proposing and activating upgrades [4]?

Limitations and considerations

The sources used here mostly describe Ethereum and Ethereum-compatible or Cosmos-based stacks. Other ecosystems use different terms and processes. Launching a chain with a native token can also raise legal and regulatory questions that depend on the jurisdiction; those are outside the scope of this page. Client market-share figures change often, so check live dashboards rather than fixed numbers.