Mirrored from https://x.com/nvthnh/status/2000876359179231303

Executive Summary

RISE and Hyperliquid represent two distinct architectural paths toward high-performance on-chain trading. By creating a dedicated L1 where its HyperCore orderbook operates directly within consensus, Hyperliquid provides centralized exchange-grade throughput, reaching over 200,000 orders/s with sub-200ms latency. Its design focuses on specialization: a HyperEVM for smart contracts and the HyperCore + HIP-3 framework for permissionless market deployment. This separation limits synchronous composability.

On the other hand, RISE approaches universality rather than specialization. Built as an Ethereum L2, it inherits Ethereum’s security that achieves 3ms latency and 100,000+ TPS natively within the EVM. By integrating orderbook and DeFi primitives directly into the execution environment through its MarketCore layer, RISE enables atomic composability and unified liquidity across all applications without capital barriers or async integrations.

RISE Evolution: From EVM to Programmable Markets

RISE represents an evolution in how we revolutionize the blockchain infrastructure for finance. Rather than building another orderbook DEX isolated from EVM DeFi, RISE reimagines the entire stack by treating high-performance trading primitives as fundamental infrastructure alongside the execution layer itself. The RISE Evolution demonstrates this layered approach.

RISE EVM - Performance Breakthough

Ethereum's current limitations are well acknowledged: slow and sequential execution. Although L2 projects like Optimism or Arbitrum have scaled Ethereum drastically, they are still bounded by the single-threaded execution. RISE tackles the execution bottleneck with incremental block building (i.e. Shreds), continuous block pipelining (CBP), and a highly-performant parallel EVM engine.

RISE offers lightning fast transactions with as low as 3ms latency, and is on track to surpass 100,000 transactions per second throughput. This enables real-time applications like on-chain orderbooks, money markets, and gaming.

Low-Latency Engine: CBP, Shreds & EIP-7966

Traditional blockchains produce discrete blocks at fixed intervals (e.g., 1-2 seconds for fast chains, 12 seconds for Ethereum). The CBP enables continuous transaction processing, and Shreds break this stream into millisecond segments that provide near-instant feedback to users. When a user submits a transaction, it enters the mempool and is executed immediately. Within 3-10ms, a Shred is produced as a preconfirmation for a batch of transactions it contains.

Furthermore, we authored EIP-7966 to introduce a synchronous JSON-RPC method that streamlines transaction submission and receipt retrieval. Traditional async methods require polling loops to check transaction receipt, which increases latency overhead. EIP-7966 eliminates this polling, reducing total submission-to-confirmation time by approximately 50% and simplifying client logic. This means dApps and wallets can submit transactions and receive receipts in a single request-response round trip.

Parallel EVM: Not all Transactions are Dependent

The fundamental insight enabling RISE's breakthrough performance is simple yet powerful: not all transactions are dependent on each other. Traditional EVMs executes transaction sequentially even when they touch unrelated states. RISE parallel EVM (pevm) addresses this by enabling concurrent processing of EVM transactions while maintaining deterministic outcomes.

The critical advantage of pevm's approach is universality. It does not require application-specific optimizations or native implementations for performance-critical operations. Every application benefits equally from parallel execution. Developers get performance improvements for free, without architectural constraints or specialized APIs.

RISE MarketCore: The Trading Innovation Layer

MarketCore implements orderbook and DeFi primitives at the infrastructure layer rather than at the application layer, fundamentally changing what developers can build. The traditional approach implements DEX applications on top of smart contracts, which run on the EVM. Every DEX reimplements matching logic, manages its own liquidity, and operates as a standalone application. RISE maintains a suite of DeFi primitives alongside the EVM, directly accessible to any smart contract through standard interfaces.

RISE MarketCore also sets to provide a unified liquidity layer. Rather than fragmenting liquidity across isolated DEX applications, MarketCore consolidates orderbook depth at the network level. The capital efficiency gains are enormous. For example, limit orders with 20% away from market price (which is unlikely to execute short-term) can earn yield in lending markets while remaining available for trade execution. New DeFi protocols (e.g, aggregators, lending) launch with day-one access to network-wide liquidity depth, eliminating costly bootstrapping. Protocols can focus on unique value propositions rather than duplicating liquidity infrastructure.

RISE vs Hyperliquid: Bringing Composable Liquidity to Ethereum

Now that we understand RISE's architecture, let's systematically compare it with Hyperliquid, the platform that proves high-performance on-chain trading is possible.

RISE MarketCore vs HyperCore + HIP-3

HIP-3: Opening HyperCore to Builders

