The Avalanche Foundation is collaborating with Chorus One to further expand validator infrastructure on the African continent. This step reflects a shared commitment to advancing global decentralization, strengthening geographic diversity, and supporting the long-term resilience of the Avalanche network.

Expanding Avalanche’s Global Footprint

Chorus One has been a trusted partner within the Proof-of-Stake ecosystem and an early supporter of Avalanche since mainnet launch. Together, we are now further extending Avalanche's validator presence to Africa - helping bring the network closer to developers, users, and institutions on the continent.

Why It Matters

• Greater Resilience
  
  Geographic and infrastructure diversity helps strengthen network reliability and reduces concentration risk.
  
  
• Global Representation
  
  Africa’s growing developer and blockchain ecosystem represents an important community for Avalanche’s ongoing growth and participation in on-chain governance.
  
  
• Institutional-Grade Infrastructure
  
  Chorus One operates high-availability validators across dozens of networks, providing a professional and secure foundation for Avalanche’s continued decentralization.
  
  

A Shared Commitment

The Avalanche Foundation’s focus on community growth and network accessibility aligns with Chorus One’s mission of transparency, performance, and inclusion. This collaboration reflects our mutual goal: ensuring that Avalanche remains a resilient, decentralized, and globally distributed network.

Looking Ahead

The Foundation will continue to work with ecosystem partners like Chorus One to encourage regional participation, broaden community access, and expand developer infrastructure.

To learn more about Chorus One’s Avalanche staking services, visit chorus.one/networks/avalanche.

We would like to thank Keone and the entire Monad team for their valuable discussions and insightful feedback.

Introduction

The Monad blockchain is designed to tackle the scalability and performance limitations of existing systems like Ethereum. It maximizes throughput and efficiency while preserving decentralization and security. Its architecture is composed of different integrated components: the Monad Client, which handles consensus and execution. MonadBFT, a consensus mechanism derived from HotStuff. The Execution Model, which leverages parallelism and speculative execution, and finally MonadDB, a state database purpose-built for Monad. Additional innovations such as RaptorCast and a local mempool design further enhance performance and reliability. Together, these elements position Monad as a next-generation blockchain capable of supporting decentralized EVM applications with low latency and strong guarantees of safety and liveness. Below, we'll provide a technical overview of the Monad architecture, which consists of the Monad Client, MonadBFT, the execution model, and monadDB.

Monad Architecture Overview

The Monad Client:

The Monad architecture is built around a modular node design that orchestrates transaction processing, consensus, state management, and networking. Validators run the Monad Client, a software with a part written in Rust (for consensus) and C/C++ (for execution) to optimize performance. Similar to Ethereum, the Monad client is split into two layers:

• Consensus Layer: Establishes transaction ordering and ensures network-wide agreement using MonadBFT, a fast Byzantine Fault Tolerant (BFT) protocol achieving ~800ms finality.
• Execution Layer: Verifies and executes transactions, updating the blockchain state in parallel for efficiency.

‍

Consensus: MonadBFT

MonadBFT is a modern BFT consensus mechanism from the HotStuff family. It combines the below properties:

• Pipelined consensus (enables low block times - 400 ms)
• Resistance to tail forks
• Linear communication complexity (enables a larger, more decentralized network)
• Two-round finality
• One-round speculative finality (speculative, but very unlikely to revert)

1. Pipelined Structure

Traditional HotStuff requires 3 phases to finalize a block, each happening one after the other:

1. Proposal: The leader (or proposer) creates a block proposal with transaction data and sends it to all validators.
2. Voting: Validators evaluate the block and return a signed vote (accept/reject the block).
3. Certification: The leader aggregates the votes. If at least two-thirds of validators sign off, their signatures are bundled into a Quorum Certificate (QC), which serves as cryptographic proof that a supermajority (≥2/3) has agreed to the block.

This sequential process delays block finalization. MonadBFT only requires 2 phases, which makes finality faster, but also, it uses a pipelined approach, overlapping phases: when block k is proposed, block k–1 is voted on, and block k–2 is finalized simultaneously. This parallelism reduces latency.

On Monad, at any round, validators propose a new block, vote on the previous, and finalize the one before that.

Comparison: HotStuff vs MonadBFT

The Monad documentation includes a clear infographic illustrating MonadBFT’s pipelined approach, showing how each round overlaps proposal, voting, and finalization to achieve sub-second finality.

2. Tail-fork resistance

Although pipelining increases block frequency and lowers latency, it comes with a big problem that previously hadn’t been addressed by any pipelined consensus algorithms. That problem is tail-forking.

Tail-forking is best explained with an example. Suppose the next few leaders are Alice, Bob, and Charlie. In pipelined consensus, as mentioned before, second-stage communication about Alice's block piggybacks on top of Bob's proposal for a new block.

Historically, this meant that if Bob missed or mistimed his chance to produce a block, Alice's proposal would also not end up going through; it would be "tail-forked" out and the next validator would rewrite the history Alice was trying to propose. 

MonadBFT has tail-fork resistance because of a sophisticated fallback plan in the event of a missed round. Briefly: when a round is missed, the network collaborates to communicate enough information about what was previously seen to ensure that Alice's original proposal ultimately gets restored. For more details, see this blog post explaining the problem and the solution.

3. The Leader Election

MonadBFT employs a stake-weighted, deterministic leader schedule within fixed 50,000-block epochs (~5.5 hours) to ensure fairness and predictability:

• Stake-Weighted Determinism: At epoch start, validator stake weights are locked. Each validator uses a cryptographic random function to generate an identical leader schedule, assigning slots proportional to stake (a validator with 3% stake gets 3% of slots). The leader changes with every new block, and all validators know exactly who the leader is for each slot across the entire epoch.
• Security and Liveness: If a leader fails to propose a block within ~0.4s, validators broadcast signed timeout messages. When ≥2/3 stake submits timeouts, these form a Timeout Certificate (TC), sent to the next leader. The new leader includes the TC in its proposal, signaling the failure and ensuring chain continuity with the highest known block.

