1. Can Consensus Fix Blockchains?

Consensus mechanisms ensure every computer in the network agrees on which transactions are consistently and securely validated and added to the blockchain, based on a set of consensus rules.

Every blockchain tries to achieve a balance with respect to the blockchain trilemma: balancing speed, security, and decentralization. Projects can often only prioritize two features at the expense of a third.

Consensus mechanisms are essential in preventing malicious actors from successfully tampering with the network or its data. They prevent double-spending and keep everything in sync, while ensuring that each node in the blockchain produces the same sequence of transactions for each block.

Think of them as the rules of a decentralized game, steering participants toward a unified “truth”. Here’s a rundown of key consensus mechanisms:

Proof of Work (PoW): Miners solve complex puzzles with computational power to add blocks, and they are rewarded with cryptocurrency. It’s secure but energy-heavy and slow (e.g., Bitcoin, pre-2022 Ethereum).

Proof of Stake (PoS): Validators stake cryptocurrency for a chance to create blocks. This method is energy-efficient and faster but may favor wealthier participants (e.g., post-2022 Ethereum, Cardano).

Delegated Proof of Stake (DPoS): Token holders vote for delegates to validate transactions, offering speed and scalability but risking centralization (e.g., EOS, Tron).

Proof of Authority (PoA): Trusted nodes validate based on identity, making it fast and efficient but less decentralized (e.g., VeChain).

Despite the promise of decentralization brought forward by blockchains, these rarely translate into the expected performance, especially for blue chips:

Bitcoin averages 7 transactions per second (TPS).

Ethereum post-PoS hits 15–30 TPS.

Visa, by contrast, averages 1,700 TPS daily.

These gaps spark delays, congestion, and high fees, exposing scalability challenges.

1.2 New Consensus Models

Emerging Layer-1s (L1) like @Hyperliquidx, @Monad_xyz, and @Soniclabs are leading to new consensus mechanisms specifically designed to solve these challenges, boosting speed, scalability, and impact while fostering trust.

This article offers an in-depth examination of how these projects tackle the blockchain trilemma, advancing consensus design further. We delve into each project’s background, consensus mechanisms, relationship with Ethereum, scalability solutions, practical applications, approaches to funding and governance, and primary challenges.

2 Hyperliquid

Hyperliquid is an L1 blockchain built for high-speed, low-cost decentralized trading. It splits into two pillars:

HyperCore: an on-chain engine for perpetual futures and spot order books with one-block finality.

HyperEVM: an Ethereum-compatible smart contract platform.

While traditional L1s face trade-offs between decentralization, performance, and accessibility, Hyperliquid seeks to overcome these challenges by offering a high-performance, fully on-chain trading ecosystem.

HyperCore can process up to 200,000 orders per second, a theoretical peak set to grow with node software upgrades.

HyperEVM introduces Ethereum’s smart contract platform to Hyperliquid, offering HyperCore’s liquidity and financial tools as open resources.

With HyperCore and HyperEVM, the team aims to enable seamless interaction between decentralized applications (dApps) and blockchain components without sacrificing efficiency or user experience.

2.1 Consensus Mechanism

Initially, Hyperliquid employed the Tendermint consensus algorithm. However, a more advanced solution was necessary to support high-frequency trading better and achieve higher transaction throughput.

To address this, Hyperliquid developed a consensus mechanism called HyperBFT. This hybrid system combines PoS with Byzantine Fault Tolerance (BFT), and is optimized for high throughput, low latency, and robust security.

The PoS model is based on the HotStuff protocol, where validators generate blocks by staking $HYPE tokens. HyperBFT’s hybrid approach is more energy-efficient than traditional PoW methods, while maintaining robust security.

2.2 Scalability and Speed

HyperBFT achieves a median finality of 0.2 seconds and latency under 0.9 seconds. The on-chain order book mimics centralized exchange precision, supporting 50x leverage, one-click trading, and stop-losses.

Hyperliquid excels in high-throughput scenarios, processing 200,000 TPS concurrently without sharding. This is currently limited mainly by network latency and validator spread.

2.3 Challenges

Low number of validators (security): Hyperliquid is relatively centralized, with only 16 validators compared to Ethereum’s vast network of 800k+ validators. They aims to expand its validator set as the network grows, aligning with its decentralization goal.

Untested resilience against major cyberattacks, raising questions about its long-term decentralization and robustness. This centralization poses security risks, especially concerning the $2.3 billion $USDC in the bridge, targeted in a 2024 hacking attempt.

