HyperRAM

HyperRAM = hyper-efficient DEX + x(3,3) + HyperEVM native integration.

The vision for Ramses is simple: build the most efficient exchange possible, keep captured value within the protocol, and allocate it through participant incentives, compounding, or supply reduction according to each module's rules. With significant portions of the initial supply dedicated to the community through RXP points and other rewards programs, Ramses prioritizes community-first development and sustainable value creation.

Hyper-efficient

Maximum value capture, minimal leakage. Ramses combines dynamic fees that respond to market conditions with permissioned MEV infrastructure designed to capture eligible opportunities. Captured value remains within the protocol and is allocated under the active module's documented rules.

Planned HyperCore integration is intended to support atomic execution between Hyperliquid spot markets and Ramses. The roadmap also includes broader cross-venue arbitrage integrations.

Security reviews, contests, and bounties help reduce risk, but they do not eliminate it. See the security reviews and risk disclosures before interacting with the protocol.

HyperEVM Native Integration

On HyperEVM, users can select a HYPE-denominated AutoVault that converts its allocated rewards into HYPE from the market. Fee allocation depends on gauge state: gauged-pool swap fees go entirely to voters for those pools, while ungauged-pool swap fees are split 95% to liquidity providers and 5% to the protocol/Sarcophagus.

Ramses prioritizes community-first development and sustainable value creation. The Hyperliquid community allocation represents 30% of the initial supply: 20% for the initial NFT and PiP allocation and 10% for incentives, including 3% for RXP. See the full token distribution.

x(3,3)

x(3,3) is a more accessible version of ve(3,3) that aligns participation with value creation rather than forced lockups. To understand how x(3,3) works, first consider ve(3,3):

ve(3,3)

The Solidly model, introduced by Andre Cronje, brought together two key concepts:

Vote Escrow (ve)

Curve's 2020 innovation introduced time-weighted voting. Instead of voting with liquid tokens, users lock tokens in a VotingEscrow for a selected period; longer locks grant more governance power.

Rebase

An anti-dilution mechanic inspired by OHM (3,3) where locked positions rebase as emissions are distributed, helping veTOKEN holders maintain their ownership share without buying and locking more tokens.

Modern implementations have proven ve(3,3) can achieve massive scale, but they rely on artificial restrictions: forced lock-ups create high friction and unfair access to rewards. Users must make upfront commitments to participate equitably, creating a system driven by obligation rather than ongoing value.

ve(3,3) → x(3,3)

ve(3,3) has a fundamental design flaw: it relies on static commitment rather than dynamic value creation. Even the most successful ve(3,3) exchanges still require users to make upfront commitments to earn meaningful rewards, creating a system where participation is driven by obligation rather than ongoing value. x(3,3) flips this entirely—it rewards users based on their active contribution to protocol success, with exit flexibility that ensures only those who genuinely value the protocol remain engaged. This creates a self-selecting community of active participants rather than passive token holders who do not participate.

Without an exit measure, the system accumulates dead voting power, as users hold veTOKENs indefinitely without active participation, still influencing the protocol without contributing to its success.

Burns

This shift from static to dynamic participation requires a fundamentally different approach to dilution protection. Instead of minting new tokens to locked positions, x(3,3) introduces a burn mechanism—a deflationary system that protects remaining holders while enabling flexible participation (50% burn when RAM → xRAM, exit anytime).

This creates a self-reinforcing cycle: as users convert RAM into xRAM, 50% of each converted RAM amount is burned. Remaining holders benefit from the resulting supply reduction, while users retain the flexibility to exit xRAM.

1. Deflation scales with the protocol (user activity)
   • Strong incentive to stay instead of lock-ups
2. Removes the need for locks or wrappers
   • xRAM solves the need for token lock-ups
   • hyperRAM (Liquid staked xRAM) solves the need for liquid wrappers

Burn vs Rebase

In a model where conversions happen often, burning is more efficient than rebasing:

Trilemma

The history of decentralized finance has been marked by repeated attempts to solve the "DEX Trilemma"—the challenge of aligning incentives between traders, liquidity providers, and token holders. While the ve(3,3) model sought to balance incentives between participants, long lockups created a high-friction system that required users to lock tokens to participate fully in the incentive model.

Credit to the Aerodrome team for the original graphic and concept.

Uniswap focused on a simple two-party system: traders and liquidity providers (LPs). ve(3,3) improved this by properly aligning incentives with token holders as well, but access to those incentives was unfair and heavily skewed towards protocols.

x(3,3) model

xRAM is where x(3,3) shines by creating an incentive system that responds to real user behavior. While ve(3,3) exchanges create value through artificial scarcity and forced commitments, x(3,3) instead generates value through genuine user activity and captured value. When xRAM is minted, the burned tokens protect remaining holders from dilution. This creates a dynamic system where ownership naturally concentrates among those who contribute most value.

Exit Options

Ramses separates the conversion burn from exit flexibility. When xRAM is minted, 50% of the RAM being converted is burned, permanently reducing circulating supply. Exiting does not burn additional RAM. Users can exit their position anytime to realize the remaining 50% backing:

1. No lock-ups required - Exit anytime
2. Deflationary protection - Burns reduce supply for remaining holders
3. Liquid alternative - hyperRAM provides instant liquidity through open market trading

The combination of xRAM (direct participation) and hyperRAM (liquid staking) removes the need for complex ve-token wrappers while maintaining strong alignment incentives.

The result? A more fluid and accessible system that provides strong incentives while removing the friction of ve-token models (token lock-ups).

Directing Emissions