4. Linear Communication

Unlike older BFT protocols with quadratic (O(n²)) message complexity, MonadBFT scales linearly (O(n)). Validators send a fixed number of messages per round to the current or next leader, reducing bandwidth and CPU costs. This enables 100–200+ validators to operate on modest hardware and with modest network bandwidth limits without network overload.

5. Fault Tolerance

MonadBFT tolerates up to 1/3 of validator stake being offline while retaining liveness, and up to 2/3 of validator stake being malicious while retaining safety (no invalid state transitions).

6. Block Propagation with RaptorCast

To support fast consensus, Monad uses RaptorCast for efficient block propagation. Instead of broadcasting entire blocks, RaptorCast splits blocks into erasure-coded chunks distributed via a two-level broadcast tree:

• The leader sends each chunk to one validator (level 1 nodes), who forwards that chunk to all others (level 2 nodes).
• Validators can reconstruct blocks from any subset of chunks of size roughly matching the original block. Extra chunks ensure resilience against loss or faulty nodes.
• This distribution results in both low latency (two hops per chunk) and low bandwidth utilization, unlike slower gossip protocols.

If a validator lags, it syncs missing blocks from peers, updating its state via MonadDB (see State Management section below). With consensus efficiently establishing transaction order, Monad's execution model builds on this foundation to process those transactions at high speed.

‍

Execution Model

Monad’s execution model overcomes Ethereum’s single-threaded limitation (10–30 TPS) by leveraging modern multi-core CPUs for parallel and speculative transaction processing, as enabled by the decoupled consensus described above.

1. Asynchronous Execution

After consensus, transactions are executed asynchronously during the 0.4 s block window. This decoupling allows consensus to proceed without waiting for execution, maximizing CPU utilization.

2. Optimistic Parallel Execution

With Optimistic Parallel Execution, Monad tries to speed up blockchain transaction processing by running transactions at the same time (in parallel) whenever possible, rather than one by one. Here’s a simple explanation of how it works:

1. Run Everything in Parallel First:

Monad executes all transactions in a block simultaneously, assuming no conflicts, and creates a PendingResult for each, recording the inputs (state read, like pre-transaction account balances) and outputs (new state, like updated balances).

2. Check and Commit Results One by One:

After the parallel execution, Monad checks each PendingResult in order (serially). 

• If a transaction’s inputs are still valid (they match the current blockchain state), Monad applies the outputs to update the blockchain.

• If the inputs are invalid (because another transaction changed the state), Monad re-executes that transaction with the updated state to get the correct result.

This saves time because many transactions don’t conflict, so running them in parallel is faster. Even when transactions conflict (for example: two transfers from the same account), Monad only re-executes the ones that fail the input check, which is usually fast because the data is already in memory.

Here’s a simple example with 4 transactions in a block:

• Tom swaps USDC for MON on Uniswap Pool A: This modifies the state of Uniswap Pool A (USDC and MON balances in the pool) and Tom’s balances (decreases USDC, increases MON).
• Jordan mints an NFT: This interacts with an NFT contract, creating a new token and assigning it to Jordan.
• Alice transfers MON to Eve: This decreases Alice’s MON balance and increases Eve’s MON balance.
• Paul swaps USDC for MON also on Uniswap Pool A: This also modifies Uniswap Pool A’s state and Paul’s balances (decreases USDC, increases MON). 

‍

How Monad Processes These Transactions

Monad assumes all transactions can run simultaneously and corrects conflicts afterward: 

Step 1: Parallel Execution

Monad executes all 4 transactions at the same time, assuming the initial blockchain state is consistent for each. It produces a PendingResult for each transaction, recording:

• The Inputs: The state read (Uniswap Pool A’s balances, Alice’s MON balance, etc).
• The Outputs: The new state after the transaction (updated pool balances, updated account balances, etc).

For example:

• Tom’s swap: Reads Pool A’s current USDC and MON balances, calculates the swap ( Tom sends 100 USDC, receives X MON based on the pool’s pricing), and outputs new pool balances and Tom’s updated balances.
• Jordan’s NFT mint: Reads the NFT contract’s state, creates a new token, and outputs the updated NFT contract state and Jordan’s ownership.
• Alice’s transfer: Reads Alice’s MON balance, subtracts the transfer amount, adds it to Eve’s balance, and outputs the new balances.
• Paul’s swap: Reads Pool A’s current balances (same as Tom’s initial read), calculates the swap, and outputs new pool balances and Paul’s updated balances.

Step 2: Serial Commitment

Monad commits the PendingResult one by one in the order they appear in the block (Tom, Jordan, Alice, Paul). It checks if each transaction’s inputs still match the current blockchain state. If they do, the outputs are applied. If not, the transaction is re-executed.

Let’s walk through the commitment process:

1. Tom’s swap (Transaction 0):
   
   • Monad checks the PendingResult. The inputs (Pool A’s initial USDC and MON balances) match the blockchain’s current state because no prior transaction has modified Pool A.
   • Monad commits the outputs: Pool A’s USDC balance increases (from Tom’s USDC), MON balance decreases (Tom receives MON), and Tom’s balances update (less USDC, more MON).

New state: Pool A’s balances are updated, Tom’s balances are updated.

2. Jordan’s NFT mint (Transaction 1):
   
   • The inputs (NFT contract state) are unaffected by Tom’s swap, so they match the current state.
   • Monad commits the outputs: A new NFT is created, and Jordan is recorded as its owner.

New state: NFT contract state is updated, Jordan owns the new NFT.

