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.

‍

For many years, corporate treasury strategies were very predictable: cash, bonds, and money market instruments. But the world shifted in 2020 when MicroStrategy made waves by placing Bitcoin squarely on its balance sheet as an offensive strategy. Now, with Bitcoin now firmly established in many corporate reserves, a new paradigm is emerging: companies are embracing proof-of-stake assets, starting with Ethereum, to earn yield while staking. This marks a critical shift in how companies think about treasury management in the digital age.

Bitcoin: The Digital Gold Prelude

MicroStrategy led the charge in August 2020 with an initial $250 million BTC purchase, framing Bitcoin as a strategic hedge against inflation and depreciation. By late 2024, MicroStrategy had amassed over 423,650 BTC, now valued at $42 billion, making it the largest corporate BTC holder. Corporate Bitcoin accumulation has spread rapidly: 61 public firms now hold more than 3.2% of total BTC supply with companies such as Tesla, GameStop, Riot Platforms, and Twenty One Capital all including Bitcoin in their treasuries. By mid 2025, private and public entities reportedly held more than 847,000 BTC.

Phase Two: Strategy Meets Yield

As BTC led the digital treasury charge, Ethereum emerged as a compelling next step, offering staked yield plus utility via smart contracts.

• Bit Digital (NASDAQ: BTBT) pivoted entirely to ETH, abandoning Bitcoin holdings in favor of building a ~100,600 ETH treasury and associated validator infrastructure. 
• SharpLink Gaming (NASDAQ: SBET) now holds ~176,000 ETH, staking over 95% of it, with its treasury decision correlating with a 400% stock surge.
• BitMine Immersion Technologies rebranded from BTC mining to ETH treasury and staking, with shares rising 25% post-announcement.
• Meanwhile, Coinbase, Exodus Movement, and Mogo also disclosed ETH holdings as part of their treasury diversification.

These moves reflect a broader cell-level strategy: shifting from purely speculative assets to productive assets that deliver yield while supporting growing digital ecosystems.

Institutional Infrastructure & Regulatory Momentum

Institutional custodial and infrastructure support has become the bedrock of credible crypto treasury strategies. Major players like Coinbase Custody, Anchorage Digital, Fireblocks, and BitGo now offer enterprise-grade custody and staking services tailored to institutional clients. For example, BitGo provides multisignature cold storage and staking support across numerous networks, managing approximately one‑fifth of on‑chain Bitcoin transactions by value. Anchorage Digital, a federally chartered crypto bank, and Fireblocks, recently approved by New York regulators, are now integrated into services like 21Shares’ spot BTC and ETH ETFs alongside Coinbase, further reinforcing industry-grade security and operational compliance. On top of custody, Validator-as-a-Service (VaaS) providers, including Chorus One, Figment, and Kiln, deliver staking infrastructure with service-level guarantees, compliance tooling, and risk mitigation capabilities to allow corporations to operate node infrastructure or delegate responsibly without needing internal DevOps teams, preserving security while capturing staking yields.

Regulatory clarity is also catching up. The IRS issued Revenue Ruling 2023‑14 on July 31, 2023, confirming that staking rewards are taxed as ordinary income once received by cash-method taxpayers under Section 61(a). Complementing this, the SEC has signaled openness to compliant staking frameworks as custodians partner with spot ETF issuers, reinforcing governance and audit controls. Looking ahead, the proposed Digital Asset Market Clarity Act of 2025 (CLARITY Act) would further strengthen this landscape by formally demarcating regulatory jurisdictions: assigning digital commodities such as ETH and SOL to the Commodity Futures Trading Commission (CFTC) while affirming the SEC’s oversight of securities. It would also clarify that mature, protocol-native tokens and DeFi protocols are not investment contracts and further supports institutional use of on‑chain strategies, but also promises to unlock structured layers like restaking, vaults, and LST integrations while preserving board-level governance, audit trails, and operational transparency.

Why It Matters: Yield, Utility, and Strategic Signaling

Producing real returns while signaling innovation, staking ETH and SOL offers public companies an attractive alternative to low-yield corporate cash or stablecoin reserves. Profitable yields of 3–7% APY are now accessible through institutional staking platforms, easily outperforming many fixed-income rates. Holding programmable assets also facilitates strategic optionality, enabling treasurers to engage with DeFi use cases, tokenize balances, or even pilot vendor fee settlements with smart contracts.

