At Chorus One, our mission has always been to empower investors and institutions to securely and efficiently participate in decentralized finance. Today, we’re excited to share a major step forward in that journey — our collaboration with Morpho and Steakhouse Financial to deliver Chorus One Earn, a forthcoming stablecoin yield product that combines transparency, risk management, and competitive returns for USDC holders.
This collaboration brings together three leaders in the DeFi ecosystem with complementary expertise:
Together, we’re creating a simple, non-custodial way for users to earn yield on idle stablecoins, without compromising on control or oversight.
Stablecoins have become the backbone of onchain finance, yet most treasury and fund managers face the same challenge: how to earn predictable yield on stable assets while managing counterparty and liquidity risk.
With Chorus One Earn, we’re addressing that challenge head-on. The product provides access to curated stablecoin vaults powered by Morpho’s lending network and guided by Steakhouse’s risk-management expertise.
Through the Chorus One platform, users will soon be able to:
Our goal is to make the stablecoin yield experience as frictionless and transparent as possible – whether you’re a DAO, an institutional investor, or a DeFi protocol managing treasury assets.
Chorus One Earn will debut with two curated USDC vaults, both powered by Morpho. Each vault is designed to cater to a different investor profile, offering a choice between stability and higher yield potential. They differ in the range of risk that the curator onboards to each vault to create the target levels of liquidity and borrower interest.
A conservative strategy focused on predictable returns and capital preservation. This vault prioritizes exposure to blue-chip collateral and includes longer governance timelocks to ensure oversight and predictability. It’s an ideal fit for institutions prioritizing stability, liquidity, and transparent governance.
A dynamic, higher-risk strategy designed for investors seeking stronger yield potential. The High Yield vault allocates into emerging collateral categories, such as tokenized private credit and structured products, and features shorter timelocks for quicker adaptation to market opportunities.
Both vaults are bookended by the same infrastructure: robust risk-management frameworks and collateral underwriting and real-time monitoring and 24/7 reallocations.
Every aspect of Chorus One Earn is designed with control and clarity in mind. Depositors retain full custody of their assets and can monitor vault activity in real time. Yield generation is powered by transparent, auditable smart contracts – not opaque off-chain processes.
By integrating Morpho’s lending optimization and Steakhouse’s asset management expertise into our infrastructure, we’re setting a new benchmark for how stablecoin yields can be earned safely and efficiently onchain.
Today’s announcement marks the beginning of this collaboration – the full product launch is coming soon. When it goes live, Chorus One Earn will be available directly through our Widget, dApp, and SDK, giving users multiple ways to integrate stablecoin yield into their treasury operations or DeFi platforms.
We’ll share more details, including performance data and onboarding timelines, in the official launch announcement.
To be the first to access Chorus One Earn when it launches, sign up for updates at chorus.one or follow us on X and LinkedIn.
As institutional capital enters crypto, SOC 2 has become the baseline language of trust—proving that operational controls are documented, tested, and auditable. But while it validates process integrity, it wasn’t built for blockchain-specific risks like validator uptime, key management, or on-chain resilience. The next evolution pairs SOC 2 with ISO 27001 for continuous risk governance and DORA for regulatory resilience, creating a layered assurance model fit for digital assets. Looking ahead, a “SOC 3.0” paradigm will merge continuous monitoring, cryptographic proofs, and real-time transparency—turning trust from a static audit into a living, verifiable standard for institutional crypto infrastructure.
For digital-asset infrastructure, trust isn’t built on slogans, it’s built on standards. Among those, SOC 2 has become the universal language of operational credibility between crypto-native firms and institutional finance. Originally developed by the American Institute of Certified Public Accountants (AICPA), SOC 2 (System and Organization Controls) reports evaluate how well a company protects data across five “Trust Services Criteria”: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
For traditional finance, SOC 2 has long been the standard for assessing whether vendors operate with robust security and governance. In the digital-asset economy, it now plays a similar role: bridging Web2 assurance frameworks and Web3 infrastructure. When an institutional investor, custodian, or exchange asks whether a staking provider or node operator is SOC 2-certified, they aren’t just checking the boxes, they want to understand reliability, transparency, and the ability to prove control in an environment where capital never sleeps.
The reason this conversation matters now is that the assurance landscape for crypto infrastructure is changing fast. In Europe, the Digital Operational Resilience Act (DORA) will begin enforcement in 2025, requiring continuous monitoring, incident classification, and third-party risk management for all critical ICT providers. At the same time, staking and custody firms across the U.S. and Asia are pursuing SOC 2 Type II and ISO 27001 certifications to meet procurement standards set by institutional allocators and banks. Together, these shifts are raising the bar: compliance is the price of admission to serve institutional capital.
But realistically, SOC 2 alone can’t capture every crypto-specific risk; key management, validator uptime, or smart-contract exposure all remain. But SOC 2 establishes a shared vocabulary of trust that both TradFi and DeFi understand. The challenge ahead, and the opportunity, is to extend that framework into the unique realities of blockchain infrastructure, to make assurance as continuous, transparent, and composable as the systems it governs.
SOC 2 is often described as the “gold standard” for operational assurance, and in many ways, it is. The framework, governed by the American Institute of Certified Public Accountants (AICPA), focuses on how an organization designs and operates its internal controls across five Trust Services Criteria:
These pillars reflect the essentials of trust in modern infrastructure, whether in a data center, a SaaS platform, or a staking service. For crypto and digital asset operators, SOC 2 shows that the organization has implemented, documented, and maintained security and operational processes with the same rigor expected in traditional financial institutions.
There are two key forms of SOC 2 reports:
For institutional partners, the distinction matters. A Type II audit provides evidence not just of policy, but of consistent execution, something risk teams view as critical for ongoing relationships.
However, SOC 2 has a well-defined boundary: it tests control integrity, not resilience or industry-specific adequacy. Organizations define their own controls, and auditors assess whether those controls exist and function as described, not whether they meet a universal security baseline. For example:
This is why SOC 2 is best understood as an attestation of operational maturity, not a certification of invulnerability. It provides essential assurance that controls are in place and working, the minimum entry requirement for institutional trust, but it stops short of enforcing resilience, continuity, or sector-specific standards.
For that reason, leading firms layer SOC 2 alongside frameworks such as ISO 27001, which prescribes a full Information Security Management System (ISMS), and DORA, the EU’s new Digital Operational Resilience Act, which mandates continuous incident reporting, stress testing, and third-party risk oversight for financial entities. Together, these frameworks cover what SOC 2 starts: SOC 2 establishes trust in process, ISO 27001 embeds continuous improvement, and DORA enforces regulatory resilience.
In short:
SOC 2 is the starting line for institutional trust. To turn attestation into resilience, firms pair SOC 2 with ISO 27001 and, in the EU, DORA
In traditional finance, governance frameworks tend to overlap, one defines how you manage risk, another defines what you must protect, and another defines how resilient you must be. In crypto infrastructure, that overlap is starting to take the same form. SOC 2, ISO 27001, and the EU’s Digital Operational Resilience Act (DORA) each play distinct but complementary roles in building institutional-grade security and assurance.
SOC 2 is fundamentally about trust through documentation and execution. It validates that an organization’s internal controls exist, are logically designed, and operate effectively over time. This is why it’s often the first certification sought by digital-asset custodians, staking operators, and exchange infrastructure providers entering institutional partnerships. SOC 2 is non-prescriptive, it doesn’t tell firms which encryption method to use or how to design access control, but it ensures that whatever control framework the company adopts is consistently applied and auditable.
Where SOC 2 stops at control attestation, ISO 27001 begins with systemic governance. Developed by the International Organization for Standardization, ISO 27001 defines a comprehensive Information Security Management System (ISMS), a living framework for assessing, mitigating, and improving security risks across people, processes, and technology. Unlike SOC 2’s periodic audits, ISO 27001 requires ongoing risk assessments, internal audits, and management reviews, embedding security into continuous operations. For institutions, this makes it the global benchmark for “security maturity.”
For crypto firms, particularly those offering infrastructure to regulated banks or funds, ISO 27001 complements SOC 2 by providing:
In practice, many institutions view SOC 2 + ISO 27001 as the combined standard for enterprise-grade crypto infrastructure: SOC 2 gives assurance to auditors and clients; ISO 27001 satisfies risk and compliance teams.
The Digital Operational Resilience Act (DORA), which will take effect across the EU in January 2025, represents the regulatory evolution of these voluntary frameworks. DORA explicitly targets financial entities and their critical ICT providers, imposing mandatory standards for:
Unlike SOC 2 or ISO 27001, DORA is law, not guidance, and its scope extends to critical service providers to regulated institutions. This means staking infrastructure companies, custodians, or blockchain node operators that serve EU-regulated banks may be classified as “critical ICT third parties,” bringing them under direct oversight by the European Supervisory Authorities (ESAs).
In other words:
SOC 2 earns trust.
ISO 27001 builds resilience.
DORA enforces both — under regulatory supervision.
For infrastructure providers like Chorus One, these frameworks work as a progression: SOC 2 establishes procedural trust, ISO 27001 embeds operational discipline, and DORA ensures resilience meets regulatory thresholds. Together, they create a compliance and assurance fabric that speaks both institutional and decentralized languages; aligning crypto infrastructure with the governance rigor expected in modern finance.
SOC 2 has become the passport for trust in digital-asset infrastructure, but it’s only the first chapter in what assurance must become for a 24/7, on-chain economy. The next phase will demand something closer to a “SOC 3.0” standard: one that integrates continuous monitoring, cryptographic verification, and regulatory transparency in real time.
Traditional SOC 2 audits are retrospective snapshots: a look back over six or twelve months to confirm that controls operated as designed. But blockchain infrastructure operates in real time, where validator uptime, MEV execution, or slashing incidents can occur in seconds.
Future assurance models will need to move from static attestations to continuous validation, using telemetry feeds, automated incident reporting, and live dashboards that update an organization’s control status dynamically. This shift mirrors the evolution of DORA’s continuous-resilience mandate and will ultimately bridge compliance with operational reality.
The next generation of assurance will combine conventional audits with on-chain verifiability. Concepts such as Proof-of-Control audits, cryptographic demonstrations that an entity controls validator keys or custody wallets without exposing them, and real-time attestations of uptime, governance participation, and key-management events could make trust both provable and programmable. In this “SOC 3.0” paradigm, auditors can verify it on-chain, linking SOC-style attestations to blockchain-based proofs that anyone can independently confirm.
For regulated institutions, this convergence will make frameworks like SOC 2, ISO 27001, and DORA interoperable.
For staking providers and validators, the benefits go beyond compliance. Real-time proof of validator performance, custody control, and incident transparency can enhance reputation, attract institutional delegations, and even feed into insurance underwriting and risk-weighted capital models.
That’s the future of assurance for crypto infrastructure: a living standard that blends the rigor of traditional compliance with the verifiability of blockchain itself. The path from SOC 2 to some new SOC 3.0 will be about designing trust that updates in real time.
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.
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.
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.
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.
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.
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:
Traditional HotStuff requires 3 phases to finalize a block, each happening one after the other:
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.
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.
MonadBFT employs a stake-weighted, deterministic leader schedule within fixed 50,000-block epochs (~5.5 hours) to ensure fairness and predictability:
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.
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).
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:
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.
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.
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.
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:
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).
After the parallel execution, Monad checks each PendingResult in order (serially).
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:
Monad assumes all transactions can run simultaneously and corrects conflicts afterward:
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:
For example:
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:
New state: Pool A’s balances are updated, Tom’s balances are updated.
New state: NFT contract state is updated, Jordan owns the new NFT.
New state: Alice and Eve’s MON balances are updated.
New state: Pool A’s balances are updated again, Paul’s balances are updated.
After committing all transactions, the blockchain reflects:
Monad enhances speed via speculative execution, where nodes process transactions in a proposed block before full consensus:
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.
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
Role in Execution
MonadDB integrates with Monad’s execution model:
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:
Monad transparently addresses this trade-off:
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:
This targeted forwarding reduces network congestion, ensuring fast and reliable transaction inclusion.
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.