3. Alice’s transfer (Transaction 2):
   
   • The inputs (Alice’s MON balance) are unaffected by Tom’s swap or Jordan’s mint, so they match the current state.
   • Monad commits the outputs: Alice’s MON balance decreases, Eve’s MON balance increases.

New state: Alice and Eve’s MON balances are updated.

4. Paul’s swap (Transaction 3):
   
   • The inputs (Pool A’s USDC and MON balances) were based on the initial state, but Tom’s swap (committed in step 1) changed Pool A’s balances.
   • Since the inputs no longer match the current state, Monad re-executes Paul’s swap using the updated Pool A state (post-Tom’s swap).
   • Re-execution calculates the swap with the new pool balances, producing updated outputs: Pool A’s USDC balance increases further, MON balance decreases further, and Paul’s balances update (less USDC, more MON).

New state: Pool A’s balances are updated again, Paul’s balances are updated.

Step 3: Final State

After committing all transactions, the blockchain reflects:

• Uniswap Pool A: Updated balances reflecting Tom’s and Paul’s swaps (more USDC, less MON).
• Tom: Less USDC, more MON based on his swap.
• Jordan: Owns a newly minted NFT.
• Alice: Less MON after transferring to Eve.
• Eve: More MON from Alice’s transfer.
• Paul: Less USDC, more MON based on his swap (calculated with the updated pool state).

3. Speculative Execution

Monad enhances speed via speculative execution, where nodes process transactions in a proposed block before full consensus:

• Consensus orders transactions: Validators collectively decide on the exact list and order of transactions in each block. This ordering is secured through the MonadBFT consensus protocol.
• Delayed State Update: Nodes receive the ordered list but delay final state commitment.
• Speculative Execution: Transactions are executed immediately on a speculative basis.
• State Commitment: State updates are committed after two consensus rounds (~800ms), once the block is finalized.
• Rollback if Needed: If the block proposal ends up not being finalized, speculative results are discarded, and nodes revert to the last finalized state.

In summary, Optimistic Parallel Execution is about how transactions get processed (running many in parallel to speed up the process) while Speculative Execution handles when processing begins, starting right after a block is proposed but before full network confirmation. This parallel and speculative processing relies heavily on efficient state management, which is handled by MonadDB.

‍

State Management: MonadDB

MonadDB improves blockchain performance by natively implementing a Merkle Patricia Trie (MPT) for state storage, unlike Ethereum and other blockchains that layer the MPT on slower, generic databases like LevelDB. This custom design reduces disk access, speeds up reads and writes, and supports concurrent data requests, enabling Monad’s parallel transaction processing. For new nodes, MonadDB uses statesync to download recent state snapshots, avoiding the need to replay all transactions. These features make Monad fast, decentralized, and compatible with existing systems.

Key Features

• Native Merkle Patricia Trie: MonadDB stores blockchain state (such as accounts, balances) in an MPT built directly into its custom database, eliminating overhead from generic databases. This reduces delays, minimizes disk I/O, and supports multiple simultaneous data requests, improving efficiency.
• Fewer Disk Reads for Speed: By leveraging in-memory caching and optimized data layouts, MonadDB minimizes SSD access, speeding up transaction processing and state queries like account balance checks.
• Handling Multiple Data Requests at Once: MonadDB handles multiple state queries at once, supporting Monad’s parallel execution model and ensuring scalability under high transaction volumes.

Role in Execution

MonadDB integrates with Monad’s execution model:

• Block Proposal and Consensus: Validators propose blocks with a fixed transaction order, which MonadBFT confirms without updating the blockchain state.
• Parallel Execution: After consensus, transactions are executed in parallel, with MonadDB handling state reads and tentative writes.
• Serial Commitment: Transactions are committed one-by-one in the confirmed order. If a transaction’s read state is altered by an earlier transaction, it is re-executed to resolve the conflict.
• State Finalization: Once a block is finalized, state changes are saved to MonadDB’s native Merkle Patricia Trie, creating a new Merkle root for data integrity.
• Speculative Execution: MonadDB allows nodes to process transactions before final consensus, discarding any changes if the block isn’t finalized to ensure accuracy.

Node Synchronization and Trust Trade-Off

MonadDB enables rapid node synchronization by downloading the current state trie, similar to how git fetch updates a repository without replaying full commit history. The state is verified against the on-chain Merkle root, ensuring integrity. However there is an important trust trade-off:

• Instead of independently verifying every transaction and block from the beginning of the blockchain, this approach relies on a trusted source (like a reputable peer, snapshot provider, or archive node) to supply the latest state. The downloaded state can be cryptographically verified against the on-chain Merkle root, ensuring its integrity.
• This method relies on the rest of the network to have validated the state transitions correctly up to this point. If an invalid or malicious transaction was ever accepted by the network, you would not detect it without replaying and verifying the entire transaction history yourself. This trade-off offers faster syncing at the cost of partial reliance on external trust.

Monad transparently addresses this trade-off:

• The team acknowledges that efficient state sync is a necessity for a fast, operable network (just as many blockchains, including Ethereum and Solana, offer state snapshots for speed).
• At the same time, they make clear that if you want to verify every single transaction and the integrity of the full ledger, you would need to sync from genesis and replay every block locally, which is slower but equivalent to traditional “trustless” node operation.

‍

Transaction Management and Networking

Monad optimizes transaction submission and propagation to minimize latency and congestion, complementing MonadBFT and RaptorCast.

Localized Mempools

Unlike global mempools, Monad uses local mempools for efficiency:

• Users submit transactions to an RPC node, which validates and forwards them to the next few scheduled MonadBFT leaders.
• Each leader maintains a local mempool, and selects transactions by prioritizing those with higher gas fees, and includes them in the block proposal.
• If a transaction isn’t included within a few blocks, the RPC node resends it to new leaders.
• Once a block is proposed, RaptorCast broadcasts it to validators, who vote via MonadBFT and execute transactions (often speculatively).