Beyond financial results, corporate treasury adoption of productive crypto signals clear differentiation to investors. A leading example is SharpLink Gaming, which converted a significant portion of its capital into Ethereum and staked over 95% of it. The firm credits this strategic shift, and the appointment of Ethereum co-founder Joseph Lubin to its board, for signaling innovation and advancing its market positioning. 

Looking Ahead

The evolution of corporate crypto treasuries is unfolding in clearly defined phases, each building upon the last in sophistication and capital efficiency. The first phase, Bitcoin pioneering, emphasized symbolic value and digital gold positioning. This was followed by the productive digital assets phase, where firms began to allocate into Ethereum (ETH) and Solana (SOL), not just for exposure but also for the ability to earn staking rewards, thereby generating yield from idle capital. And now, we are entering the multi-layer yield phase, in which forward-looking treasuries are layering on liquid staking, restaking protocols, and decentralized finance (DeFi) integrations to unlock additional yield and liquidity while retaining principal exposure. As regulatory frameworks solidify and infrastructure scales, expect more corporate treasurers to move from storing value to building yield-generating digital treasury architectures.

‍

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.

At Chorus One, we’ve always believed that staking should be both secure and seamless. Over the past few years, we’ve partnered with leading institutions like Ledger, Utila, and Cactus to bring institutional-grade staking solutions to users worldwide. These partnerships have largely relied on SDK-based integrations, which, while effective, still require a fair amount of development and testing on the client side.

Now, we’re taking simplicity to the next level with the Chorus One Earn Widget.

What is the Chorus One Earn Widget?

The Chorus One Earn Widget is a ready-to-integrate staking portal designed to be embedded directly into a partner’s website or app. Built on an iFrame, it allows platforms to offer staking products to their users almost instantly: no heavy lifting, no lengthy development cycles.

With a prebuilt user interface, wallet connection support, and built-in transaction flows, partners can launch staking services quickly, while users can start staking assets and earning rewards without leaving the familiar environment of their preferred app or platform.

For many of our partners, speed matters, and we have seen this accelerate in recent weeks, with some institutions needing to quickly onboard a new provider for staking in days. Take any leading FinTech app, for example, which is preparing to add staking–while SDK integrations provide full customization,  FinTech apps and similar partners want a plug-and-play solution that minimizes the technical overhead of launching a new product.

The Chorus One Widget solves this by offering:

• Minimal integration effort – Embed it like you would any iFrame.
• Seamless user experience – Prebuilt UI consistent with Chorus One’s dApps.
• Customizability – Adjust variables such as accent colors, logos, or theme (light/dark mode) to match brand identity.
• Robust functionality – Support for wallet connections, staking/unstaking, and reward tracking.

In short, the widget makes staking as easy as adding a YouTube video to your site.

Who Is It For?

The widget is designed for:

• FinTech apps looking to quickly expand their product offering with staking.
• Wallet providers who want to add staking capabilities without building from scratch.
• DeFi platforms aiming to provide their users with additional earning opportunities.

By removing development and testing hurdles, the widget opens the door for a wider range of institutions to integrate staking into their products.

Features at a Glance

The Chorus One Earn Widget comes with a set of functional and non-functional features  designed to ensure security, scalability, and usability:

• Prebuilt UI with customizable colors, fonts, and themes.
• Wallet support in line with Chorus One’s ETH and SOL dApps, with improved wallet lists for Ethereum.
• Transaction handling for staking, unstaking, and withdrawals, with in-widget pop-ups for a clean user experience.
• Dashboard (future-ready) to display user positions, rewards summaries, and potentially charts or promotional content.
• Security-first design with whitelisting, API authentication, and performance optimization for high transaction volumes.
• Scalability currently supports 12 networks including ETH, SOL, and TON. The Earn Widget will continue expanding to support additional networks, restaking, and assets.

Benefits for Partners and Users

For partners, the widget reduces integration time dramatically while offering a customizable, secure, and scalable solution. It fits neatly into existing workflows and comes with implementation guides and support from the Chorus One team.

For end users, the widget ensures a familiar, intuitive interface to stake assets and track rewards, without navigating away from the apps and platforms they already trust.