Centralization impact: In March 2025, Hyperliquid faced an incident with the $JELLY token. A trader manipulated the platform’s liquidation system by creating three accounts and taking leveraged positions: two long totaling $4.05 million and one short of $4.1 million in $JELLY futures. This led to a 400% price spike and the trader self-liquidated, causing Hyperliquid’s vault to assume a $6 million short position. This resulted in unrealized losses for liquidity providers, estimated between $700,000 and $10 million. However, after Hyperliquid’s intervention, the vault made a $700,000 profit, as Hyperliquid ended up delisting the $JELLY contract, sparking debates about decentralization and governance transparency.

High-Leverage trading risks: on March 13, 2025, a whale liquidated $ETH long positions through high-leverage trading, resulting in a loss of approximately $4 million in the HLP Vault. Such events highlight the platform’s vulnerability to market manipulation and the need for robust risk management strategies.

Competition: Hyperliquid’s closed-source code and absence of automated validator penalties limit transparency and resilience. Competition from high-throughput platforms like Solana, emerging L1s such as Monad and MegaETH and advanced DEXs like dYdX presents challenges.

Scalability: Hyperliquid is engineered for scalability, handling up to 200,000 TPS with sub-second finality. However, extreme conditions such as massive leveraged trades may introduce challenges like liquidity strain or validator coordination delays.

3. Monad

Monad is an EVM-compatible L1 for scalability and performance, using parallel execution and MonadBFT.

Monad targets up to 10k TPS with blocks produced every 500 msec and finalized in one second. It promotes decentralization while tackling Ethereum’s bottlenecks (e.g. slow speeds, high fees, and limited scalability). Its testnet launched February 19, 2025, with speculation about mainnet launch in Q3-Q4 2025.

3.1 Consensus Mechanism

Monad’s architecture centers on its custom MonadBFT consensus mechanism, an optimized evolution of the HotStuff BFT protocol .

It integrates pipelined execution and efficient communication to distinguish itself from traditional blockchain designs.

MonadBFT: This algorithm turns HotStuff’s three-phase process into two, improving validator speed. Validators rotate as leaders: one proposes a block and gathers prior votes into a quorum certificate (QC), a consensus proof to certify the previous block. A timeout mechanism keeps the network robust if a leader fails, ensuring security in partially synchronous settings.

Parallel Execution: Parallel execution refers to the ability to process multiple tasks or transactions simultaneously, rather than one at a time. Nodes agree on transaction order first, then execute transactions concurrently across multiple threads using an optimistic approach. This ensures consistency with sequential outcomes while significantly boosting throughput.

PoS: Validators stake tokens to participate, securing the network through economic incentives. This PoS system balances speed and security, with staked assets discouraging malicious actions.

MonadBFT delivers scalable, reliable finality for real-time dApps by reducing communication overhead,

The diagram below illustrates MonadBFT’s pipelining process, showing how validators (Alice, Bob, Charlie, David, etc.) propose, vote on, and finalize blocks (N, N+1, N+2, etc.) across overlapping rounds.

Each block progresses through stages: proposed, voted, and finalized. Validators rotate leadership, producing QCs to certify blocks.

3.2 Scalability and Speed

Monad combines MonadBFT’s efficiency with parallel execution, allowing it to outperform traditional L1s by handling transactions concurrently, avoiding sharding, and ensuring quick finality. Its theoretical capacity could go higher than mentioned above (10k TPS, sub-second finality), though real-world results depend on network latency and validator spread.

3.3 Challenges

Execution Complexity: Monad’s optimistic parallel execution could lead to inconsistencies, rollbacks, or vulnerabilities (e.g., edge-case exploits). Its advanced features (MonadBFT and parallel execution) add complexity, increasing development and maintenance costs, particularly for smaller teams. This may hinder growth and security, challenging smaller teams and making it favored by teams with more resources and development experience.

Network Latency: Real-world TPS and finality rely on validator distribution and latency, risking underperformance.

Untested Scale: Pre-mainnet, Monad’s 10,000 TPS claim remains unproven, with possible bugs or bottlenecks.

Competition: High-throughput platform rivals like Sonic, Arbitrum, and Solana, could challenge developer and user adoption.

Learning Curve: Despite EVM compatibility, Monad’s unique systems (MonadBFT, MonadDB) may slow developer onboarding.

Centralization: Early Foundation control and a concentrated token model could centralize power, threatening long-term decentralization and security.

4. Sonic

Sonic is an EVM-compatible L1 for high throughput and sub-second transaction finality, evolving from the Fantom Opera ecosystem.

