Ramses on HyperEVM combines a capital-efficient DEX, the x(3,3) incentive model, and HyperEVM-native transaction support.
Ramses uses pool fees, voting incentives, automated strategies, and supply-reduction mechanisms to align traders, liquidity providers, and xRAM participants. The exact allocation depends on each pool and module's current configuration.
Hyper-efficient
Ramses combines dynamic pool fees with an authorized same-chain MEV backrun module on HyperEVM. Dynamic fees can respond to current market conditions, while successful backruns can support RAM buybacks and burns.
| Feature | Description |
|---|---|
| Dynamic fees | Pool fee parameters can respond to current market conditions |
| MEV backruns | Authorized same-chain routes can capture eligible value through atomic execution |
| Buyback and burn | Eligible value retained by the module can be used to buy and burn RAM |
| Execution safeguards | Only approved executors can run backruns; temporary fee settings are transaction-scoped and failed routes revert |
See the live MEV backrun and buyback-and-burn mechanics and published security reviews for current scope and controls.
HyperEVM Native Integration
On HyperEVM, AutoVault users can choose from output tokens currently enabled by the vault contract and shown in the application. The vault automates voting and reward conversion; users claim converted rewards when they are ready.
Under the default fee configuration, gauged-pool swap fees go to voters for those pools, while ungauged-pool swap fees are split 95% to liquidity providers and 5% to the protocol. Gauge-specific fee splits can differ, so users should check the pool's current configuration.
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) gives xRAM stakers weekly emissions voting and eligible voter rewards without a fixed-duration lock. To understand the design, it helps to compare it with vote-escrow systems.
ve(3,3)
The Solidly model brought together two concepts:
Vote Escrow (ve)
Vote escrow uses time-weighted voting. Users lock tokens in a voting escrow for a selected period, and longer locks generally grant more governance power.
Rebase
A rebase can offset dilution for locked positions as emissions increase supply, helping participating holders maintain their relative ownership share.
Fixed-duration locks can increase the cost of changing or exiting a position. Implementations differ in whether positions are transferable and how rewards, extensions, and exits work.
ve(3,3) → x(3,3)
Ramses replaces fixed-duration voting positions with non-transferable xRAM. Converting RAM mints xRAM 1:1, burns half of the RAM input, and retains the other half as backing for direct redemption at 0.5 RAM per xRAM. Holders can vote directly, use an AutoVault, or mint r33 for a transferable liquid-staking position.
Burns
Each RAM → xRAM conversion burns 50% of the RAM input. The other 50% remains in the xRAM contract as direct-redemption backing. Burns therefore scale with conversion volume, not with general protocol activity, and do not guarantee a market-price outcome.
See xRAM conversion and redemption for the complete mechanics.
Burn vs Rebase
Burning and rebasing use different approaches to supply and dilution:
| Feature | xRAM Conversion Burn | Vote-Escrow Rebase |
|---|---|---|
| Supply treatment | Burns 50% of the RAM amount converted to xRAM | Mints or distributes tokens to eligible locked positions |
| Dilution approach | Reduces circulating RAM when conversions occur | Seeks to offset holder dilution while emissions increase supply |
| Exit treatment | xRAM can be redeemed directly for 0.5 RAM per xRAM | Exit terms depend on the implementation and lock |
Trilemma
DEX incentive systems coordinate three groups: traders, liquidity providers, and token holders. Different designs make different tradeoffs between liquidity, voting participation, and exit flexibility.
Credit to the Aerodrome team for the original graphic and concept.
| AMM Model | Vote-Escrow Model | x(3,3) |
|---|---|---|
| Coordinates traders and liquidity providers through pool liquidity and configured fees | Adds emissions voting through time-locked positions | Adds emissions voting through staked xRAM without a fixed-duration lock |
| Governance and liquidity incentives depend on the protocol | Transfer, extension, and exit rules depend on the implementation | Offers direct xRAM redemption and optional r33 liquidity |
x(3,3) model
xRAM voting connects weekly RAM emissions to eligible pools. Pool fees, vote incentives, and automation options then determine how participants can earn and manage rewards.
| Traders | Liquidity Providers | xRAM Holders |
|---|---|---|
| Access available pool liquidity and the pool's current fee configuration | Earn the configured LP fee share and eligible RAM emissions while exposed to price, range, and adverse-selection risk | Direct weekly emissions and receive the configured voter fee share plus eligible vote incentives |
| Review price impact, slippage, route, and fee before signing | Emissions depend on gauge votes and the position's qualifying liquidity | Can vote directly or use AutoVault and r33 automation on HyperEVM |
Exit Options
Ramses separates the conversion burn from exit execution. The 50% RAM burn occurs when xRAM is minted; exiting does not burn additional RAM.
- Direct redemption — Redeem xRAM for 0.5 RAM per xRAM.
- Liquid-staking market exit — Mint or hold r33 and trade it on an available market, subject to liquidity, price impact, cooldowns, and execution costs.
Directing Emissions
xRAM stakers allocate weekly RAM emissions among eligible pools. Voters can consider fees, volume, incentives, liquidity needs, and other pool information when choosing allocations.
More vote support increases a gauge's share of next-epoch RAM emissions. Realized liquidity still depends on LP participation, fees, incentives, and market demand.
Each epoch begins Thursday at 00:00 UTC. Votes recorded for eligible gauges determine the following epoch's emission allocation. Read the live voting guide before submitting a vote.
Fees and eligible vote incentives from one epoch become claimable after the next epoch begins. Rewards are proportional to the user's vote share for each pool and are not sent automatically.
Vote Incentives
Ramses supports two incentive types:
- Voter incentives are offered to xRAM voters to attract votes to an active gauge.
- Liquidity incentives are distributed to eligible liquidity providers under the gauge's reward rules.
| Voter Incentives | Liquidity Incentives |
|---|---|
| Become claimable by eligible voters after epoch rollover | Stream to eligible liquidity providers over the configured reward period |
| Can influence votes during the current epoch | Supplement the pool's liquidity rewards |
| Reward share depends on votes for the pool | Reward share depends on qualifying liquidity |
Fees
The default swap-fee states are:
- Gauged pools — 100% to xRAM voters for that pool.
- Ungauged pools — 95% to liquidity providers and 5% to the protocol.
On Robinhood Chain, the protocol share is routed to the Buyback Module for RAM buybacks.
Fee splits can be configured per gauge. Check the pool's current configuration before trading, providing liquidity, or estimating voter rewards.
Fee-Split
| Default Gauged Pool | Default Ungauged Pool |
|---|---|
| 100% to xRAM voters | 0% to xRAM voters |
| 0% to liquidity providers | 95% to liquidity providers |
| 0% to protocol | 5% to protocol |
Dynamic Fees
Ramses can adjust certain pool fee parameters using available market data. The objective is to reduce adverse selection during volatile periods while keeping fees appropriate for the pool's current conditions.
Active fee ranges and caps can differ by pool and change over time. Check the current pool configuration before trading; a dynamic-fee mechanism does not eliminate price impact, inventory loss, adverse selection, or other liquidity-provider risks.
Real-Time Market Protection
During volatile markets, fee parameters may increase in response to conditions such as liquidity distribution, price movement, and trade size. During stable markets, parameters may decrease to keep execution competitive. The data and controls available to a module depend on the pool and deployment.
HyperEVM transactions that exceed the small-block gas limit use Big Blocks. Ramses can switch block mode automatically when the required HyperCore setup is available. Open the Big Blocks guide →