HyperCore implements the orderbook outside the EVM execution environment, which is precisely what enables its impressive performance. Hyperliquid achieves performance that rivals centralized exchanges: 200,000 orders/s throughput and sub-200ms latency.

HIP-3's model is powerful in its simplicity: builders stake 500,000 HYPE, configure market parameters, and deploy. They receive 50% of trading fees (users pay 2x standard fees), and validators enforce operational standards through slashing mechanisms. The builder does not operate infrastructure, they leverage HyperCore's engine and simply set configuration instead.

This approach offers several advantages, mainly the simplicity, but it also has limitations.

• The 500,000 HYPE stake (~$20M) ensures quality but limits experimental deployment to well-capitalized entities. The 2x fee structure compensates deployers but makes HIP-3 markets structurally more expensive than validator-operated ones.
• More significantly, since HyperCore is optimized as a specialized application separate from HyperEVM, it cannot be composed synchronously within smart contracts. Builders can deploy markets with custom parameters, but the orderbook remains an async integration point for smart contracts rather than a primitive they can invoke atomically. We will discuss this later.

RISE MarketCore: Composable Orderbook Primitives

RISE targets permissionless innovation from two complementary angles: 1) enabling developers to build applications that directly compose with orderbook primitives; and 2) building toward permissionless perpetual market deployment similar to HIP-3.

Today: Composable Liquidity Infrastructure. MarketCore lives inside the RISE EVM and serves as a liquidity infrastructure, accessible to any smart contract through standard interfaces. There is no special deployment process for using MarketCore, it’s a normal contract deployment. MarketCore is infrastructure, like ERC-20 token standards or native ETH transfers, that any application can use. Developers might build prediction markets using orderbook price discovery, perpetual platforms with custom margin models, yield strategies rotating between AMM and orderbook liquidity, or structured products packaging orderbook positions with lending and options.

Future: Permissionless Market Deployment. Recognizing the HIP’s proven success, MarketCore’s roadmap also aims to provide such capabilities. The aspiration is to allow builders to spin up new perpetual markets on MarketCore's infrastructure. The specific mechanisms are still being designed and will be announced as the protocol matures.

Last but not least, a crucial difference emerges from MarketCore's infrastructure positioning: unified liquidity across all applications building on RISE. When a lending protocol, DEX, options vault, and prediction market all access the same liquidity infrastructure, they collectively contribute to and benefit from shared liquidity depth. On RISE, every application accessing MarketCore contributes to the same unified liquidity pool.

Execution Environments: Universal High Performance vs Specialized Architecture

HyperEVM: Protecting Trading Performance

Hyperliquid's HyperEVM provides EVM-compatibility while protecting HyperCore's trading performance through a carefully designed dual-block architecture. This architecture reflects a clear philosophical choice: HyperCore's trading performance is exceptionally high, and the EVM serves as a protocol extension layer rather than competing for resources. HyperEVM uses standard sequential execution without parallelization, keeping EVM throughput conservatively below HyperBFT's total capacity to ensure processing capacity for HyperCore.

RISE EVM: Universal High Throughput

Unlike HyperEVM, RISE EVM is optimized to achieve the trading-grade performance universally. RISE makes the EVM fast enough for RISEx orderbooks to operate within the same execution environment as other applications. As a result, every transaction benefits from the optimized EVM, whether it is a complex DeFi strategy, an orderbook trade, or a gaming state update.

RISEx operates as EVM-native smart contracts within the same execution environment, benefiting from parallel optimization like any other application. For example, a lending protocol integrating orderbook liquidations uses standard Solidity function calls with atomic execution guarantees. Nevertheless, developers get predictable gas costs at high capacity. Trading, lending, options, and yield strategies compose atomically without special-case integration patterns.

Another critical advantage of RISE EVM's approach is latency. Shreds deliver user-facing latency that feels instantaneous. This offers significantly faster response time than Hyperliquid's already-impressive sub-200ms latency, creating a Web2-like experience where every action feels immediate.

Composability: From High-Performance Trading to Programmable Liquidity

Hyperliquid's Read-Synchronous, Write-Asynchronous Model

Hyperliquid's composability model reflects its performance-first architecture. HyperCore operates separately from HyperEVM, and the boundary between them creates an asynchronous interface for write operations while maintaining synchronous reads.

• Smart contracts can query HyperCore state directly through precompiled contracts (e.g., reading positions, mark prices, orderbook depth, etc).
• However, write operations (e.g., placing/canceling orders) happen asynchronously through the CoreWriter system contract. When a smart contract calls CoreWriter to place an order, the EVM transaction succeeds immediately, but the actual HyperCore execution happens in the next L1 block. The EVM transaction does not revert if the orderbook action fails.