Sonic introduces notable operational enhancements: its latest consensus protocol, SonicCS 2.0, achieves a 2x increase in consensus speed and a 68% reduction in memory usage per epoch (from 420 MB to 135 MB), lowering resource demands for validators and improving scalability.

These upgrades tackle several blockchain challenges:

Slow transaction processing

High operational costs

Fragmented ecosystems

With a rebranded identity, Sonic incentivizes developers by redistributing up to 90% of network transaction fees through its Fee Monetization program (FeeM), fostering dApp creation and adoption.

4.1 Consensus Mechanism

Sonic’s Lachesis Consensus blends Directed Acyclic Graphs (DAGs) with Asynchronous Byzantine Fault Tolerance (ABFT), advancing beyond Fantom Opera’s foundation.

ABFT: allows validators to process transactions and exchange blocks asynchronously. This eliminates the sequential delays of Practical Byzantine Fault Tolerance (PBFT)-based systems, enhancing throughput and resilience.

DAG: Transactions are represented as vertices and dependencies as DAG edges, enabling concurrent block additions. This accelerates validation compared to linear blockchain designs, forming an interconnected web-like structure rather than a single chain.

PoS: Validators stake a minimum of 500k $S tokens to participate, batching transactions into event blocks within local DAGs. Consensus is reached when sufficient validators confirm these blocks as “roots” on the main chain, achieving sub-second finality. This PoS system balances speed, security, and decentralization, with staked tokens deterring misconduct.

The figure below illustrates a DAG for a specific node:

Orange events represent candidate leader events

Yellow events indicate committed leader events.

The events positioned between these leaders can be sequenced into a chain, enabling the extraction of a transaction list to construct a block.

4.2 SonicCS 2.0 - Their latest Consensus Mechanism upgrade

Sonic recently upgraded its consensus mechanism with SonicCS 2.0, introduced on March 27, 2025. This protocol leverages a DAG-based approach with overlapping elections, reducing computational effort and memory usage by 68%. Experiments with 200 epochs of Sonic mainnet data demonstrate a 2.04x average speedup (ranging from 1.37x to 2.62x) and significant memory efficiency, reinforcing Sonic’s capacity to process over 10k TPS with sub-second finality. SonicCS 2.0 is set to roll out to the mainnet soon, with a detailed technical report forthcoming.

4.3 Scalability and Speed

Sonic’s hybrid Lachesis consensus merges DAG’s adaptability with ABFT’s integrity, delivering rapid, secure transaction finality without requiring sharding. This design supports seamless scalability as network demand grows.

SonicCS 2.0 can potentially push the performance of Sonic mainnet closer to theoretical estimates of 396,825 TPs. However, it’s good to point out that practical results hinge on network latency and validator distribution. According to @AndreCronjetech the maximum realtime TPS measured on Sonic was already around 5,140, which is quite impressive.

Sonic is fully EVM compatible, optimizing performance within this framework rather than replacing it with a distinct virtual machine. SonicCS 2.0’s vectorized operations and overlapping elections enhance validator efficiency and dApp performance.

Source: Chainspect

4.4 Challenges

Consensus Complexity: Under high load, Sonic’s consensus mechanism may introduce intricate dependencies or validation delays, risking inefficiencies or exploits.

Developer Adaptation: While EMV-compatible, Sonic’s advanced features (e.g., SonicCS 2.0’s vectorized voting) may require developers to adjust workflows, potentially slowing adoption.

Network Latency: Sub-second finality and 10k TPS depend on validator distribution and latency, which could degrade real-world performance.

Untested Scale: Pre-SonicCS 2.0 mainnet rollout, the 10k TPS claim lacks full real-world validation and possible bottlenecks or bugs have yet to emerge.

L2 Dominance: Ethereum’s L2 solutions (e.g., Optimism, zkSync) offer similar performance at lower costs, leveraging vast liquidity and developer ecosystems. Sonic’s Sonic Gateway bridge aids interoperability, but competing as an independent L1 remains challenging.

Centralization: The 500,000 $S staking requirement and early control by the Sonic Foundation risk centralizing power, potentially alienating decentralization-focused users and weakening security if token distribution favors insiders .

5. Comparison Table

6. Harnessing Ethereum’s Ecosystem

Hyperliquid, Monad, and Sonic all leverage EVM-compatibility, enabling developers to deploy dApps on high-speed infrastructure using familiar tools and smart contracts. This delivers low-cost, high-throughput transactions with robust security, tapping into Ethereum’s ecosystem without code rewrites.

Powering Diverse dApps

These L1s offer sub-second confirmation times and high TPS capacity, making them ideal for a wide range of dApps that can seamlessly deploy.