Expanding the Chorus One Ecosystem

The launch of the Chorus One Earn Widget represents a strategic step toward expanding our product suite which includes the Chorus One SDK and dApp, and reaching a broader client base. By lowering the barrier to entry for staking integration, we’re enabling more institutions, both traditional and decentralized, to offer their users access to rewards and participation in proof-of-stake networks.

Our goal is clear: make staking simple for everyone. Whether through SDKs for tailored integrations or the plug-and-play widget for faster rollouts, Chorus One is committed to delivering best-in-class staking infrastructure to meet our partners’ diverse needs.

‍

Institutional crypto treasuries are entering a new phase. In the first wave, treasurers allocated to Bitcoin and Ethereum, focusing on long-term exposure and basic staking yields. But as on-chain infrastructure matures and liquid staking protocols like Lido and EigenLayer gain traction, a new strategy is emerging: yield stacking. By combining liquid staking tokens (LSTs), restaking mechanisms, and DeFi services, treasuries can now layer multiple sources of yield on top of the same principal, without giving up custody, transparency, or compliance controls. Treasuries that can generate 3–5% from vanilla savings and staking, can now see 6–10% using enterprise-grade tools and increasingly permissioned crypto vaults. This is Treasury 3.0: dynamic, composable, and built for capital efficiency.

The New Frontier: From Staking to Yield Stacking

The blink-and-you- will-miss- it era of single-layer staking, locking ETH or SOL for basic yield, is already giving way to yield stacking strategies that enhance capital efficiency without compromising security. Traditional staking is a great foundation, delivering around 3–5% APY on assets like Ethereum and Solana. Adding liquid staking, using tokens such as stETH or mSOL, which grant liquidity and composability for use across DeFi protocols, add another 3+%.  For example, Lido’s stETH, for instance, currently yields 2.7-3.3% APY on secured ETH while enabling seamless DeFi integration across 90+ platforms. Next comes restaking, via platforms like EigenLayer, which allows existing staked (or liquid-staked) ETH to secure additional protocols, adding an extra ~.50% yield while leveraging Ethereum’s security layer. Each layer compounds yield while keeping treasuries in control via custodied wrappers, making this tactical approach highly compelling for sophisticated institutional finance teams.

Case Study: What a Multi-Yield Treasury Stack Looks Like

Imagine a treasury that layers multiple yield strategies on the same ETH base—for example:

• Layer 1: ETH → staked ETH
  At this stage, ETH earns roughly ~2.7–3.3% APY through validators such as Chorus One.
• Layer 2: stETH → EigenLayer AVS via restaking
  Using liquid-staking to mint stETH can then be restaked through EigenLayer to secure additional Actively Validated Services (AVSs), earning an extra ~.50% APY on top of the base yield.
• Layer 3: DeFi deployment
  The liquid stETH can then be deployed in yield-bearing protocols, lending it on Aave, for instance, can add another 2–6% APY, depending on market conditions.

Stacking these rewards represents a 2x+ improvement over traditional savings or T-bill yields (~3% APY), without relinquishing principal or legacy custody frameworks. Whether a treasury opts for a conservative single-stack or a progressive full-stack deployment, the efficiency gain is clear, and easily trackable with the right tooling.

Infrastructure Is Catching Up

What once required bespoke tooling and manual tracking is now becoming enterprise-ready. Institutional-grade infrastructure is rapidly evolving to support yield-stacking strategies through familiar custody, validator, and reporting partners. Custodians like Coinbase Custody, Anchorage Digital, and BitGo now support liquid staking tokens (LSTs) and restaking flows, enabling treasuries to layer yield without compromising asset security. On the validator side, providers such as Chorus One, Kiln, Figment, and Renzo offer restaking and AVS onboarding services with built-in compliance and risk frameworks. And tools like Chorus One’s Rewards Reporting complete the stack by offering audit-ready reporting, wallet-level attribution, and easily exportable formats to satisfy both finance and ops teams. The combination of performance, visibility, and enterprise integration is what transforms this from a crypto-native idea into a finance-grade treasury solution.

Risks and Requirements