As discussed in DEX Trilemma, prior to ve(3,3) users had no choice but to suffer from misaligned incentives from centralized parties. This led to inefficient capital allocation and reduced long-term sustainability for exchanges. x(3,3) solved this by putting emission control directly in the hands of xRAM stakers who are incentivized to optimize for value.

Directing emissions is an extremely powerful use case for xRAM stakers as it gives holders primary power over what the platform incentivizes. Combined with swap-fee rewards and MEV modules that retain value within the protocol, this creates a feedback loop where voters are incentivized to direct emissions to the most productive liquidity: those pools that generate the most fees, trading volume, and arbitrage opportunities.

Less rewards from the pool = less emissions = less liquidity.

Each week, during a protocol epoch, xRAM stakers choose which liquidity pools receive RAM emissions. Voting closes every Thursday at 00:00 UTC, and emissions are allocated according to the result. Read more about voting and emission distribution.

Voters earn swap fees and vote incentives in a lump sum immediately after epoch flip. These rewards are based on the liquidity you voted for in the previous epoch. If you vote for a liquidity pool in Epoch X, you will receive your accumulated rewards instantly when Epoch Y begins, proportional to your vote compared to the total votes.

Vote Incentives

On Ramses we utilize two different types of vote incentives: liquidity pool incentives & voter incentives. A vote incentive can be in the form of ANY whitelisted token. As a protocol, incentivizing your liquidity will attract voters and result in higher directed emissions. As an xRAM staker, you earn a portion of the incentives.

A voter incentive can be designated at any time during the current epoch and is paid in a lump sum to xRAM voters. Once added, it remains visible and can influence votes until the epoch rolls over.

A liquidity incentive is another method protocols can use to attract liquidity provision. This incentive is distributed directly to liquidity providers and is a great way to bootstrap new liquidity on the platform.

Fees

Ramses' x(3,3) model takes a straightforward approach to fee distribution:

• 100% to xRAM voters on gauged pools - Gauged-pool swap fees flow to the voters for those pools
• 95% to LPs and 5% to the protocol/Sarcophagus on ungauged pools - Ungauged-pool swap fees retain the default LP and protocol split
• MEV value - Captured value from privileged infrastructure follows module-specific rules, including RAM burns and hyperRAM compounding

This creates a powerful flywheel where:

1. High-performing pairs generate more fees and MEV opportunities
2. xRAM stakers are incentivized to vote for productive liquidity
3. Increased emissions attract deeper liquidity
4. Deeper liquidity drives more volume, fees, and arbitrage opportunities

Fee-Split

Fee splits can be configured per gauge. The default pool swap-fee states are:

Dynamic Fees

Ramses' algorithm adjusts fees based on market conditions and trading volume. The goal is to reduce adverse selection during volatile periods while keeping fees competitive in stable markets.

Below is a visual of Ramses' dynamic fees versus other exchanges:

While dynamic fee mechanisms are not entirely novel, Ramses' algorithm uses market data to adjust fees. The roadmap includes deeper integration across HyperEVM, HyperCore, and other venues. Learn more about the current and planned MEV protection mechanisms.

Real-Time Market Protection

The algorithm is designed to adapt its parameters on sub-minute time scales. Faster adjustments can increase fees during volatile periods, but they do not eliminate inventory loss, adverse selection, or other liquidity-provider risks.

During volatile periods, the central objective is to shield LPs from excessive toxic flow while simultaneously capturing the highest possible trading fees. The algorithm continuously monitors:

• Relative liquidity distributions across venues
• Price deviations and typical trade sizes
• Real-time on-chain and market data
• Cross-venue volume patterns

During stable markets, the focus shifts toward maintaining a smooth trading experience and optimizing fee collection from non-toxic order flow. Since we continuously compete with other DEXs for volume, maintaining an optimal balance between fee level, liquidity depth, and spot price is crucial.

Our team continuously monitors and optimizes the algorithm, implementing specialized algorithms for different pool categories including volatiles, stables, LST (Liquid Staking Tokens), and meme pools, with novel approaches that account for trading patterns, redemption mechanics, liquidity cycles, and cross-protocol dynamics.

Big Blocks

HyperEVM uses a dual-block architecture that balances transaction speed and capacity. This design allows for both rapid confirmations and the handling of larger, more complex transactions.

Small blocks are ideal for simple swaps, standard token transfers, and quick transactions that require fast confirmations. Big blocks accommodate complex operations like deploying large smart contracts, adding liquidity to concentrated liquidity positions, and transactions that exceed the small block gas limit.

Big-Blocks Auto-Switch

Ramses automatically toggles between small and big blocks based on transaction complexity, eliminating the need for manual configuration.

The system analyzes transaction size and complexity in real time, switching between block types in the background. When a transaction requires big blocks, the system automatically:

1. Disables small blocks
2. Executes the transaction on big blocks
3. Re-enables small blocks after completion

No more manual toggling—just sign your transactions. Enable "Big Blocks Auto-Switch" in your Ramses settings to activate this feature.

Fix Big Blocks Errors

To utilize big blocks, you need:

1. A HyperCore user account - Created by having a spot balance on HyperCore
2. HYPE on HyperCore - HYPE tokens on Core to pay for the evmUserModify action that enables big blocks

The evmUserModify action that sets usingBigBlocks: true runs on HyperCore, which is why HYPE on the Core account is required. For actual big block transactions on HyperEVM, you'll also need HYPE on EVM for gas fees.

If you're encountering errors with big blocks, follow these steps:

1. Navigate to Hyperliquid Portfolio
2. Click "EVM <-> Core Transfer"
3. Transfer 0.1 HYPE from EVM → Core (needed for the evmUserModify action)
4. Enable Big Blocks or Big Blocks Auto-Switching in the UI.