Together, this creates a development pattern that requires developers to have careful and complicated handling of composability flow.

RISE's Synchronous Atomic Execution

RISE's synchronous model groups multi-step operations into a single atomic transaction and the entire flow happens atomically. Either the entire operation fully succeeds or it fully reverts. This is possible because the MarketCore consists of a suite of Solidity contracts that live inside the RISE EVM. This means that any other contract on the RISE EVM can directly call MarketCore’s contracts in an atomic way.

The synchronous composability advantage becomes most apparent in sophisticated strategies. Consider an automated market maker that wants to hedge AMM inventory with orderbook positions whenever large swaps create directional exposure. On an async platform, this requires multi-transaction orchestration with observable intermediate states that create MEV opportunities. On RISE, the entire hedge executes atomically in the same transaction as the AMM swap (i.e, either both succeed or both revert) with no intermediate state for MEV extraction.

Security Model: Ethereum-Backed vs Custom Consensus

Hyperliquid: External BFT Consensus

Hyperliquid's security model reflects its focus on performance. HyperBFT consensus operates with 23 validators selected by delegated stake to meet sub-200ms latency requirements. The Hyper Foundation controls 78.54% of staked tokens and operates 5 validators directly while delegating stake to others.

RISE: Ethereum-Inherited Security

RISE inherits Ethereum's security model from day one through optimistic rollup architecture. Every state transition gets proven back to Ethereum L1, with fraud proofs. The current limitation is RISE's centralized sequencer, which is common to early-stage rollups. That is, a single entity ordering transactions and producing blocks. This creates trust assumptions around liveness and fair ordering.

Fortunately, based sequencing addresses this gap by making Ethereum L1 validators themselves the sequencer. RISE transactions will be included in the same ordering process as L1 transactions, with L1 validators earning sequencing fees. This, in turn, will remove the centralized sequencer entirely, replacing it with $100B+ economic security, and global censorship resistance.

Bridge Security

The bridge security models also differ significantly. Hyperliquid uses a 2-of-3 multisig controlling all bridged assets. The risk is that compromising 2 signers would enable unauthorized withdrawals.

RISE utilizes trustless bridging mechanism between RISE EVM <> Ethereum with 7-day challenge periods (and there is potential to reduce this to 1 day). This eliminates multisig trust assumptions and allows anyone to challenge invalid bridge or rollups operations during the challenge window. No small set of signers controls withdrawals.

The Promising Future: Based Sequencing + ZK Transition

Based Sequencing: Decentralization Without Compromise

Most L2s launch with centralized sequencers for operational simplicity during growth phases, and RISE also adopts this path. However, RISE has a plan to transition to a based sequencing model to eliminate centralized risks.

In this model, when validators produce L1 blocks, they can include RISE batches alongside regular Ethereum transactions, earning sequencing fees as additional revenue. This makes L1 validators the sequencer, eliminating centralized control entirely.

As a result, RISE inherits Ethereum's full decentralization with 1M+ validators responsible for ordering; censorship resistance and liveness guarantees come from Ethereum consensus itself.

ZK Rollup Transition: The Ethereum Composability Vision

The current optimistic rollup model requires 7-day withdrawal periods for challenge windows. ZK rollups replace fraud proofs with validity proofs that Ethereum can verify instantly. With this transition, near-instant withdrawals become possible: withdrawals complete in seconds bounded by proof generation.

More importantly, ZK proofs and based sequencing, together, enable synchronous L1 <> L2 composability. This transforms RISEx from RISE's MarketCore into Ethereum's MarketCore: a liquidity primitive for the entire Ethereum ecosystem. Every L1 DeFi protocol could use RISEx for atomic liquidations.

However, the technical challenges are non-trivial. ZK proof generation is computationally intensive and maintaining RISE’s performance while adding ZK proving requires significant engineering. Fortunately, the ZK landscape evolves rapidly with proof aggregation, hardware acceleration, etc. What seems limiting today may be entirely possible within RISE's development timeline.

Conclusion

Hyperliquid and RISE represent two sophisticated but fundamentally different answers to the question: How do we bring high-performance trading on-chain? Hyperliquid achieves this through a specialized HyperCore running at 200,000 orders/s on an isolated L1, with async composability to maximize trading performance. RISE optimizes the EVM itself for universal high performance, 100,000+ TPS with 3ms preconfirmations and synchronous composability, while positioning MarketCore as the infrastructure layer with unified liquidity across all applications. Both push boundaries of decentralized trading infrastructure, serving different market needs in a multi-architecture future rather than competing head-to-head.