Release Candidate

The RC phase triggers the final round of security reviews and economic modeling. Key activities include:

• Fuzzing and formal verification of the new code.
• Economic stress tests to model validator incentives and slashing conditions.
• Bug bounty programs are often intensified, offering rewards for critical vulnerabilities discovered in the RC. This stage is the last line of defense against exploits that could threaten network security or user funds.

For decentralized networks, a Release Candidate serves as a tangible artifact for on-chain or off-chain governance signaling. Token holders or validators can signal readiness or approval by:

• Upgrading their nodes to the RC version on testnet.
• Participating in governance votes that reference the specific RC build.
• This creates a clear, auditable checkpoint for community consensus before irrevocable mainnet deployment.

Infrastructure providers and dApp developers use the RC period to ensure compatibility. This involves:

• Updating JSON-RPC API clients and libraries (e.g., ethers.js, web3.py).
• Testing indexers, oracles, and bridges with the new protocol rules.
• Deploying and testing smart contracts on the forked testnet to verify behavior changes (e.g., new opcodes, gas costs). This prevents service disruptions post-upgrade.

A Release Candidate (RC) is a version of software that is feature-complete and has passed initial quality assurance, deemed ready for final testing before a stable release. Its primary purpose is to serve as a final proving ground for security audits, performance testing, and community validation, minimizing the risk of critical bugs reaching production.

The RC phase is the last opportunity for security researchers and auditors to conduct penetration testing and vulnerability assessments on a near-final codebase. Discovering a critical vulnerability at this stage can prevent catastrophic exploits post-launch, such as reentrancy attacks, governance takeovers, or fund loss. It is standard practice to run a bug bounty program concurrently with the RC release.

Teams deploy the RC in a staging environment that mirrors mainnet conditions to test:

• Network upgrades and hard fork compatibility
• Node operator deployment scripts and configurations
• Monitoring and alerting systems under load
• Disaster recovery and rollback procedures This validates operational readiness and ensures a smooth, coordinated mainnet launch.

Understanding the deployment pipeline is key:

• Testnet: Used for early development and integration testing with valueless tokens.
• Release Candidate (RC): A candidate for mainnet, often deployed on a long-running testnet (e.g., Goerli, Sepolia) with final code, but still using test ETH.
• Mainnet: The live production blockchain where transactions have real economic value and consequences. An RC must pass all gates before promotion to mainnet.

A successful RC launch requires ecosystem-wide coordination. This includes:

• Wallet providers (e.g., MetaMask) updating support.
• Block explorers (e.g., Etherscan) indexing the new chain.
• Bridge and oracle operators deploying upgrades.
• DApp developers testing integrations. Clear communication channels and a defined release timeline are essential to synchronize these parties.

A Release Candidate is promoted to a stable release only after meeting strict exit criteria, which typically include:

• Zero critical or high-severity bugs open for a defined period.
• Successful completion of a final security audit round.
• Stress test results meeting performance benchmarks (e.g., TPS, finality time).
• Community consensus from core developers, client teams, and major stakeholders via governance processes.