MEV

Overview

Ramses uses permissioned engines designed to capture eligible MEV opportunities and retain the resulting value within the protocol. Allocation depends on the module described below.

Ramses' liquid-staked xRAM product is called r33, with the name hyperRAM on HyperEVM. The hyperRAM AMO flow below describes its HyperEVM implementation.

MEV Solutions

Automated Market Operations (AMO)

Ramses' AMO system is designed to optimize protocol efficiency and maximize value for all participants through systematic arbitrage when the hyperRAM redeem floor triggers.

The AMO system executes a systematic arbitrage process:

1. Target liquidity pool identification
2. Application of the module's fee privileges
3. RAM → hyperRAM conversion
4. hyperRAM → xRAM redemption
5. Instant exit: xRAM → RAM
6. Allocation of the resulting value according to the rules below

The AMO bot targets market inefficiencies through the atomic conversion and allocation flow above.

Backrun Arbitrage

The backrun arbitrage bot is designed to capture eligible opportunities that would otherwise be available to external extractors. Its goal is to reduce loss-versus-rebalancing (LVR) and adverse selection for liquidity providers while retaining captured value within the protocol.

MEV Infrastructure

Ramses' current MEV infrastructure includes the live modules above. The roadmap expands that system across additional chains, venues, and protocols.

Planned Multi-Venue Arbitrage

Planned Privileged Atomic Execution

Dynamic Fee Integration

The MEV infrastructure works with Ramses' dynamic fee algorithm, which uses available market data to adjust fee levels in real time. This creates a feedback loop where:

1. Dynamic fees protect LPs during volatile periods
2. MEV bots capture arbitrage opportunities that would otherwise extract value from LPs
3. Arbitrage proceeds are allocated according to the active module
4. The protocol retains value that could otherwise leak to external extractors

Stopping Reverse JIT Liquidity

Ramses pioneered timer-based protection against reverse-JIT emissions farming. The principle is direct: claim rewards or change liquidity too soon, and the affected emissions are slashed. Emissions should support liquidity that stays available for trading.

How Ramses' Anti-Sybil Timer Works

The Voter controls the anti-Sybil switch and the reward timer. For protected concentrated-liquidity positions, the position manager records the latest liquidity change, and the gauge checks the reward validator when processing a claim.

1. A liquidity change starts the timer. Creating a position, adding liquidity, or removing liquidity records a timestamp for that position.
2. A reward claim checks the timer. While anti-Sybil protection is enabled, the validator compares the time since that checkpoint with the threshold configured in the Voter.
3. Claim too soon and lose those rewards. If the timer has not cleared, the affected claim is slashed and redirected to r33 (hyperRAM on HyperEVM). Once the timer has cleared, the timing check passes; other reward eligibility checks still apply.

Liquidity increases and decreases also automatically attempt to claim emissions against the previous checkpoint before resetting the timer. Rapidly changing liquidity can therefore trigger the penalty even without pressing a separate claim button.

What Is Reverse JIT Liquidity?

Standard just-in-time (JIT) liquidity enters immediately before a swap and exits immediately afterward to earn its fees. Reverse JIT does the opposite: an operator farms emissions in a tight range between swaps, then pulls liquidity just before a trade to avoid its inventory risk.

That strategy competes for emissions with LPs who remain available to support trades. Ramses' timer puts a direct cost on rapid entry, exit, and reward extraction, enforced by the contracts themselves.

What This Means for LPs

Let the full timer clear after creating or changing a protected position before claiming emissions or changing its liquidity again. Adding or removing liquidity restarts the timer; collecting swap fees alone does not restart it.

The duration and enabled state are configurable in the Voter and can differ by deployment. Integrators should read timeThresholdForRewarder() and isAntiSybilEnabled() from the relevant Voter contract, rather than assume a fixed waiting period. This describes the concentrated-liquidity reward path; other pool types can settle rewards differently.

Implementation references: position checkpoints and automatic claims, gauge reward validation and slashing.