While the opportunity is clear, executing a Treasury 3.0 strategy requires thoughtful navigation of regulatory, technical, and organizational complexity. Tax guidance remains underdeveloped, especially around restaking and liquid staking tokens (LSTs). For example, the IRS has clarified that staking rewards are taxed as ordinary income upon receipt (Rev. Rul. 2023‑14), but has yet to issue formal treatment of restaking flows or derivative tokens like stETH and LRTs. Meanwhile, Europe’s DAC8 and proposed U.S. legislation like the CLARITY Act could introduce new disclosure and compliance obligations for multi-layer yield strategies. On the operational front, risks include smart contract vulnerabilities in vaults or restaking modules, as well as composability fragility, where issues in one protocol layer (e.g., an LST depeg) could cascade through a treasury stack. To handle these requirements, institutions must update investment policies, establish clear escalation protocols, and ensure cross-functional coordination between finance, legal, and technical teams. But these are small obligations in comparison to the power of a Treasury 3.0 yield stacking strategy.

Conclusion: Treasury 3.0 Is Already Here

The next evolution of treasury management isn’t a future concept, it’s already unfolding across the on-chain economy. Treasury 3.0 strategies harness staking, restaking, and DeFi layers to unlock meaningful, compoundable returns which significantly outperform traditional finance tools while preserving custody, compliance, and control. With infrastructure and reporting tools maturing, these strategies are now auditable and enterprise-ready. For forward-looking finance teams, the question is no longer if to adopt these strategies, but how to operationalize them responsibly. Institutions that act now will not only drive stronger yield, they'll define the governance, compliance, and capital efficiency standards of the new digital economy.

The U.S. crypto ETF landscape is undergoing a transformative shift. The recent approval (or more accurately, no disapproval) of the REX-Osprey™ SOL + Staking ETF (ticker: SSK) marks a significant milestone, offering investors exposure to Solana (SOL) while earning yield through on-chain staking. This development signals a broader trend: the integration of staking rewards into regulated investment vehicles.

This is already a gigantic shift in SEC policy and enforcement. But what comes next? Emerging technologies like Distributed Validator Technology (DVT) and restaking protocols introduce new layers of yield that should be integrated into these traditional ETF structures. This article explores the current state of crypto ETFs, the implications of these innovations, and the regulatory considerations that lie ahead.

The Rise of Staking ETFs

As we discussed previously, the launch of the REX-Osprey™ SOL + Staking ETF represents a pioneering approach to integrating staking rewards into an ETF structure. By utilizing a C-corporation that owns a Cayman-based subsidiary, the fund acquires and stakes SOL tokens, providing investors with staking yields within a regulated framework .

This structure offers a workaround to the traditional '33 Act spot ETF route, enabling faster market entry. However, it also introduces tax inefficiencies, as C-corporations are subject to corporate tax, potentially reducing the staking rewards passed on to shareholders.

Challenges in Achieving High Rewards Amid Altcoin Momentum

As the crypto market matures, investors are increasingly looking beyond Bitcoin and Ethereum to altcoins that offer higher staking yields. However, integrating these assets into ETFs presents several challenges:

• Liquidity Constraints: Many altcoins have lower liquidity, making it difficult for ETFs to manage large inflows and outflows without impacting market prices.
• Regulatory Uncertainty: The classification of certain altcoins remains ambiguous, posing risks for ETF issuers in terms of compliance and investor protection.
• Operational Complexity: Managing staking operations for multiple altcoins requires sophisticated infrastructure and expertise, increasing operational risks.

The Double-Edged Sword of DVT and Restaking

Emerging technologies like Distributed Validator Technology (DVT) and restaking protocols offer promising ways for enhancing staking yields and network security. However, they also introduce complexities that challenge traditional ETF structures.

Distributed Validator Technology (DVT):

DVT allows multiple nodes to collaboratively operate a single validator, enhancing decentralization and fault tolerance. Projects like Obol Network and SSV Network are at the forefront of this innovation.

Benefits:

• Increased Resilience: By distributing validator responsibilities, DVT reduces the risk of single points of failure.
• Enhanced Security: DVT mitigates risks associated with key management and validator downtime.

Challenges:

• Tax Implications: The introduction of middleware tokens like SSV raises questions about their classification and taxation within ETF structures.
• Operational Complexity: Implementing DVT requires sophisticated coordination among node operators, which may be challenging for ETF issuers to manage. 

Restaking Protocols:

Restaking allows staked assets to be used to secure additional networks or services, effectively layering staking rewards.EigenLayer is a prominent example of this approach .

Benefits:

• Enhanced Yield: Restaking can amplify returns by allowing assets to earn multiple streams of rewards.
• Capital Efficiency: It enables more efficient use of staked assets across different protocols.

Challenges:

• Regulatory Ambiguity: The layered nature of restaking complicates the classification of rewards and may trigger additional regulatory scrutiny.
• Risk Management: Restaking introduces new risks, such as correlated failures across protocols, which need to be carefully managed.

Regulatory Landscape: Navigating Uncertainty

The integration of advanced staking mechanisms into ETFs necessitates a clear regulatory framework. The CLARITY Act of 2025 aims to provide such a framework by delineating the responsibilities of the SEC and CFTC over digital assets.

Additionally, the IRS's Revenue Ruling 2023-14 clarifies that staking rewards are taxable when the taxpayer gains dominion and control over them. However, the application of this ruling to complex staking arrangements involving DVT and restaking remains uncertain.

ETF issuers must navigate these regulatory complexities to ensure compliance while offering innovative products that meet investor demand.

Conclusion: Embracing Innovation with Caution

The evolution of staking ETFs represents a significant advancement in the integration of decentralized finance into traditional investment vehicles. While technologies like DVT and restaking offer enhanced yields and network security, they also introduce complexities that must be carefully managed.

As the regulatory landscape continues to evolve, collaboration among ETF issuers, technology providers, and regulators will be crucial in developing products that balance innovation with compliance.

‍

At Chorus One, our mission is to empower institutions, protocols, and individual stakers with the best-in-class infrastructure and yield opportunities across the Proof-of-Stake ecosystem. Today, we’re excited to announce a new partnership with MEV Zone, a permissionless protocol designed to bring transparent and standardized MEV extraction to Avalanche.

Introducing MEV Zone

MEV Zone is pioneering an Avalanche-specific implementation of Proposer-Builder Separation (PBS), a mechanism designed to optimize block production and democratize access to MEV (Maximal Extractable Value).

Through MEV Zone, validators run a custom client that receives block chunks from builders and assembles them into the final block. In return, validators receive a share of the block yield from the extracted opportunities.

This approach not only enhances validator rewards but also contributes to healthier network dynamics by ensuring that arbitrages, liquidations, and other MEV-driven market activities are executed in a transparent and standardized way.

What This Means for Chorus One Customers

As one of the largest and most trusted validation providers across Avalanche and 40+ other networks, Chorus One is proud to be the first partner of MEV Zone.

This collaboration will make MEV Zone’s innovative solution available to both:

• Public nodes operated by Chorus One;
• Validator-as-a-Service (VaaS) customers, who will now gain access to this additional yield source without any operational overhead.

By integrating MEV Zone into our infrastructure, we’re extending a new layer of yield opportunities for Avalanche validators and delegators, while ensuring the network benefits from more efficient and fair markets.

Transparent and Sustainable MEV

The broader MEV conversation in blockchain has often been clouded by concerns around fairness and opacity. By supporting MEV Zone, we believe Avalanche can set a new standard—where MEV is permissionless, transparent, and beneficial for both validators and the network’s long-term sustainability.

At Chorus One, we see this as an important step in our ongoing journey to provide robust infrastructure and innovative yield strategies for our partners and clients.

‍

About Chorus One

Chorus One is one of the largest institutional staking providers globally, operating infrastructure for over 40 Proof-of-Stake (PoS) networks, including Ethereum, Cosmos, Solana, Avalanche, Near, and others. Since 2018, we have been at the forefront of the PoS industry, offering easy-to-use, enterprise-grade staking solutions, conducting industry-leading research, and investing in innovative protocols through Chorus One Ventures. As an ISO 27001 certified provider, Chorus One also offers slashing and double-signing insurance to its institutional clients. For more information, visit chorus.one or follow us on LinkedIn, X (formerly Twitter), and Telegram.

‍

About MEV Zone

MEV Zone is a permissionless protocol for transparent MEV extraction on Avalanche, powered by an Avalanche-specific version of Proposer-Builder Separation (PBS). The protocol enables validators to increase returns while improving market efficiency and fairness across the Avalanche ecosystem.

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.

‍