This targeted forwarding reduces network congestion, ensuring fast and reliable transaction inclusion.

‍

Conclusion

Overall, Monad's architecture demonstrates how a blockchain can achieve high performance without sacrificing safety. By using MonadBFT, parallel execution, and an optimized database, Monad speeds up block finalization and transaction processing while keeping results deterministic and consistent. Features like RaptorCast networking and local mempools further cut down latency and network overhead. There are trade-offs, especially around fast syncing and trust assumptions, but Monad is clear about them and offers flexible options for node operators. Taken together, these choices make Monad a strong foundation for building decentralized EVM applications, delivering the low latency and strong guarantees promised in its design.

‍

Ethereum staking continues to mature, and institutions with significant ETH holdings are increasingly looking for secure and yield-competitive strategies. At Chorus One, we are building solutions that combine simplicity, flexibility, and performance – allowing our clients to participate in Ethereum’s DeFi ecosystem without added complexity.

Our latest staking product leverages Lido stVaults to deliver two complementary strategies:

• Vanilla staking: a straightforward ETH staking experience tailored for institutions seeking reliable yield.
• Looped staking: a strategy that compounds rewards by re-deploying staked ETH into lending and borrowing protocols, thereby maximizing yield potential while maintaining access to liquidity.

This dual approach positions Chorus One to better meet the diverse needs of institutional clients – whether they value simplicity, capital efficiency, or higher returns.

Why stVaults and stETH?

Several factors make stVaults and stETH a natural fit for our institutional staking product:

• Strategic alignment with Lido: As an early Lido Node Operator and DAO contributor, Chorus One has deep familiarity with the protocol and its governance.
• Risk-aware infrastructure: stVaults are designed with robust safeguards, making them well-suited for institutions with high security requirements.
• Liquidity advantage of stETH: stETH is one of the most liquid staking derivatives in the market. Its use of ETH-based liquidation oracles on lending platforms reduces the risk of premature liquidations during market volatility, making it particularly effective for looped staking.
• Full autonomy over vaults: Chorus One can now design, deploy, and manage vaults end-to-end, ensuring tighter control over product design, client relationships, and revenue flow.

Security remains foundational to our approach. We are actively testing vanilla and looped staking strategies on testnets to validate reliability, scalability, and client safety.

If custom smart contract development is required, we will follow strict transparency standards by publishing fully public audits. Institutions can also review our broader security framework in our Chorus One Handbook and security documentation.

What Institutions Can Expect

By integrating stVaults into our staking product suite, Chorus One is unlocking several benefits for institutions:

• Optimized rewards: competitive yield strategies that balance security, liquidity, and capital efficiency.
• Operational flexibility: faster product iterations and the ability to adapt strategies as markets evolve.
• Direct client alignment: institutions can now work exclusively with Chorus One, reducing reliance on multiple operators.
• Scalability: a foundation for both vanilla and advanced strategies, with optional curator partnerships for more complex vault designs.

The launch of stVault-based staking products marks a significant step forward in Chorus One’s institutional offering. By combining the liquidity of stETH with the flexibility of stVaults, we are empowering institutions to access yield opportunities that are both secure and scalable, without unnecessary dependencies.

At Chorus One, we believe the future of ETH staking lies in making institutional participation seamless, capital-efficient, and reward-optimized. stVaults are a key part of that vision.

Chorus One is excited to announce that our validator is live in the active set on Hyperliquid, enabling HYPE staking in partnership with FalconX, a leading institutional digital asset prime broker. This collaboration combines FalconX’s deep liquidity and institutional reach with Chorus One’s proven Proof-of-Stake expertise—making it easier than ever for institutional investors to participate in the growth of the Hyperliquid ecosystem. 

A New Standard for On-Chain Finance

Hyperliquid is an EVM-compatible Layer-1 blockchain powered by the HyperBFT consensus mechanism. The network is designed for performance, supporting on-chain trading and applications with the security and reliability expected from institutional-grade infrastructure. 

The native token, $HYPE, underpins the staking economy. Holders can delegate without minimum or maximum limits and currently earn an annualized staking reward of approximately 2.10%–2.30%, distributed daily with automatic compounding. For transparency, all network activity can be tracked through the Hypurrscan block explorer. The chain introduces two major architectural innovations:

• HyperCore – at the heart of the network is a fully on-chain order book that rivals centralized exchanges (CEXs) in speed and efficiency—while retaining decentralization and transparency. Hypercore is an on-chain trading engine processing up to 200,000 orders per second with single-block settlement.
• HyperEVM – an EVM-compatible environment for smart contract deployment.

By joining the validator set, Chorus One brings years of staking expertise to support Hyperliquid’s vision of building the future of on-chain finance. Together with FalconX, we’re extending secure and institutional-grade access to HYPE staking from day one.

HYPE and Chorus One

Partnering with FalconX ensures institutional clients gain direct access to staking through a platform trusted by some of the world’s largest financial players. With FalconX’s custody integrations and liquidity services, institutions can easily engage with Hyperliquid staking in a secure, compliant, and capital-efficient way.

Chorus One supports institutions through HYPE staking to our public validator, support for White Label validators, HYPE rewards reporting suite and access to our research team's deep expertise on the Hyperliquid ecosystem, including the HIP-3 Standard which allows for the creation of custom perpetual contract markets.

Contact staking@chorus.one or custody@falconx.io for more information on how to stake.

We’re also collaborating with projects building on Hyperliquid, such as leading liquid staking protocols Kinetiq and Hyperbeat, further embedding ourselves in the ecosystem’s long-term growth.