Hyperliquid offers fast, secure DEX transactions with an on-chain order book, matching centralized exchange precision with high scalability.

Sonic adds rapid finality for efficient DeFi applications, securing transactions in under a second.

Monad enhances this with 10,000 TYPS, 1-second block times, and single-slot finality.

Beyond Web3: Enterprise Potential

These networks’ speed and scalability position them for enterprise use in finance, supply chain, and payments. Retailers can handle high-volume payments at reduced costs, while healthcare providers secure real-time patient data with compatibility to existing systems.

7. L2 as Ethereum’s Answer to the Scaling Issue

What about L2s?

Why do we need new L1 blockchains with fancy consensus mechanisms in the first place?

L2 solutions like Arbitrum, Optimism, and Base boosted L1 scalability by processing transactions off-chain. Arbitrum achieves up to 4,000 TPS, while Base targets thousands with 0.2-second Flashblocks by mid-2025.

However, L2s depend on Ethereum’s security and finality, inheriting its features and limitations. For instance, the need for fraud proofs in systems like optimistic rollups can lead to delays, since transactions on Optimism’s OP Stack chains become finalized when their data is included in a finalized Ethereum block. This can impact user experience, especially for applications requiring rapid transaction finality.​

New L1 blockchains like Hyperliquid, Monad, and Sonic address these limitations with advanced consensus mechanisms. Unlike L2s, these L1s are highly performant without relying on Ethereum’s infrastructure, avoiding complexities like fraud proofs or L1 block-time bottlenecks.

Yet, building new L1s introduces risks, potentially challenging decentralization or increasing costs. While L1 blockchains provide a base layer of security and decentralization, they often face scalability challenges due to consensus mechanisms and block size limitations. Furthermore, they don’t have the historic performance and trust of Ethereum.

The necessity of developing new L1 blockchains in the presence of existing L2 solutions is an ongoing discussion topic on Twitter:

L2s ease L1 congestion but tie their scalability to Ethereum’s constraints. They are as fast as Ethereum, but this doesn’t take into consideration that all L2 transactions’ finality depend on L1 block confirmation times.

At the same time, new L1s promise independence and speed, but they must prove they can scale securely for billions of users.

The interplay between L1 and L2 solutions raises critical questions about the future architecture of blockchain networks.

Can the scalability challenges of L1 blockchains be effectively addressed through the development of new consensus mechanisms, or is the integration of L2 solutions essential despite their inherent trade-offs?

These considerations underscore the need for ongoing research and dialogue within the blockchain community to navigate the complexities of scalability, security, and decentralization.​

Conclusion and Food for Thought

One major hurdle in the current market is thin and rotating liquidity, affecting both new and existing users. Attention is low and short-spanned, making it even more challenging to secure a growing mindshare in this crowded sector.

Therefore, to drive adoption, it’s essential to prioritize the needs of both developers and users.

But let’s be honest: most users care more about practical functionality than the underlying technology. They want a seamless experience, with fast transactions and low fees that make the network accessible, especially for microtransactions.

Security is also non-negotiable: users expect robust safeguards to protect their assets and data, fostering trust in the system. And, of course, there needs to be stuff to do on chain, which satisfies different types of user needs.

Both L1s and L2s need to fight for these interests to stay relevant. Instead of solely focusing on the “best tech” and trying to “over-improve” the consensus mechanisms of their chain, they should also be pragmatic and focus on offering users and developers the best network to build and use their applications.

To conclude, new L1s, like Hyperliquid, Monad, and Sonic, address L2 dependencies but face challenges, as seen in Hyperliquid’s small validator pool, where just four nodes heightened collusion risks, exposing vulnerabilities. Expanding validators, securing bridges and implementing higher approval thresholds, real-time monitoring, and anomaly detection can bolster resilience. Balancing security, scalability, and decentralization through proactive risk management is key to fostering trust and sustaining DeFi’s growth, urging users to scrutinize platform safeguards and developers to prioritize robust defenses.

Let the “devs do something”: let them do the heavy tech weight and define the consensus mechanisms trade-off, fueling the search for equilibrium.

Also, let’s not forget about users: those who simply enjoy responsive, efficient, decentralized, and secure applications.

These new designs are pushing the boundaries of what consensus models can achieve in terms of pace, security, and interoperability.

It will be interesting to see how they evolve and how they intertwine once Monad (and other competitors) go live.

Disclaimer:

1. This article is reprinted from [Castle Labs]. All copyrights belong to the original author [@cryptorinweb3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. The Gate Learn team does translations of the article into other languages. Copying, distributing, or plagiarizing the translated articles is prohibited unless mentioned.