Overview
Ramses uses a live, same-chain HyperEVM module to run authorized MEV backruns through supported Ramses pools. Eligible value retained by the module can fund RAM buybacks and burns. Separate onchain reward protection discourages reverse-JIT liquidity farming.
The live backrun flow is scoped to HyperEVM and supported Ramses pool routes.
HyperEVM MEV Backruns
The module gives approved executors a controlled path for atomic, same-chain backruns.
- An authorized executor submits a supported sequence of Ramses pool swaps.
- The module applies any approved temporary fee settings only for that transaction.
- The swaps execute atomically and the original pool fees are restored before completion.
- If a step fails or the module's profitability check does not pass, the complete transaction reverts.
Ordinary user swaps continue under each pool's configured fees. Backrun permissions do not grant an executor general control over user positions or funds.
RAM Buyback & Burn
The module exposes a separate buyback-and-burn operation. Eligible retained value is used to buy RAM with a minimum-output check, and the purchased RAM is burned. Completed operations emit an onchain BuybackAndBurn event, and the Ramses stats page tracks the resulting RAM burns.
This HyperEVM mechanism is separate from the Robinhood Buyback Module, which receives protocol fees and transfers RAM to the dead address.
This creates a transparent path from captured same-chain MEV to RAM supply reduction. Buybacks depend on successful backruns and available retained value; they are not guaranteed on a fixed schedule.
Stopping Reverse JIT Liquidity
Ramses uses 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.
- A liquidity change starts the timer. Creating a position, adding liquidity, or removing liquidity records a timestamp for that position.
- 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.
- 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 wait period and enabled state can differ by deployment. Check the active setting before claiming rewards or changing liquidity. This protection applies to the concentrated-liquidity reward path; other pool types can settle rewards differently.