Looking Ahead

Hyperliquid is redefining on-chain finance by merging the efficiency of centralized platforms with the openness and transparency of blockchain. With Chorus One and FalconX, HYPE staking is now accessible to both retail and institutional users who want to secure the network while earning consistent rewards.

Get started today with Chorus One and FalconX to join the next era of decentralized finance.

‍

We’re thrilled to congratulate Autonity on its mainnet launch, a major step forward in the evolution of decentralized finance infrastructure. As one of the earliest institutional supporters of Autonity, Chorus One is proud to back this groundbreaking Layer 1 blockchain through both strategic investment and hands-on validator participation.

Autonity is not just another EVM-compatible chain. It’s the first Layer 1 purpose-built for decentralized derivatives clearing, introducing an entirely new design space for programmable risk transfer. Developed by Clearmatics, a pioneer in the application of blockchain to financial instruments, Autonity represents a bold vision: building infrastructure that expands the universe of tradable risk far beyond the narrow boundaries of crypto speculation.

A New Kind of Network Purpose-Built from the Ground Up

At its core, Autonity addresses a fundamental gap in today’s DeFi landscape: the lack of robust infrastructure for derivatives that can track real-world risks — from macroeconomic indicators like inflation to environmental metrics like global temperatures. Traditional finance fails to offer instruments for many of these exposures, while current DeFi platforms are mostly confined to crypto-native assets, plagued by liquidity fragmentation and inefficiencies.

Autonity’s solution is elegant and deeply considered. By decoupling trading venues from the clearing layer via its Autonomous Futures Protocol (AFP), Autonity creates a unified, permissionless clearinghouse for diverse risk markets. Its architecture allows forecast contracts — a new class of fully on-chain derivatives that follow public time series data — to be created, traded, and settled efficiently, opening doors for innovation in quant finance, machine learning, and institutional risk hedging.

Autonity features:

• EVM compatibility with 1-second block times and Tendermint BFT consensus;
• A delegated proof-of-stake system capped at 100 validators;
• A dual-token design with:
  
  • ATN for on-chain derivatives collateral;
  • NTN for securing the network via staking;
  • LNTN, a liquid staking representation to maximize capital efficiency.
• Robust oracle infrastructure, with native validator-powered price feeds;
• Built-in accountability protocols to enhance data integrity and trust.

These primitives work together to provide a flexible, secure, and scalable foundation for derivative instruments that can hedge or speculate on almost anything — not just tokens, but real-world metrics.

Chorus One’s Role in the Journey

We’ve been closely involved with Autonity’s development from its earliest stages. As a strategic validator partner, Chorus One participated in over six testnets, helping to validate network performance, test slashing mechanisms, and refine the protocol’s consensus and oracle systems.

Autonity is also a Chorus One Ventures portfolio company. We believe that enabling programmable, decentralized markets for any measurable risk factor is not only the next step in the evolution of DeFi, but also a fundamental leap forward in how we structure global financial systems.

From concept to code to mainnet, the Autonity team has executed with precision, vision, and purpose. As investors and infrastructure partners, we at Chorus One are honored to have supported this journey, and we’re incredibly excited to see what comes next.

Enabling staking on Cosmos has never been easier for institutions. At Chorus One, we’re committed to making staking accessible, secure, and developer-friendly, whether you’re building a dApp, integrating staking into a wallet, or simply looking to support your favourite Cosmos protocol. Our lightweight yet secure SDK empowers you to enable staking across all supported Cosmos SDK-based protocols with less than 10 lines of code. It also underpins Chorus One’s staking dApps for ATOM, TIA, DYDX and more. 

‍

Why Cosmos and the Cosmos SDK?

The Cosmos network is celebrated for its interoperability and modular architecture, powered by the Tendermint BFT consensus engine. This foundation allows independent blockchains to communicate and share data seamlessly, all while maintaining their autonomy. Staking is at the heart of Cosmos, securing the network and rewarding those who participate. Our SDK was built to empower Custodians, Exchanges and Wallet Providers to enable their users to access these benefits. 

‍

Chorus One SDK: Staking Made Simple

Don’t let the term “SDK” intimidate you. The Chorus One SDK is designed to be intuitive and lightweight. With just a few lines of code, you can:

• Build staking, unstaking, redelegation, and reward withdrawal transactions
• Sign transactions using your preferred method (including Utila, Ledger, and more)
• Broadcast transactions to the Cosmos network
• Track transaction status in real time

‍

We’ve successfully implemented Cosmos staking solutions for industry leaders like Ledger and Cactus, proving robust compatibility and reliability.

‍

Seamless Integration: Under 10 Lines of Code

Here’s how easy it is to get started with staking on Cosmos using our SDK:

import { CosmosStaker } from '@chorus-one/cosmos'

const staker = new CosmosStaker({
  rpcUrl: 'http://public-celestia-mocha4-consensus.numia.xyz',
  lcdUrl: 'https://api.celestia-mocha.com',
  bechPrefix: 'celestia',
  denom: 'utia',
  denomMultiplier: '1000000',
  gas: 250000,
  gasPrice: '0.4'
})

‍

Tip: The SDK is fully compatible with popular Cosmos libraries like `@cosmjs/cosmwasm`, making integration with existing projects seamless.

‍

Validator Addresses Made Easy

The SDK provides a pre-populated list of Chorus One validator addresses for all supported Cosmos networks:

import { CHORUS_ONE_COSMOS_VALIDATORS } from '@chorus-one/cosmos'

const validatorAddress = CHORUS_ONE_COSMOS_VALIDATORS.COSMOS

‍

Simplified Staking Operations 

The SDK simplifies staking on the Cosmos and other networks by offering easy-to-use methods to perform operations such as staking, unstaking, redelegating, and withdrawing rewards.  Here’s a simple example of how to build a staking transaction using the SDK:

const { tx } = await staker.buildStakeTx({
  delegatorAddress: 'celestia1x88j7vp2xnw3zec8ur3g4waxycyz7m0mahdv3p',
  validatorAddress: 'celestiavaloper15urq2dtp9qce4fyc85m6upwm9xul3049e02707',
  amount: '1' // 1 TIA
})

‍

Our SDK delivers a comprehensive end-to-end experience, facilitating signing via leading wallets and supporting transaction broadcasting. It’s common for our clients to have these services in-house, reducing the need for duplication. For more information on our adaptable and straightforward signing enablement and broadcasting, please refer to our in-depth documentation.

‍

Why Choose Chorus One SDK?

• Lightweight: Get started in under 10 lines of code.
• Secure: Supports industry-leading signing solutions.
• Compatible: Works with the Cosmos SDK and popular libraries.
• Proven: Successfully implemented in major wallets and dApps.
• Scalable: Supports staking for all Cosmos SDK-based protocols.

‍

Ready to enable staking?

With Chorus One, staking on Cosmos is as simple as it gets. Whether you’re building a new dApp, integrating staking into your product, or exploring Cosmos for the first time, our SDK has you covered.

‍

Explore our technical documentation for a deeper dive and start staking today!

‍

The next chapter in Bitcoin’s evolution is here

With the launch of Mezo, Bitcoin takes a decisive step into everyday finance—where BTC holders can borrow, spend, and earn without ever selling their Bitcoin.

At Chorus One, we’re proud to support this pivotal moment by securing the network that powers Mezo’s onchain Bitcoin banking.

Mezo: Bitcoin banking, onchain

Bitcoin is the most secure and decentralized asset in crypto, yet it’s often treated as passive. Mezo changes that by making BTC productive capital without compromising sovereignty.

At the heart of Mezo is MUSD, a 100% Bitcoin-backed stablecoin. Users post BTC as collateral and borrow MUSD at fixed, transparent rates (from 1%) with up to 90% LTV, opening stable liquidity for bills, purchases, treasury, and opportunities, all while keeping their upside in Bitcoin.

From fixed-rate borrowing to Bitcoin-backed stablecoin spending, Mezo is building the core primitives for a circular, user-owned Bitcoin economy. 

Learn more about Mezo’s Bitcoin-backed stablecoin loans

Borrowing on Mezo: live now—with Chorus One

Mezo’s mainnet brings BTC-collateralized borrowing to everyone. Open a position, borrow MUSD, deploy liquidity onchain or off-chain, and repay anytime to unlock your BTC. Activity on Mezo rewards early participation (e.g., Mezo Points) and will evolve as the network matures.

Everything is onchain and transparent, aligned with Bitcoin’s ethos of security and self-custody.

🔐 Want to learn more? Contact us here.

Why Chorus One?

As a validator and infrastructure provider for Mezo, Chorus One is proud to help secure the network at mainnet launch, playing a foundational role in bringing Bitcoin staking to life. Our involvement is part of a broader commitment to supporting the next generation of Bitcoin-native finance—an emerging landscape of L2s driving innovation in the Bitcoin ecosystem.

As one of the world’s most trusted staking providers, Chorus One brings the reliability and resilience this new financial infrastructure demands. We operate with ISO27001-certified security, 99.9% uptime across 40+ protocols, and a globally distributed infrastructure spanning 16 countries and 300+ points of presence. Every validator we run is backed by years of protocol expertise, automated operations, and proactive failover systems designed to ensure your assets stay safe and your rewards are delivered.

Choosing Chorus One means staking with a provider trusted by some of the largest names in crypto—and one fully aligned with Bitcoin’s ethos of security, transparency, and self-sovereignty.

👉To learn more, click here. 

Get Started

To get started staking your BTC, click here.

🟠 Remember, Mezo Points are just the beginning. These rewards will evolve into native BTC-based incentives as the network progresses.

To learn more, visit Mezo’s docs here. 

A New Era for Bitcoin

Bitcoin is no longer just digital gold. With the launch of Mezo, and the continued development of BitcoinFi, its becoming increasingly programmable, productive, and participatory.

BTC holders can now engage in decentralized finance without bridging to Ethereum, giving up custody, or sacrificing Bitcoin’s principles. Mezo offers the infrastructure to do this natively—and Chorus One provides the trusted path to participate securely.

We’re excited to help shape this next chapter and invite you to join us at the forefront of Bitcoin’s evolution.

👉Are you an institution looking to stake your BTC? Get in touch today!

‍

As a world-leading staking provider and node operator, we’re excited to support this next phase of Ethereum and the opportunities it unlocks. In this article, we’ll explore what Pectra is, its impact on the staking economy, and how Chorus One is delivering best-in-class experiences for stakers in this new era.

‍

Ready? Let's dive into the Pectra upgrade!

‍

Pectra’s Impact on Ethereum Staking

‍

Pectra is a major milestone in Ethereum’s proof-of-stake evolution. By raising validator stake limits, enabling auto-compounding, introducing partial withdrawals, and accelerating activations, this upgrade makes staking more scalable, capital-efficient, and accessible for both solo stakers and institutional participants.

‍

Increased Validator Stake Capacity

‍

At the heart of Pectra is the massive increase in validator stake capacity. The upgrade’s marquee proposal, EIP-7251, raises a validator’s Maximum Effective Balance (MEB) from the rigid 32 ETH limit to 2,048 ETH, through the introduction of a new validator type using the 0x02 withdrawal prefix. This permits large node operators to consolidate into fewer validators, while allowing for compounding rewards, and more flexible increments for stakers operating under the new 2048 ETH limit.

‍

It’s all about reductions. Reduced nodes leads to reduced network congestion, which further results in:

• Reduced p2p message overhead.
• Reduced signature aggregation overhead.
• Reduced size of the beacon state.

When a new node is added to the Ethereum network, all nodes must exchange attestations with it (P2P messages), and the beacon chain must store information about that validator (balance, status, etc.). All of this exponentially increases congestion as each new validator is added to the network.

‍

Currently, there are approximately 1 million nodes on Ethereum, with around 32 million ETH staked. With Pectra, a single validator can secure up to 64× more ETH, allowing for the consolidation of dozens of separate validator instances into one. If all ETH were consolidated into 0x02 validators, the size of the validator set would go down to 15,625. This may seem like an extreme or unrealistic conversion rate, but we actually expect the conversion rate to be pretty high over time. Of the 32M ETH staked, nearly 13.3M is in Liquid Staking Protocols, pools that aggregate ETH from users, and as such are extremely likely to consolidate in order to reduce operational overhead and slashing risk. A large portion of the remaining ETH is held by institutional holders, CEXs, etc., with holdings in excess of 2048 ETH; which will also likely be consolidated.

‍

So, there is actually a pretty good chance that over the next 12 months, the number of ETH nodes will go down by 100x, massively improving network efficiency.

‍

Higher Rewards & Flexible Staking Ranges

‍

The original Ethereum staking framework was rigid, with each validator capped at 32 ETH, and any rewards earned beyond this amount had no impact on returns. In order to optimize rewards, operators were required to manually withdraw funds and secure an additional 32 ETH before spinning up a new validator. With EIP-7251, these rewards can be automatically reinvested up to the new 2,048 ETH cap, allowing for auto-compounding of the staking rewards.

‍

At the same time, this makes staking more flexible than ever. Instead of the fixed 32 ETH increments, stakers will be able to allocate any amount between 32 ETH and 2,048 ETH within a single validator. This means that a user with 40 ETH could stake their entire balance, as opposed to under the old framework, where they would have to secure an additional 22 ETH (for a total of 64) and spin up an entirely new validator. This benefits both individual stakers and large-scale operators, enhancing capital efficiency and allowing for more tailored staking strategies.

‍

Triggerable Exits & Partial Withdrawals

‍

Historically, only validators could initiate exits, meaning stakers had to rely on node operators to process withdrawals. This created a trust dependency, particularly in staking-as-a-service models and pooled staking setups, where participants had limited control over their staked assets.

‍

Pectra addresses this with EIP-7002, which allows the execution-layer withdrawal address to directly trigger validator exits. This means that instead of depending on validator operators, stakers can now independently initiate withdrawals, giving them greater control over their funds.

‍

Beyond full exits, Pectra also refines partial withdrawals, allowing validators to seamlessly withdraw excess ETH beyond the 32 ETH staking requirement. Previously, while partial withdrawals were enabled in the Shanghai upgrade, they were processed in batches, sometimes leading to delays and inefficiencies. With Pectra, this process becomes more efficient, ensuring that staking rewards are automatically withdrawn without requiring validator intervention or disrupting staking activity.

‍

By shifting exit control to the execution layer and optimizing partial withdrawals, Pectra enhances staker autonomy, reduces trust dependencies, and improves liquidity in Ethereum’s staking ecosystem.

‍

Faster Validator Activations

‍

Before Pectra, when users staked ETH, it remained in the deposit contract until it was processed and assigned to a validator, a process that could take hours or even days, leading to delays in activation.

‍

Pectra improves this with EIP-6110, which embeds validator deposit data directly in execution layer blocks. This eliminates the need for validators to pull deposit data from the beacon chain separately, significantly reducing activation wait times. The benefits of this are:

• Faster staking onboarding – Validators can start securing the network sooner.
• More transparent deposit handling – Deposits are recorded directly in execution blocks, making the process easier to track.
• Better user experience for stakers – Reduced delays mean stakers can begin earning rewards more quickly.

This upgrade streamlines validator activations, making Ethereum’s staking process more efficient and responsive.

‍

Slashing on Pectra

‍

Currently, on Ethereum, the minimum slashing penalty (for double signing) is 1 ETH. This is calculated by dividing the effective balance by 32. Since the effective balance pre-Pectra is always 32, the slashing amount is almost always exactly 1 ETH.

‍

However, with the stake limit changed to 2048 ETH, if a fully consolidated node is slashed, you could incur a 64 ETH penalty for each double sign. This penalty is very high and might disincentivize staking, harming overall network security.

‍

To mitigate this, Pectra will change the slashing penalty to 1/4,096 of the total stake. So, if a node has the maximum effective balance (MEB) of 2048 and gets slashed, the new penalty would be 2048/4096, which amounts to 0.5 ETH. This lower penalty is to encourage the consolidation of validators by reducing risk. Effectively, with the Pectra upgrade, you have a higher ARR, initially at a lower slashing risk. However, this might change as the number of nodes comes down. This is a massive argument in favor of users switching to 0x02 validators.

‍

A New Era for the Staking Economy

‍

With Pectra, Ethereum staking is entering a new era of efficiency, flexibility, and accessibility. In the next section, we’ll explore how Chorus One is implementing Pectra’s advancements to deliver higher rewards, seamless staking experiences, and cutting-edge innovations for our clients.

‍

Chorus One’s Approach to Pectra

‍

As mentioned previously, Pectra introduces a new validator type (0x02 prefix) that allows for larger stake limits, automated compounding, and operational efficiency. At Chorus One, we are committed to providing our clients with the most optimized staking experience, ensuring they fully benefit from these improvements while maintaining network integrity and performance.

‍

Support for Both 0x01 and 0x02 Validator Types

‍

We understand that different stakers have different needs. That’s why Chorus One will continue to support both validator prefix types (0x01 and 0x02). However, we strongly encourage our clients to transition to the 0x02 validator type, as it offers higher rewards through compounded rewards, while also enhancing network efficiency.

‍

Seamless Migration & Validator Consolidation

‍

For existing Chorus One clients, we offer a smooth transition to Pectra’s 0x02 validator format. For new clients, if you’re considering moving your stake to Chorus One, enjoy a seamless onboarding process, where you can deploy a new 0x02 validator, maximizing staking efficiency from day one.

‍

Maximizing the Benefits of Compounding

‍

To ensure our clients experience the full benefit of Pectra’s compounding feature, Chorus One will implement a custom effective balance limit for 0x02 validators, set at 1910 ETH. This accounts for around 2 years of compounding rewards at a rate of 3.5% annualized, before reaching the 2048 ETH cap, allowing for sustained reward optimization.

‍

Why Stake with Chorus One?

‍

At Chorus One, we optimize staking operations in order to maximize performance and rewards. Through leading early-stage research, collaboration with other industry leaders, and advanced testing of new implementations, we aim to provide our clients with the highest possible returns, while actively contributing to Ethereum’s long-term security and efficiency.

‍

MEV Optimization

‍

Ethereum validators play a crucial role in Maximal Extractable Value (MEV). Our team is at the forefront of reward optimization for our stakers. In 2024, we worked on our proprietary mev-boost fork called Adagio. Our research showed that Adagio delivered a total improvement of 16.67% in MEV rewards from June 2024 until the end of the year. To learn more, click here.

‍

In 2025, we stopped using the Adagio model as relays began to exploit timing games. Our focus has now shifted to optimizing connectivity to relays rather than fine-tuning timing parameters. Since then, we’ve focused on:

• Co-location with key relays — placing servers physically closer to MEV relays to reduce latency and land more valuable blocks.
• Optimal peering — selecting the best network routes to reduce latency even further.

This way, we’re able to optimize for rewards and performance for our stakers.

‍

Early Adoption of Preconfirmations for Reward Enhancement

‍

We stay ahead of the curve by actively testing and implementing groundbreaking technologies that enhance staking rewards. Working alongside key players, including Chainbound/Bold, Primev, and ETHGas, we stay vigilant in testing and implementing cutting-edge solutions. In fact, Chorus One led the first-ever preconfirmations using Bolt during the ZuBerlin and Helder testnets.

‍

We have since continued to conduct and share our research, with the most recent additions being our research paper on Pricing Transactions for Preconfirmations. You can also try out our preconfs dashboard, which allows you to test pricing strategies across more than 400k transactions. Plus, access our very own Random Forest Model, which outperformed even the Geth’s heuristics-based transaction fee-pricing.

‍

Innovative Reward Opportunities through DVT Technologies

‍

We provide unique opportunities to enhance staking rewards through Distributed Validator Technology (DVT), in collaboration with industry leaders such as Obol and SSV. Our deep involvement in Ethereum research and development positions us as the most capable and reliable staking operator.

‍

Want to start maximizing your ETH staking rewards with a leading staking provider?

👉Stake With Us!

‍

From Holesky to Hoodi: Pectra’s Difficult Path to Mainnet

‍

This wouldn't be an analysis of Pectra without addressing the elephant in the room, Holesky. On Monday, February 24, 2025, the Pectra upgrade was activated on the Holesky testnet. Unfortunately, a bug in specific Execution Layer (EL) clients (specifically Geth, Nethermind, and Besu) caused them to use the wrong deposit contract address. As a result, these clients processed a block incorrectly, leading to a network split where:

• Validators using Erigon and Reth (correct configuration) rejected the invalid block.
• Validators using Geth, Nethermind, and Besu (misconfigured clients) accepted the invalid block and continued building on it.

This divergence created two chains:

1. The invalid chain (majority chain) – most validators followed it.
2. The valid chain (minority chain) – only a few validators correctly followed it.

Because most validators followed the incorrect chain, the overall network health degraded, making it difficult for nodes to sync to the correct chain and potentially undermining the reliability of testnet transactions.

To resolve the issue, Ethereum developers proposed a coordinated slashing approach. The plan aimed to:

• Get enough Holesky validators online simultaneously to finalize a block on the correct chain.
• Slash validators who had attested to the invalid chain, forcing them off the network.
• Reduce the stake of slashed validators below 33% so that the correct chain can be finalized.

Holesky validators were instructed to update their clients to patched versions, sync to the valid chain and disable slashing protection by slot 3737760 to enable attestations to the correct chain.

‍

A coordination call was scheduled to guide node operators, with Chorus One among the participants. Unfortunately, this slashing experiment failed, leaving Holesky in a prolonged period of instability.

‍

In response, Ethereum developers launched a new testnet called Hoodi in late March 2025. Chorus One became one of the 29 Hoodi genesis validators to help with the network’s launch and to be among the first entities active on the new testnet for Pectra. Hoodi mirrors mainnet conditions more closely, with a similar validator count and infrastructure. Pectra was deployed there and finalized just 30 minutes after activation, a sharp contrast to the Holesky failure. Hoodi is now expected to replace Holesky as Ethereum’s primary public testnet later this year.

‍

The Hoodi deployment serves as the final dress rehearsal for Pectra.

‍

Stake with Chorus One

‍

The Pectra Hardfork represents a watershed moment for Ethereum, redefining what’s possible for both individual stakers and large-scale institutions. As a leading validator service provider, Chorus One stands at the forefront of these changes, offering modern solutions that transform the way you stake and manage your crypto assets.

‍

If you’re ready to experience optimal performance, higher rewards, and a truly next-gen staking platform, contact us or visit our website to learn more about how Chorus One can help you thrive in the Pectra era. Let’s enter this exciting new chapter of Ethereum staking together.

👉Stake With Us!