# Ramses documentation Official documentation from https://www.ramses.xyz/docs. Each article below includes its canonical source URL. Interactive charts are linked to their HTML articles; accompanying explanations and tables are included. --- # Ramses documentation Ramses combines dynamic fees, same-chain MEV backruns, and fee-aligned RAM, xRAM, and r33 tokenomics. Source: https://www.ramses.xyz/docs ## Start Here Choose what you want to do, then follow the linked guide. ### [Swap tokens](https://www.ramses.xyz/docs/swapping) Choose a pair, review the live route and minimum received, then confirm the swap. ### [Provide liquidity](https://www.ramses.xyz/docs/farming) Choose a pool model, create a position, and manage fees and eligible rewards. ### [Vote with xRAM](https://www.ramses.xyz/docs/voting) Direct RAM emissions across active HyperEVM gauges and review eligible voter rewards. ### [Verify contracts](https://www.ramses.xyz/docs/contract-addresses) Confirm live DEX deployments, RAM and r33 OFT routes, and explorer-verified addresses. **For launchpads:** [Connect your token launch or graduation flow to Ramses](https://www.ramses.xyz/docs/for-launchpads), compare pool models, and get integration support. ## Explore Ramses Products ### [Review dynamic fees](https://www.ramses.xyz/docs/hyperram#dynamic-fees) See how Ramses adjusts pool fees in response to market volatility and trading volume. ### [Understand MEV backruns](https://www.ramses.xyz/docs/mev) Learn how the live same-chain HyperEVM backrun, RAM buyback-and-burn path, and reverse-JIT reward protection work. ### [Understand tokenomics](https://www.ramses.xyz/docs/tokenomics) Review RAM supply and emissions, xRAM conversion burns, r33 backing, and fee-funded RAM buybacks. ### [Use AutoVaults](https://www.ramses.xyz/docs/autovaults) Stake xRAM, select an enabled output token, automate voting and reward conversion, then claim accrued rewards. ### [Explore the Buyback Module](https://www.ramses.xyz/docs/buyback-module) Follow how Robinhood protocol fees fund authorized RAM buybacks and transfers to the burn address. ### [Understand xRAM](https://www.ramses.xyz/docs/xram) Learn how non-transferable xRAM directs emissions, receives eligible fees and incentives, and can be redeemed or used to mint r33. ### [Learn concentrated liquidity](https://www.ramses.xyz/docs/concentrated-liquidity) Learn how price ranges, out-of-range positions, competitive farming, range orders, and fee tiers work. ### [Provide DLMM liquidity](https://www.ramses.xyz/docs/dlmm) Learn how price bins, liquidity ranges, dynamic fees, and DLMM position management work. ### [Learn competitive farming](https://www.ramses.xyz/docs/concentrated-liquidity#competitive-farming) See how qualifying concentrated liquidity earns emissions based on active liquidity and range efficiency. ### [Understand r33 liquid staking](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking) Learn how r33 (hyperRAM on HyperEVM) automates voting and compounds eligible fees and incentives into its xRAM backing. --- # Tokenomics & Emissions Initial distribution, supply schedule and elastic emissions for RAM token Source: https://www.ramses.xyz/docs/tokenomics --- ## Design Overview Ramses tokenomics combine flexible participation with supply discipline. [Converting RAM to xRAM](https://www.ramses.xyz/docs/xram#conversion-burn) burns half of the RAM input, xRAM holders direct weekly emissions without a fixed-duration lock, and value retained by [MEV backruns](https://www.ramses.xyz/docs/mev#ram-buyback-and-burn) can fund RAM buybacks and burns. On Robinhood Chain, protocol fees fund RAM buybacks through the [Buyback Module](https://www.ramses.xyz/docs/buyback-module), which replaced the Sarcophagus as the fee recipient on October 14, 2026. These mechanisms do not guarantee net deflation or a market-price outcome. RAM issuance and every source of supply reduction must be evaluated together. --- ## Distribution Below is the initial distribution of **RAM**. [Initial token distribution — interactive visualization](https://www.ramses.xyz/docs/tokenomics#distribution) Initial RAM distribution among the Ramses community, Hyperliquid community, treasury, and protocol-owned liquidity. | Allocation | Initial supply | | --- | --- | | Ramses community (veRAM) | 45% | | Hyperliquid community | 30% | | Treasury | 23% | | Protocol-owned liquidity | 2% | --- ### Breakdown The **Hyperliquid Community (30%)** allocation contains the **NFT Airdrop (20%)** and **Incentives (10%)**. Within Incentives, **RXP receives 3%** and **Liquidity and Vote Incentives receive 7%**. All percentages below are shares of the initial supply. | **Category** | **% of Initial Supply** | **Amount** | | --- | --- | --- | | Ramses Community (veRAM) | **45%** | 157,500,000 | | Hyperliquid Community | **30%** | 105,000,000 | | NFT Airdrop — Hypurr, Hypios, Catbal NFTs, and PiP | 20% | 70,000,000 | | Incentives | 10% | 35,000,000 | | RXP | 3% | 10,500,000 | | Liquidity and Vote Incentives | 7% | 24,500,000 | | Treasury | **23%** | 80,500,000 | | POL | **2%** | 7,000,000 | | **Initial Supply** | **--** | **350,000,000** | > **Token Types** > > All allocations are in xRAM except for POL. --- ## Emissions RAM's current supply grows when new RAM is minted and falls when RAM is burned. The [live supply composition](https://www.ramses.xyz/tokenomics) shows where existing RAM sits, alongside this epoch's emissions and annualized gross inflation. Gross inflation measures issuance before burns; it is not a forecast of net supply growth. The **1 billion RAM cap** limits the total RAM that can exist at one time. It is a safety ceiling, not an emission target or a limit on lifetime cumulative issuance. Burns reduce outstanding supply and restore room below the ceiling, so cumulative issuance can exceed the cap over time without outstanding supply exceeding it. The Buyback Module transfers RAM to the dead address, removing it from usable circulation without reducing the Robinhood token's ERC-20 `totalSupply`. Tokenomics tracks these transfers separately from supply-reducing RAM burns on HyperEVM. [Legacy Sarcophagus burials](https://www.ramses.xyz/docs/sarcophagus) permanently sent r33 to the dead address. Because r33 is liquid-staked xRAM, the burial also retires its liquid claim on the underlying xRAM and RAM backing. That backing remains permanently locked inside r33 and remains part of RAM total supply, so it is not counted as a direct RAM-token burn. ### Supply & Issuance The chart shows recorded weekly issuance and total supply for completed epochs. The next-epoch figure is read live from the minter; it is not extended into a long-term forecast. [RAM supply and emissions — interactive visualization](https://www.ramses.xyz/docs/tokenomics#supply-and-issuance) Recorded RAM issuance and total supply for completed epochs. Switch between weekly issuance and total supply over 12 weeks, 26 weeks, or all available history. Live current supply and next-epoch emissions are shown separately. Use **Weekly issuance** to see RAM minted each epoch, or **Total supply** to see outstanding RAM after mints and supply-reducing burns. The initial supply reconciliation and the current incomplete epoch are excluded. ### Elastic Emissions New weekly RAM emissions are sent to the voter and gauge system; there is no recurring team-emissions allocation. An authorized protocol role can update the emissions multiplier within the contract's maximum allowed change. The current multiplier and next scheduled emission are available on-chain. The current setting does not commit future epochs to the same rate. --- ## Multichain Token Architecture Ramses X is live across **HyperEVM, Base, Polygon, and Robinhood Chain**. HyperEVM is the current home of RAM and the canonical side of the live LayerZero OFT network. Ethereum Mainnet is configured as an eventual canonical hub, but its route is currently inactive. RAM and r33 use shared supply accounting across active OFT routes, while execution, liquidity, and governance remain local to each chain. Moving the canonical hub to Ethereum is not required for the current network. [Learn more about Ramses X multichain architecture →](https://www.ramses.xyz/docs/ramses-x) --- # MEV Backruns & LP Protection How Ramses' live HyperEVM backruns, RAM buyback-and-burn path, and reverse-JIT reward protection work. Source: https://www.ramses.xyz/docs/mev ## 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. 1. An authorized executor submits a supported sequence of Ramses pool swaps. 2. The module applies any approved temporary fee settings only for that transaction. 3. The swaps execute atomically and the original pool fees are restored before completion. 4. 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](https://www.ramses.xyz/docs/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. > **Backrun Safeguards** > > Only an authorized executor can run a backrun. Temporary fee settings are transaction-scoped, failed or unprofitable routes revert, and buybacks enforce a minimum RAM output. --- ## 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. 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. > **Slashed Rewards Are Forfeited** > > An early claim forfeits the affected emissions permanently. Waiting afterward does not recover them. The penalty applies to those rewards; it does not confiscate the position's deposited liquidity. ### 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. --- # AutoVaults Stake xRAM, select a reward token, and automate voting, reward collection, and conversion. Claim converted rewards when ready. Source: https://www.ramses.xyz/docs/autovaults ## Ramses AutoVaults Stake xRAM, choose a reward token, and let the AutoVault handle voting, reward collection, and conversion each epoch. **Stake and chill.** ### [Select Your Reward](https://www.ramses.xyz/docs/autovaults#how-it-works) Choose from the reward tokens currently enabled by the AutoVault contract. ### [Automated Voting](https://www.ramses.xyz/docs/autovaults#automated-voting-and-conversion) The operator submits votes automatically each epoch. Users do not vote manually. ### [Low Maintenance](https://www.ramses.xyz/docs/autovaults#benefits) No weekly votes or manual reward conversion. Converted rewards remain claimable until you collect them. ### [Automated Strategy](https://www.ramses.xyz/docs/autovaults#automated-voting-and-conversion) An operator-managed strategy allocates votes using available fee, incentive, and liquidity data. --- ## How It Works AutoVaults simplify the xRAM staking experience into four steps: | Step | Action | | --- | --- | | **1. Stake xRAM** | Deposit your xRAM into the AutoVault | | **2. Select Reward Token** | Choose from the output tokens currently enabled by the AutoVault contract | | **3. Earn Automatically** | The operator handles voting, reward collection, and conversion each epoch | | **4. Claim Rewards** | Claim your converted rewards whenever the vault is unlocked | The vault uses an automated voting strategy similar to r33, the liquid-staked xRAM product called hyperRAM on HyperEVM. The operator votes each epoch and credits converted rewards to each staker for claiming. --- ## Reward Tokens AutoVault is live on **HyperEVM**. Choose any currently supported output token from the app's **Reward Token** selector. > **Token Formats** > > AutoVault output tokens are ERC-20 tokens. Native assets appear through their supported wrapped or tokenized representation where applicable. --- ## Automated Voting and Conversion Each epoch, the operator: 1. Allocates the vault's xRAM voting power across Ramses pools. 2. Collects the resulting fees and vote incentives. 3. Converts those rewards onchain into the selected output token. 4. Credits each staker's pro-rata share as a claimable balance. Each epoch's result reflects the fees, incentives, liquidity, and execution available at that time. Converted rewards are not reinvested into the xRAM deposit. --- ## Benefits ### Automated Voting The operator manages the voting strategy each epoch, so stakers do not submit weekly votes or rebalance positions. ### One Selected Reward Token The vault collects and converts underlying fees and vote incentives into the output token selected by each staker. ### Claim on Your Schedule Converted rewards remain credited to the staker and can be claimed whenever the vault is unlocked. --- ## AutoVaults vs Manual Staking vs r33 | Feature | AutoVaults | Manual xRAM | r33 | | --- | --- | --- | --- | | Voting | Automated | Weekly manual | Automated | | Value Accrual | Selected token credited for claiming | Fees and incentives in their native reward tokens | Rewards compound into r33's xRAM backing | | Claiming | Claim when ready | Manual claim | No separate reward claim | | Strategy | Operator-managed | User-directed | Automated voting and compounding | | Effort Required | Low | Weekly | Low | | Liquidity | Withdrawable during unlocked periods | Withdrawable | Tradeable on available markets, subject to market liquidity | --- ## Getting Started 1. **Acquire xRAM** — Convert RAM to xRAM or receive it through a distribution that explicitly offers xRAM 2. **Navigate to AutoVaults** — Find the vault for your preferred reward token 3. **Deposit xRAM** — Stake your position 4. **Claim Rewards** — Rewards are converted automatically, then claimed with a user transaction > **Exit Mechanics** > > - Deposits, output-token changes, and claims are available while the AutoVault is unlocked. > - During a VoteModule cooldown, deposits and output-token changes pause. > - Withdrawals remain available, but withdrawing before an epoch's reward processing is complete may forfeit that epoch's rewards. Review the in-app warning before confirming. > - The contract does not charge a withdrawal fee; network gas still applies. --- # Buyback Module How the Robinhood and Elysium Buyback Modules convert assets into RAM and permanently remove that chain's RAM from circulation. Source: https://www.ramses.xyz/docs/buyback-module ## From Protocol Fees to RAM Buybacks The **Buyback Module** is the current destination for Ramses protocol fees on Robinhood Chain. Accumulated assets fund automated RAM buybacks, with execution restricted to authorized callers. RAM received by the module is sent to the dead address, permanently removing it from usable circulation. > **Live on Robinhood Chain** > > On **October 14, 2026**, fee routing moved from the Sarcophagus to the Buyback Module. The [routing transaction](https://robin.etherscan.io/tx/0x4e5df9d3d5f14c0cb26ad6731ab4e9f3c11bfb72dcbee0de455ce46b2d99aff1) updated the concentrated-liquidity, legacy, DLMM, and gauge fee recipients. The [Sarcophagus documentation](https://www.ramses.xyz/docs/sarcophagus) is retained as a legacy reference for r33 burials. Elysium has its own Buyback Module, deployed on **October 29, 2026**. It retires **Elysium RAM**, a separate token contract with no listed OFT route to the other RAM deployments. Robinhood and Elysium buybacks are therefore tracked per chain. The loop and controls below describe the Robinhood deployment. ## The Fee-to-Buyback Loop 1. **Collect fees.** The configured protocol share of pool fees is collected into the module as token balances. 2. **Execute a buyback.** An authorized executor chooses an input asset, a maximum input amount, a whitelisted aggregator, and a minimum RAM output. 3. **Check the result.** The contract measures the actual input spent and RAM received. The transaction reverts if the input limit is exceeded or the minimum RAM output is not met. 4. **Retire RAM.** The module transfers the received RAM to `0x000000000000000000000000000000000000dEaD` in the same transaction and emits a `BuybackExecuted` event. If the module already holds RAM, an authorized executor can send that RAM directly to the dead address without a swap. These executions also emit `BuybackExecuted`; a completed event therefore does not always represent a market purchase. Buybacks depend on available balances, executable liquidity, and authorized execution. The contract does not enforce a fixed schedule or guarantee a buyback amount. ## Fee Distribution On Robinhood Chain, each pool's **configured protocol fee share** is routed to the Buyback Module to fund RAM buybacks. ## Execution and Controls The [verified BuybackModule implementation](https://robin.etherscan.io/address/0x74F1e8Be68Ae7bf24Bc387Ee1a900d5bC23317a3#code) restricts `buybackAndBurn` to callers with the AccessHub `SWAP_FEE_SETTER` role. Users do not approve or bury r33 to claim the module's assets. - **Approved routes:** swaps must use a whitelisted aggregator contract. - **Bounded input:** the aggregator receives an allowance for the specified input amount, and that allowance is cleared after the call. - **Minimum output:** each execution requires a nonzero minimum RAM output and checks the actual balance increase. - **Atomic execution:** the swap, output check, and RAM transfer complete together or revert together. - **Administrative controls:** the AccessHub default admin can update the aggregator whitelist and rescue ERC-20 balances. The minimum output is supplied by the authorized executor; it is not an independent price oracle or a guarantee of the best available price. ## What the Burn Means Here, **burned RAM means RAM transferred to the dead address**. This removes RAM from usable circulation but does **not** reduce the Robinhood token's ERC-20 `totalSupply`. It is tracked separately from supply-reducing RAM burns on HyperEVM. Legacy Sarcophagus burials sent **r33** to the dead address, retiring the liquid claim on its underlying xRAM and RAM backing. The Buyback Module instead retires **RAM itself**. Historical r33 burials remain part of the record and should not be counted again as new RAM buybacks. ## Contracts and Activity | Contract | Robinhood Chain Address | Elysium Address | | --- | --- | --- | | Buyback Module | [0x74F1e8Be68Ae7bf24Bc387Ee1a900d5bC23317a3](https://robin.etherscan.io/address/0x74F1e8Be68Ae7bf24Bc387Ee1a900d5bC23317a3) | [0xE565310BAa582C768a77a3BB7F86a892eF07D04e](https://elysium.kinetiq.xyz/explorer/address/0xE565310BAa582C768a77a3BB7F86a892eF07D04e) | | RAM | [Robinhood RAM in the contract directory](https://www.ramses.xyz/docs/contract-addresses) | [0x2ea9E66Adb86b0Ed71f79ab2e81a31147eDc3215](https://elysium.kinetiq.xyz/explorer/address/0x2ea9E66Adb86b0Ed71f79ab2e81a31147eDc3215) | | Burn Address | [0x000000000000000000000000000000000000dEaD](https://robin.etherscan.io/address/0x000000000000000000000000000000000000dEaD) | [0x000000000000000000000000000000000000dEaD](https://elysium.kinetiq.xyz/explorer/address/0x000000000000000000000000000000000000dEaD) | The [tokenomics dashboard](https://www.ramses.xyz/tokenomics) tracks confirmed Buyback Module activity alongside other burn mechanisms, with a separate series for each chain. Its buyback history matches `BuybackExecuted` events to RAM transfers to the dead address in successful transaction receipts. Assets still held by a module are not completed buybacks. Each chain's amounts are nominal RAM of that chain's token. USD values use that token's historical price on the day of the buyback; a day without a recorded price stays unpriced rather than using today's price. A chain with no completed buybacks shows zero, and a chain whose history cannot be loaded shows as unavailable instead of zero. [View all contract addresses →](https://www.ramses.xyz/docs/contract-addresses) --- # r33 (hyperRAM) r33 is Ramses' liquid staked xRAM token, known as hyperRAM on HyperEVM. Learn how it fits into Ramses' HyperEVM ecosystem. Source: https://www.ramses.xyz/docs/hyperram > **r33 and hyperRAM are the same product** > > **r33** is Ramses' [liquid staked xRAM](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking). It is known as **hyperRAM on HyperEVM** and **r33 on other chains**. The docs use r33 as the general name; hyperRAM remains the HyperEVM name shown in token lists, contracts, and integrations. > > This page covers the HyperEVM ecosystem. For conversion, redemption, liquid staking, and cooldown mechanics, see [xRAM](https://www.ramses.xyz/docs/xram); for the live multichain architecture, see [Ramses X](https://www.ramses.xyz/docs/ramses-x). ![HyperEVM](https://www.ramses.xyz/docs-assets/HLxRAM.avif) Ramses on HyperEVM combines a **[capital-efficient DEX](https://www.ramses.xyz/docs/hyperram#hyper-efficient)**, the **[x(3,3) incentive model](https://www.ramses.xyz/docs/hyperram#x-3-3)**, and **[HyperEVM-native transaction support](https://www.ramses.xyz/docs/big-blocks)**. 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](https://www.ramses.xyz/docs/mev) and [published security reviews](https://www.ramses.xyz/docs/audits) 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](https://www.ramses.xyz/docs/tokenomics#breakdown). --- ## x(3,3) ![Trilemma](https://www.ramses.xyz/docs-assets/trilemma3.png) **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. [Voting power — interactive visualization](https://www.ramses.xyz/docs/hyperram#vote-escrow-ve) Four-year lock example: voting weight declines linearly to zero over 1,460 days while the locked token amount remains constant. #### Rebase A rebase can offset dilution for locked positions as emissions increase supply, helping participating holders maintain their relative ownership share. [Rebasing example — interactive visualization](https://www.ramses.xyz/docs/hyperram#rebase) Rebasing example: user veTOKEN holdings of 1,000, 1,500, and 2,390 against total TOKEN supply of 2,000, 3,000, and 4,000 across three epochs. 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) ![ve(3,3)](https://www.ramses.xyz/docs-assets/ve33x33.png) 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](https://www.ramses.xyz/docs/xram#conversion-burn) 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. ![Trilemma](https://www.ramses.xyz/docs-assets/trilemmanogrid.png) *Credit to the Aerodrome team for the [original graphic and concept](https://x.com/wagmiAlexander/status/1862191154932195570).* | 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 ![x(3,3)](https://www.ramses.xyz/docs-assets/ramsesflywheel.png) 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. 1. **Direct redemption** — Redeem xRAM for **0.5 RAM per xRAM**. 2. **Liquid-staking market exit** — Mint or hold [r33](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking) 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](https://www.ramses.xyz/docs/voting) 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 | > **Check Incentive Eligibility** > > A voter incentive must use an allowed token and target an active gauge. Verify the token, gauge, amount, and epoch before submitting the transaction. Incentive deposits cannot be assumed to produce a particular vote or liquidity outcome. --- ## 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](https://www.ramses.xyz/docs/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 | > **Configurable Fee Splits** > > The table shows default states. A gauge can use a different fee split, and current on-chain configuration controls. --- ### Dynamic Fees ![Dynamic Fees](https://www.ramses.xyz/docs-assets/dynamicfees.png) 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. ![Algo in Volatile Time](https://www.ramses.xyz/docs-assets/algoinvolatile.png) ![Algo in Stable Markets](https://www.ramses.xyz/docs-assets/algoinstable.png) --- 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 →](https://www.ramses.xyz/docs/big-blocks) --- # xRAM Stake xRAM to direct emissions and earn eligible voter rewards, or mint r33 (known as hyperRAM on HyperEVM) to automate voting and compound rewards. Source: https://www.ramses.xyz/docs/xram ## What is xRAM? ![xRAM](https://www.ramses.xyz/docs-assets/xRAM.png) xRAM is Ramses' non-transferable voting token. It lets holders direct weekly RAM emissions and receive eligible voter fees and incentives without a fixed-duration lock. xRAM conversion, staking, voting, and r33 minting and redemption currently run on **HyperEVM**. r33 can move across its supported OFT routes and is called **hyperRAM on HyperEVM** and **r33 on other chains**. **Participate without a fixed-duration lock.** ### [Incentives](https://www.ramses.xyz/docs/xram#voting) Vote to direct RAM emissions and receive the configured voter fee share plus eligible vote incentives. ### [Direct Redemption](https://www.ramses.xyz/docs/xram#how-to-exit-x-ram) Redeem xRAM for RAM at the protocol's 1:0.5 ratio at any time. ### [AutoVaults](https://www.ramses.xyz/docs/xram#auto-vaults) Delegate voting, receive rewards in an enabled output token, and claim them when ready. ### [Vote Incentives](https://www.ramses.xyz/docs/xram#voting) Receive a proportional share of eligible incentives for the active gauges you vote for. ### [r33 Liquid Staking](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking) Automate voting and compound eligible rewards with r33, the liquid staked version of xRAM known as hyperRAM on HyperEVM. ### [Conversion Burn](https://www.ramses.xyz/docs/xram#conversion-burn) 50% of each RAM amount converted to xRAM is burned; the other 50% backs direct redemption. --- ### What can I do with xRAM? xRAM holders can stake and vote to direct emissions to eligible pools. Under the default gauged-pool configuration, voters receive 100% of the swap fees from pools they vote for, plus eligible vote incentives; gauge-specific fee splits can differ. On HyperEVM, holders can instead deposit xRAM into an AutoVault and choose from output tokens currently enabled in the app, or mint **r33 (hyperRAM on HyperEVM)** to automate voting and compound eligible rewards. - **Voting & incentives:** Vote to direct emissions and earn the configured voter share of swap fees plus eligible vote incentives. - **Choose your reward:** Stake xRAM in an AutoVault and choose from the output tokens currently enabled in the app. - **Mint r33 (LST):** Mint r33 (hyperRAM on HyperEVM), the liquid-staked xRAM that compounds eligible fees and vote incentives. --- ![xRAM](https://www.ramses.xyz/docs-assets/ramsesflywheel.png) --- ## Token xRAM is minted 1:1 from RAM input and cannot be transferred between wallets. For every RAM amount converted, **50% is burned** and the remaining 50% stays in the xRAM contract to fund direct redemption at **0.5 RAM per xRAM**. Staked xRAM provides Ramses voting power. --- ### How is xRAM obtained? Users mint xRAM by converting RAM. xRAM may also be received through an incentive or distribution that explicitly offers xRAM; weekly gauge emissions are paid in RAM. ![Conversion](https://www.ramses.xyz/docs-assets/convert.png) ### RAM → xRAM Conversion RAM can be converted into xRAM at any time. The full RAM input amount is minted as xRAM, 50% of that RAM input is burned, and the remaining 50% backs direct redemption. --- ### How to exit xRAM? ![Exit](https://www.ramses.xyz/docs-assets/exit.png) ### xRAM → RAM Redemption Users can exit an xRAM position in two ways: 1. **Direct redemption** — Redeem xRAM for RAM at **0.5 RAM per xRAM**. 2. **Liquid-staking market exit** — Hold r33 and trade it on an available market, subject to market liquidity, price impact, cooldowns, execution costs, and protocol risk. > **Burn on Mint** > > The 50% burn occurs when xRAM is minted, not when xRAM or r33 is redeemed. --- ## AutoVaults ![AutoVault Rewards](https://www.ramses.xyz/docs-assets/hypebuyback.png) AutoVault is currently available on **HyperEVM**. Users deposit xRAM, choose from output tokens currently enabled by the vault contract, and let the vault operator submit votes each epoch. After an epoch flips, the operator collects allocated fees and vote incentives, converts them into each user's selected output token, and credits claimable rewards. Rewards are not sent automatically; users claim them when the vault is unlocked. > **AutoVault Lock and Reward Timing** > > Deposits, output-token changes, and claims are available while the AutoVault is unlocked. During a VoteModule cooldown, deposits and output-token changes pause. Withdrawals remain available, but withdrawing while reward processing is incomplete may forfeit that epoch's rewards; review the in-app warning before confirming. > **Automated Voting** > > AutoVaults use an automated voting strategy similar to r33. The operator submits votes each epoch, so users do not vote manually. [Learn more about AutoVaults →](https://www.ramses.xyz/docs/autovaults) | Source | Conversion | Distribution | | --- | --- | --- | | Eligible fees and vote incentives | Converted into the selected output token after epoch flip | Credited pro rata for manual claiming | Unstaked xRAM does not earn AutoVault rewards. The output-token selector in the app is the current source for enabled reward choices. --- ## xRAM Liquid Staking **r33 is the liquid staked version of xRAM. It is known as hyperRAM on HyperEVM and r33 on other chains; both names refer to the same product.** These docs use r33 as the general name and retain hyperRAM where it identifies the HyperEVM token, contract, or integration. ![Mint r33 (hyperRAM on HyperEVM)](https://www.ramses.xyz/docs-assets/xRAMconvert.png) r33 automates voting and compounds eligible fees and vote incentives into additional xRAM backing. Users hold a transferable token instead of managing weekly votes directly. > **Minting Lock** > > During the final **1 hour before an epoch flip**, new r33 cannot be minted while votes are calculated. ### r33 (hyperRAM) ![r33, known as hyperRAM on HyperEVM](https://www.ramses.xyz/docs-assets/hyperRAM.png) r33 can be minted with xRAM. Its xRAM redemption ratio starts at 1.00:1.00 and is designed to increase as eligible rewards are converted into additional backing. | Feature | Details | | --- | --- | | **Automated voting** | The strategy submits votes each epoch | | **Reward conversion** | Collected fees and incentives are converted through supported routes into additional backing | | **Auto-compounding** | Additional backing increases the amount of xRAM redeemable per r33 | | **No protocol fees** | No protocol fee for deposits, redemptions, or compounding; network gas still applies | | **Transferable token** | r33 can trade on available markets, subject to liquidity and execution conditions | | **On-chain redemption ratio** | The current ratio is read from the liquid-staking contract | After each weekly epoch flip, collected fees and vote incentives are converted into additional backing. The example below is illustrative; the actual r33:xRAM ratio changes with realized rewards. [r33:xRAM redemption ratio — interactive visualization](https://www.ramses.xyz/docs/xram#hyper-ram) Example r33:xRAM redemption ratio rising from 1.000 to 1.352 over ten epochs. r33 is called hyperRAM on HyperEVM. This example is not a forecast or a guaranteed return. #### Market price and redemption value r33 can trade on available markets, but it does not change xRAM's direct-redemption economics. RAM → xRAM conversions burn 50% of the RAM input, and each xRAM redeems for 0.5 RAM. The r33 market price can differ from its redemption value because of liquidity, price impact, cooldowns, execution costs, and protocol risk. > **Post-Epoch Processing** > > After an epoch flips, new r33 minting is disabled for up to **12 hours** while rewards are processed and compounded. Redemptions remain available, but redeeming before compounding finishes can forfeit the position's share of that week's unprocessed rewards. Review the in-app warning before confirming. --- ## Conversion Burn Each RAM → xRAM conversion burns **50% of the RAM input** and retains the other 50% as direct-redemption backing. This reduces circulating RAM when conversions occur. It does not distribute the burned RAM to users or guarantee a market-price outcome. --- ## Voting Manual xRAM voting currently runs on **HyperEVM**. Staked xRAM holders allocate weekly RAM emissions among active gauges. Under the default gauged-pool configuration, voters receive 100% of the swap fees from pools they vote for plus eligible vote incentives. A gauge can use a different fee split, so its current configuration controls. Ungauged pools use the default 95% liquidity-provider and 5% protocol split. | **Swap Fees** | **Vote Incentives** | | --- | --- | | The pool's configured voter share, allocated in proportion to votes | Eligible incentives offered to attract votes to the gauge | > **Claiming Rewards** > > - Eligible fees and vote incentives become claimable after epoch rollover; they are not sent automatically. > - A voter incentive must use an allowed token and target an active gauge. [Learn how to vote →](https://www.ramses.xyz/docs/voting) ### Voting Breakdown Votes determine each active gauge's share of next-epoch RAM emissions. Emissions are then distributed under that gauge's reward rules. ### Emission Calculation Expected pool emissions are calculated from total epoch emissions and the pool's share of all eligible votes: - **Pool emissions = total epoch emissions × (pool votes / total eligible votes)** For example, if an epoch distributes **100,000 RAM** and a gauge receives **10%** of eligible votes, that gauge receives **10,000 RAM** for the epoch. The rewards stream over the epoch according to the gauge's qualifying-liquidity rules. ### Vote Weight Calculation Voting power is based on the user's staked xRAM balance in the VoteModule. Users allocate that power proportionally across selected pools: **Pool vote weight = xRAM voting balance × (submitted pool weight / sum of submitted weights)** > **Weekly Epochs** > > - Each epoch begins Thursday at **00:00 UTC**. > - Recorded votes determine emission distribution for the following epoch. > - Rewards depend on gauge eligibility and qualifying liquidity. --- # Legacy Liquidity Learn about Ramses' Uniswap v2-style pairs and stable swaps. Source: https://www.ramses.xyz/docs/legacy-liquidity Prior to concentrated liquidity, **Uniswap v2** pairs were the standard for DeFi liquidity. Ramses implements these traditional pairs alongside stable pairs for correlated assets. --- ## Swaps Each quote follows the pool's invariant, reserve ratio, trade size, and swap fee. Arbitrage helps keep the pool price aligned with the broader market. ### Pair Types **Ramses features two types of Liquidity Pairs, each with its own swap curve:** - **Volatile (Uniswap v2)**: Uses the constant-product curve for assets that can move independently. - Volatile swap formula: `x * y = k`. - **Stable (Correlated)**: Uses a curve designed for correlated assets such as stablecoins, providing lower slippage near their shared target price. - Stable swap formula: `xy(x^2 + y^2) = k`. ### Swap Curves #### Visualization The graph below compares the correlated and volatile swap curves between `0` and `100`, illustrating their different behavior near a balanced 1:1 price. [Interactive swap-curve graph](https://www.desmos.com/calculator/1brdmaxdgx?embed) **Solid** = Correlated Curve, **Dotted** = Volatile Swap Curve ### Fee Structure > **Pool Fees** > > Fees are set per pool and shown in the app before a swap. Correlated pairs generally use lower fees, while volatile pairs use higher fees to compensate LP risk. --- ## Pairs Legacy LP tokens can be staked in an active gauge to earn RAM emissions. The more xRAM votes a pair receives, the more RAM its gauge receives in the following epoch. ### Fees & Rewards Stake legacy LP tokens in an active gauge to earn RAM emissions and any additional gauge rewards shown in the app. By default, gauged-pool swap fees go to xRAM voters. If a pool does not have a gauge, 95% of swap fees remain in the pair and increase LP-token value, while 5% goes to the protocol. --- # Concentrated Liquidity Maximize capital efficiency by providing liquidity in specific price ranges. Source: https://www.ramses.xyz/docs/concentrated-liquidity --- ## What is it? Popularized by **Uniswap V3**, concentrated liquidity enables liquidity providers to focus their capital within specific [ranges](https://www.ramses.xyz/docs/concentrated-liquidity#ramses-cl), tightening spreads and reducing slippage while that liquidity is active. To understand concentrated liquidity, compare it with a familiar centralized-market structure: **an order book**. ![Order Book](https://www.ramses.xyz/docs-assets/cexorderbook.png) In the depth chart above, **bids (buys)** and **asks (sells)** are clearly shown. The available depth shows how a market order would move through quoted prices and affect its average execution price. --- ### Ramses CL Ramses CL is a **concentrated-liquidity AMM** designed for capital-efficient liquidity provision. Its price-level depth can resemble an order book, while swaps continue to execute through onchain liquidity. In a **Uniswap v2** liquidity pair, liquidity positions are spread across a range from 0 to infinity (`0,∞`). Each liquidity provider therefore distributes capital across the full positive price range. Full-range liquidity can be far less capital-efficient near the current market price than liquidity concentrated within a defined range such as **$3400-$3500**. Focusing liquidity around active prices creates more depth per dollar and can reduce price impact while that liquidity remains in range. ![Position Overview](https://www.ramses.xyz/docs-assets/positionoverview.png) The **price-history overlay** shows the pool's recent trading range, helping liquidity providers assess volatility before selecting a position range. The **liquidity-depth view** shows how capital is distributed across initialized prices for the selected [fee tier](https://www.ramses.xyz/docs/concentrated-liquidity#fee-tiers). The **horizontal markers** represent the **range** of the position. In the context of automated market makers (AMMs), a **"range"** is an interval between two usable ticks. The marker also displays the number of ticks within the range. --- ### Order Book View ![Order Book View](https://www.ramses.xyz/docs-assets/orderbookview.png) The order book view presents concentrated-liquidity positions in a familiar format. It helps users compare available ranges and manage positions using a price-level layout. --- ### Alice and Bob Consider Alice and Bob providing liquidity to a **HYPE / USD₮0** pool with HYPE at **$50**. Each has **$1,000,000** available, but they take different approaches: | Alice's AMM Strategy | Bob's CL Strategy | | --- | --- | | Spreads her entire **$1,000,000** across the full price range in a passive full-range position. | Allocates about **$49,000** within the **$45-$55** price range and keeps about **$951,000** for other opportunities. | | Provides full-range liquidity at every positive price. | Provides approximately the same liquidity depth as Alice while HYPE remains between **$45 and $55**, using less deposited capital. | | Remains active across the full price curve. | Becomes inactive and entirely one-sided after price moves beyond a range boundary, until price re-enters the range or Bob adjusts the position. | > **Illustrative Assumptions** > > The estimate uses standard concentrated-liquidity formulas at a $50 spot price, before fees and rounding. Concentrated liquidity can provide more depth per dollar while a position is active. Fees and rewards depend on volume, active-liquidity share, time in range, and gauge eligibility. An out-of-range position stops earning swap fees and becomes entirely one-sided until price returns or the LP adjusts it. --- ## Competitive Farming Competitive farming rewards liquidity that is active and eligible for a pool's gauge. In concentrated liquidity models, users choose the tick-aligned price interval in which they want to provide liquidity. ### What are the benefits? Active, gauge-eligible liquidity can earn RAM emissions according to xRAM votes. Productive liquidity also improves execution and can help a pool become a preferred routing destination for aggregators. Trading volume generates swap fees. Under the default Ramses configuration, gauged pools direct those fees to xRAM voters, while RAM emissions paid to eligible LPs depend on gauge votes. ![CL](https://www.ramses.xyz/docs-assets/CL.png) ### How does this differ from other models? Unlike full-range positions, concentrated liquidity lets LPs choose where their capital is active. Narrower ranges create more depth per dollar and require closer management as the market price moves. --- ## Range Orders In order books, a trader can place a **limit order** to buy or sell an asset at a specified price. Concentrated-liquidity range orders approximate that behavior but have different execution and inventory mechanics. With concentrated liquidity, **you can approximate a limit order by providing a single asset as liquidity within a specific range.** Like traditional limit orders, range orders are set with the expectation they will execute at some point in the future, with the target asset available for withdrawal after the spot price has crossed the full range of the order. > **Important** > > A range order is still a liquidity position. While active, it can earn swap fees and eligible gauge rewards. ### Take-Profit Order #### Selling **HYPE** for **USD₮0** The current price of the **HYPE / USD₮0** pool is **$40**. To begin selling HYPE when price reaches approximately **$45**, you can provide HYPE in a range such as **$45-$46**. The position converts HYPE into USD₮0 as price moves through the range and is fully converted only after price crosses the upper boundary. Execution occurs across the range, not at one exact price. --- ### Buy Limit Order #### Selling **USD₮0** for **HYPE** The current price of the **HYPE / USD₮0** pool is **$45**. To begin buying HYPE if price falls to approximately **$42**, you can provide USD₮0 in a range such as **$41-$42**. The position begins converting below the upper boundary and is fully converted only after price crosses the lower boundary. > **Caution** > > Unlike a traditional limit order, a range order remains active after it has converted. If price reverses through the range before the liquidity is removed, the position can automatically convert back into the original asset. Remove liquidity after full conversion if the goal is to keep the destination asset. A tighter range narrows the execution interval but does not remove reversal risk. ### Range-Order Limits CL range orders convert inventory only as price moves through the selected range. Stop orders on the opposite side of the current market require a different order type. Choose the execution interval carefully: wider ranges execute across more prices, while narrower ranges concentrate more liquidity per dollar. --- ## Fee Tiers Ramses supports the following core fee tiers. Robinhood Chain also supports **3%** and **5%** tiers for higher-volatility markets. The app shows the tiers available on the selected chain. | Fee Tier | Tick Spacing | Best Used For | | --- | --- | --- | | **0.01%** | 1 | Highly correlated and pegged assets | | **0.025%** | 5 | Competitive asset classes with moderate volatility | | **0.05%** | 10 | Standard fee tier for most trading pools | | **0.3%** | 50 | Higher volatility assets | | **1%** | 100 | Exotic pairs with significant volatility | | **2%** | 200 | Highly volatile or illiquid assets | | **3%** *(Robinhood Chain)* | 300 | Higher-volatility markets | | **5%** *(Robinhood Chain)* | 500 | Extreme-volatility or thin-liquidity markets | ### Distribution By default, swap fees are distributed according to the pool's gauge state: | Pool State | Liquidity Providers | xRAM Voters | Protocol | | --- | --- | --- | --- | | **Gauged** | 0% | 100% | 0% | | **Fee-only / Ungauged** | 95% | 0% | 5% | > **Pool Configuration** > > These are the default splits. A pool's active configuration may differ. --- # DLMM Learn how Ramses DLMM pools use discrete price bins, dynamic fees, and auto-compounding LP fees. Source: https://www.ramses.xyz/docs/dlmm ## What is DLMM? A Discretized Liquidity Market Maker (DLMM) divides the price curve into discrete **bins**. Each bin represents one fixed price and holds its own token reserves. Liquidity providers choose which bins to fund. Traders use the liquidity in the active bin first, then move through the next available bins when a swap requires more liquidity. This lets LPs concentrate capital around the prices where they expect trading to occur. | Feature | DLMM | Concentrated liquidity | | --- | --- | --- | | Price unit | Fixed-price bins | Price ranges between ticks | | Swap behavior | Fixed price within a bin, then steps to another bin | Price changes continuously through active liquidity | | Position format | Fungible shares in each funded bin | NFT position covering a tick range | | LP fee accounting | Retained in bin reserves and reflected in share value | Accrued to the position for collection | > **Current deployment** > > Ramses DLMM is live on **Robinhood Chain**. Current pools operate in fee-only mode, so LP returns come from auto-compounding swap fees. See the [technical deployment reference](https://tech.ramses.xyz/contracts/reference/dlmm/deployments) for contract details. ## How bins work ### Bin step The **bin step** controls the percentage difference between neighboring bins. A bin step of 1 represents one basis point, or 0.01%, between adjacent price levels. A larger bin step creates more distance between bins. Each pool has one active bin: - Bins on one side of the active price hold one token. - Bins on the other side hold the other token. - The active bin can hold both tokens. The exact token on each side depends on the pool's token ordering. ### Price movement A swap executes at one fixed price while it remains within a bin. When that bin no longer has enough liquidity for the trade, execution continues at the next non-empty bin. Empty bins can be skipped. Crossing more bins means greater price impact. The app's minimum received and slippage settings protect users if the available liquidity or price changes before execution. ## Providing liquidity ### Choosing a range An LP selects a range of bins and deposits the token amounts needed for that range. The position earns fees only in bins used by swaps. A narrow range concentrates more capital near the current price and can earn more while active, but it is also more likely to move out of range. A wider range covers more price movement but spreads the same capital across more bins. As the market moves: - Liquidity near the active bin can hold both tokens. - Liquidity away from the active bin becomes one-sided. - A position outside the traded bins does not earn swap fees until trading returns to its range. ### Fees auto-compound The LP portion of swap fees stays inside the bins and increases the reserves backing their shares. LPs do not make a separate claim for these fees; they are received when liquidity is removed. Adding liquidity with a token ratio that differs from the active bin's composition can incur a composition fee. The app displays transaction details before submission. ### Removing liquidity Removing liquidity burns the holder's bin shares and returns the corresponding share of the bin reserves. Only the holder or an approved operator can remove them. ## Fees and rewards DLMM swap fees combine: - A base fee determined by pool configuration. - A variable fee that reacts to recent **on-chain** bin movement and trading activity. Dynamic fees respond to onchain bin movement and trading activity and remain capped by contract-defined limits. The current fee is displayed with each pool in the app. | Pool state | LP share of swap fees | Voter/protocol share | Emissions | | --- | --- | --- | --- | | Fee-only (ungauged) | 95% | 5% to the protocol | None | | Gauged | 0% | 100% to voters | Eligible | ## Risks DLMM positions can: - Become mostly or entirely one token as swaps move through their bins. - Stop earning fees when trading activity moves outside their selected bins. - Underperform simply holding the tokens when their relative prices move. ## Learn more - [Technical DLMM overview](https://tech.ramses.xyz/concepts/protocol/dlmm) - [Developer integration guide](https://tech.ramses.xyz/contracts/guides/dlmm/integration) - [Contract architecture](https://tech.ramses.xyz/contracts/reference/dlmm/overview) - [Ramses contract addresses](https://www.ramses.xyz/docs/contract-addresses) - [Concentrated liquidity](https://www.ramses.xyz/docs/concentrated-liquidity) --- # Ramses X Ramses X is Ramses' live multichain architecture for shared tokenomics, LayerZero OFT connectivity, chain-specific execution, and fee-first deployments. Source: https://www.ramses.xyz/docs/ramses-x ## From Governance DEX to DeFi Infrastructure Ramses has matured beyond a single-chain, governance-heavy DEX. **Ramses X** is its live multichain architecture: automation, fee-first deployments, and shared tokenomics while each chain retains its own execution and liquidity. **One token economy. Multiple chains.** ### [RAM & OFT Network](https://www.ramses.xyz/docs/ramses-x#ram-token-and-oft-connectivity) HyperEVM is RAM's current home and the canonical side of the live LayerZero network. Ethereum Mainnet is the eventual hub, but its route is inactive. ### [Fee-First Deployments](https://www.ramses.xyz/docs/ramses-x#chain-structure-and-fee-handling) Fee-only or ungauged pools default to 95% of swap fees for LPs and a 5% protocol share. ### [Buyback Module](https://www.ramses.xyz/docs/buyback-module) Robinhood protocol fees fund authorized RAM buybacks, with RAM sent permanently to the dead address. ### [AutoVaults](https://www.ramses.xyz/docs/autovaults) Stake xRAM, select a reward token, automate voting and conversion, then claim converted rewards. --- ## Architecture Overview Ramses X is already live as multichain infrastructure. Its architecture combines **native RAM and r33 on HyperEVM with live OFT connectivity**, **chain-specific execution and liquidity**, and a **fee-powered deflationary module**. The eventual Ethereum hub will change the token network's center; it is not what makes Ramses X multichain. --- ## RAM Token & OFT Connectivity **HyperEVM is the current home of RAM and the canonical side of the live LayerZero OFT network.** RAM and r33 can move among HyperEVM, Base, Polygon, and Robinhood Chain. Native assets are locked or unlocked by the HyperEVM adapters, while the satellite OFTs mint or burn on transfer. **Ethereum Mainnet is intended to become the canonical hub later, but its route is not currently active.** Execution, liquidity, and governance remain chain-specific even where OFT connectivity is live. | Component | Current Role | | --- | --- | | **RAM on HyperEVM** | Current native RAM token and home of the coin | | **HyperEVM Adapters** | Live lockboxes for native RAM and r33 entering or leaving the OFT network | | **RamsesOFT Satellites** | Live RAM and r33 representations on Base, Polygon, and Robinhood Chain | | **Ethereum Route** | Configured but inactive; intended to become the canonical hub later | | **Messaging Fees** | Live cross-chain transfers require source-chain gas and a quoted LayerZero messaging fee | The live OFT architecture is designed to: - Maintain coordinated RAM supply accounting across connected chains - Avoid independently issued RAM tokens - Preserve chain-specific execution, liquidity pools, and governance state **OFT connectivity unifies token supply accounting; it does not unify liquidity across chains.** --- ## Chain Structure & Fee Handling A Ramses X deployment can operate with **governance inactive** and fee-only or ungauged liquidity, then activate governance through a published, deployment-specific process. ### Fee-Only Mode In this initial phase: | Feature | Status | | --- | --- | | LP fee share | 95% of swap fees | | Protocol share | 5% of swap fees | | Emissions | Inactive | | Gauges & Voting | Inactive | On Robinhood Chain, the protocol share is routed to the [Buyback Module](https://www.ramses.xyz/docs/buyback-module), which replaced the Sarcophagus on October 14, 2026. Authorized execution converts accumulated fee assets into RAM and sends the RAM to the dead address. Other deployments use their own configured fee recipients. No emissions are distributed during the fee-only phase. ### Governance-Active Mode Governance can be enabled after the deployment-specific activation criteria and responsible process are published. Activation is not automatic; it requires the applicable administrative or governance actions for that chain. At that point: | Feature | Status | | --- | --- | | LP fee share | 0% by default for gauged pools | | xRAM voter fee share | 100% by default for gauged pools | | RAM emissions | Active and directed by gauge votes | | Voters | Earn fees plus incentives | | Revenue stream | Backed by real activity | **The intended sequence is demand first, incentives second.** > **Governance Activation** > > Activation criteria, responsible roles, and relevant contract changes are published before governance is enabled on a chain. --- ## What This Enables | Outcome | Benefit | | --- | --- | | **Coordinated Supply** | The live HyperEVM adapters and satellite OFTs maintain shared supply accounting; Ethereum remains the eventual hub | | **Independent Scaling** | Chains retain independent execution and liquidity while starting fee-only | | **Published Governance Activation** | Governance activation follows a deployment-specific process published before activation | | **Explicit Fee States** | Fee-only pools use the 95% LP / 5% protocol split; gauged pools default to 100% for voters | | **Automation** | AutoVaults remove manual voting while preserving user-controlled claims | Ramses X is Ramses' live evolution from a governance-centric DEX into **modular multichain DeFi infrastructure**. --- ## Ramses X Network Status | Chain | Current Ramses X Role | Status | | --- | --- | --- | | **HyperEVM** | Current home of native RAM and r33; live OFT adapters, DEX, and token governance | Live | | **Base** | Live RAM and r33 OFT satellite; no Ramses DEX deployment | OFT live | | **Polygon** | Live RAM and r33 OFT satellite plus a chain-specific Ramses DEX deployment | Live | | **Robinhood Chain** | Live RAM and r33 OFT satellite plus a chain-specific Ramses DEX deployment | Live | | **Arbitrum** | Chain-specific Ramses DEX deployment; not an active RAM or r33 OFT route | DEX live | | **Ethereum** | Configured inactive OFT route and eventual canonical hub | Route inactive | > **Deployment Status** > > Ramses X and its HyperEVM, Base, Polygon, and Robinhood OFT network are live independently of the eventual Ethereum hub. New deployment-specific OFT, buyback, DEX, and governance addresses will be published in the contract-addresses documentation when available. --- # Audits Published security reviews, competition reports, and administrative-control disclosures for Ramses. Source: https://www.ramses.xyz/docs/audits ## Published Security Reviews Ramses publishes its available security reviews so users and integrators can inspect their scope, findings, and remediation details directly. ### Ramses V3 Review | [**Consensys**](https://diligence.consensys.io/audits/2024/08/ramses-v3) ![Consensys Diligence audit cover](https://www.ramses.xyz/docs-assets/consensysaudit.png) | | --- | ### Security Competition The [Code4rena Ramses V3 CLMM contest report](https://code4rena.com/reports/2024-10-ramses-exchange) documents the competition scope, findings, and mitigations. ### Ramses-Commissioned Shared-Code Reviews Ramses also commissioned the following reviews of Ramses-derived or shared core codebases used by other projects. The linked public engagement targets are **Etherex Contracts** and **shadow-x33**, respectively. These reports may inform Ramses' security work, but they are not Ramses deployment-specific audit reports. | [**Spearbit — Etherex Contracts**](https://cantina.xyz/portfolio/48fc9b98-ded3-43fa-80a2-5aedb3a5a51e) ![Spearbit Etherex review cover](https://www.ramses.xyz/docs-assets/etherexaudit.png) | [**Cantina — shadow-x33**](https://cantina.xyz/portfolio/98695d75-ee7d-4e1c-aa96-6379f73c5b2c) ![Cantina shadow-x33 review cover](https://www.ramses.xyz/docs-assets/shadowaudit.png) | | --- | --- | --- ## Custody and Administrative Controls Ramses V2 and V3 liquidity pools are noncustodial: AccessHub cannot arbitrarily withdraw an LP's deposits or transfer a user's V3 position NFT. A withdrawal still requires control of the relevant LP token or position NFT, or an approval granted by its owner through the normal pool and position-manager interfaces. Noncustodial pools do not make the surrounding system immutable. Authorized AccessHub, multisig, and timelock paths can change protocol configuration—including fees and fee splits, gauge status, emissions, reward settings, token whitelists, tick-spacing availability, fee collection, designated dependencies, and some implementations. These controls can change the economic and governance conditions around a position even though they do not give administrators custody of that individual position. AccessHub uses three primary roles in addition to functions restricted directly to the treasury multisig or timelock: - `DEFAULT_ADMIN_ROLE` can grant and revoke AccessHub roles. - `PROTOCOL_OPERATOR` manages gauges, emissions, rewards, whitelists, tick spacings, and several treasury, fee, and factory parameters. - `SWAP_FEE_SETTER` manages pool swap fees and participates in fee-split and dynamic-fee maintenance paths. Role holders and the balance between multisig and timelock control are deployment-specific. Verify current addresses and permissions onchain before interacting with a deployment. --- # Contract Addresses Published contract addresses and deployment statuses for Ramses across supported chains. Source: https://www.ramses.xyz/docs/contract-addresses Ramses DEX deployments and RAM/r33 OFT routes are separate networks. The OFT table shows token connectivity, while the chain tabs show published deployment-specific contracts. Base is OFT-only among the deployments listed here and therefore has no DEX tab. Arbitrum and Elysium have DEX contract listings and no listed live RAM or r33 OFT route. HyperEVM, Polygon, and Robinhood Chain have both a Ramses DEX deployment and live OFT connectivity. **r33** is the liquid staked xRAM token, known as **hyperRAM on HyperEVM**. Both names refer to the same product; the tables below identify its contract on each listed network. ## RAM & r33 OFT Network | Chain | RAM Endpoint | r33 Endpoint | Status | | --- | --- | --- | --- | | **HyperEVM** | [Native RAM](https://hyperevmscan.io/address/0x555570a286F15EbDFE42B66eDE2f724Aa1AB5555) · [Adapter](https://hyperevmscan.io/address/0xe1C39b767E968a57aF2Ecad2F5b09eE2E7874D9f) | [Native r33 / hyperRAM](https://hyperevmscan.io/address/0x5555c2542836e7a6c8D3E133D5AA9773b65D5555) · [Adapter](https://hyperevmscan.io/address/0xA4C83170f2A1410681D586a1e8C2E4620a93a081) | Current home; live | | **Base** | [RAM OFT](https://basescan.org/address/0x03FE4dd36DB2c8483E258974Db82D07d82F8d239) | [r33 OFT](https://basescan.org/address/0xADd32480630A16dfAcEe6eeFcB3ab2181449Dc3B) | Live satellite | | **Polygon** | [RAM OFT](https://polygonscan.com/address/0x8483F906187c45cC2b491F26dBbDD7C3231597e8) | [r33 OFT](https://polygonscan.com/address/0xe3Bc31a2F12ACFF0e5ffb2b37985fDd913b98B7a) | Live satellite | | **Robinhood Chain** | [RAM OFT](https://robin.etherscan.io/address/0x5173D45A1191eE33cBB7D8c7e65f21B04eD54802) | [r33 OFT](https://robin.etherscan.io/address/0x4e5195469A0360f5dfe811730C9CCaCFF0a0FeeE) | Live satellite | | **Ethereum Mainnet** | [Configured RAM endpoint](https://etherscan.io/address/0x95CBe89A7712ad5b99ff2956e9d5369fC65959eb) | [Configured r33 endpoint](https://etherscan.io/address/0x2eBd7B85a4E08D5B508b04BA147976C94afE6590) | Route inactive; eventual hub | > **DEX and OFT Availability** > > Base appears in the OFT table because its RAM and r33 satellite contracts are live, but no Ramses DEX deployment is listed there. Arbitrum and Elysium appear in the DEX tabs with their published Ramses contracts; neither has a RAM or r33 OFT route listed here. Ethereum has configured OFT endpoints, but the route remains inactive. --- ## Ethereum ## Ethereum Mainnet ### Core Contracts | Contract Name | Contract Address | | --- | --- | | RAM OFT Endpoint (Inactive) | [0x95CBe89A7712ad5b99ff2956e9d5369fC65959eb](https://etherscan.io/address/0x95CBe89A7712ad5b99ff2956e9d5369fC65959eb) | | r33 OFT Endpoint (Inactive) | [0x2eBd7B85a4E08D5B508b04BA147976C94afE6590](https://etherscan.io/address/0x2eBd7B85a4E08D5B508b04BA147976C94afE6590) | > **Ethereum Deployment** > > HyperEVM is RAM's current home. The configured Ethereum endpoints are disabled, and Ethereum Mainnet is not currently offered as an OFT route. It is intended to become the canonical hub later; activation details will be published when that transition occurs. ## Arbitrum ## Arbitrum ### V2 AMM (Legacy) | Contract Name | Contract Address | | --- | --- | | PairFactory | [0xADd32480630A16dfAcEe6eeFcB3ab2181449Dc3B](https://arbiscan.io/address/0xADd32480630A16dfAcEe6eeFcB3ab2181449Dc3B) | | Legacy Router | [0x1614a7e1fe63960B4684867a62080acd2404757f](https://arbiscan.io/address/0x1614a7e1fe63960B4684867a62080acd2404757f) | | FeeRecipientFactory | [0x8483F906187c45cC2b491F26dBbDD7C3231597e8](https://arbiscan.io/address/0x8483F906187c45cC2b491F26dBbDD7C3231597e8) | --- ### V3 AMM (Concentrated Liquidity) | Contract Name | Contract Address | | --- | --- | | RamsesV3Factory | [0xd0019e86edB35E1fedaaB03aED5c3c60f115d28b](https://arbiscan.io/address/0xd0019e86edB35E1fedaaB03aED5c3c60f115d28b) | | Init Code Hash | `0x892f127ed4b26ca352056c8fb54585a3268f76f97fdd84d5836ef4bda8d8c685` | | FeeCollector | [0xa22bE6E1a1a5A22b3a52De872bB757CD5F45dC32](https://arbiscan.io/address/0xa22bE6E1a1a5A22b3a52De872bB757CD5F45dC32) | | RamsesV3PoolDeployer | [0xb722efaAbe807FAeA16068f595EaA9aa1a62CECD](https://arbiscan.io/address/0xb722efaAbe807FAeA16068f595EaA9aa1a62CECD) | | RamsesV3PositionManager | [0x807a31EF83342D279a1F7708Adbc3492405A4CbC](https://arbiscan.io/address/0x807a31EF83342D279a1F7708Adbc3492405A4CbC) | | NonfungibleTokenPositionDescriptor | [0xFCBBe2Af83F94e7E2a9C35a535B3A04719aFD2Ae](https://arbiscan.io/address/0xFCBBe2Af83F94e7E2a9C35a535B3A04719aFD2Ae) | | UniversalRouter | [0x23B6EC50Fe0197FbE436717a0676BC07c54ba562](https://arbiscan.io/address/0x23B6EC50Fe0197FbE436717a0676BC07c54ba562) | | QuoterV2 | [0x00d4FeA3Dd90C4480992f9c7Ea13b8a6A8F7E124](https://arbiscan.io/address/0x00d4FeA3Dd90C4480992f9c7Ea13b8a6A8F7E124) | | QuoterV1 | [0x0C20C6E42242DB7AF259CC40366A07B198f2C295](https://arbiscan.io/address/0x0C20C6E42242DB7AF259CC40366A07B198f2C295) | | TickLens | [0x33D3CDD45E4D64Ea762574789A2DB4842EC8262E](https://arbiscan.io/address/0x33D3CDD45E4D64Ea762574789A2DB4842EC8262E) | | UniswapInterfaceMulticall | [0xbFbb2BCBc9dfFA029C27A249ae9BE031E1d83b1C](https://arbiscan.io/address/0xbFbb2BCBc9dfFA029C27A249ae9BE031E1d83b1C) | | MixedRouteQuoterV1 | [0x7b062f643A3FdB62370dfa2FA01807F682424115](https://arbiscan.io/address/0x7b062f643A3FdB62370dfa2FA01807F682424115) | | SwapRouter | [0x4730e03EB4a58A5e20244062D5f9A99bCf5770a6](https://arbiscan.io/address/0x4730e03EB4a58A5e20244062D5f9A99bCf5770a6) | --- ### Access Control | Contract Name | Contract Address | | --- | --- | | AccessHub | [0xd21eEB527414Ff97208C7DfBC9C9eCa520341a78](https://arbiscan.io/address/0xd21eEB527414Ff97208C7DfBC9C9eCa520341a78) | | ProxyAdmin | [0x5A827a245d322bB52b1d5664683BaA53556d39Df](https://arbiscan.io/address/0x5A827a245d322bB52b1d5664683BaA53556d39Df) | ## HyperEVM ## HyperEVM ### Governance | Contract Name | Contract Address | | --- | --- | | RAM Token | [0x555570a286F15EbDFE42B66eDE2f724Aa1AB5555](https://hyperevmscan.io/address/0x555570a286F15EbDFE42B66eDE2f724Aa1AB5555) | | xRAM Token | [0xAE6D5FcE541216BDA471D311425B5412D9f1DEb9](https://hyperevmscan.io/address/0xAE6D5FcE541216BDA471D311425B5412D9f1DEb9) | | r33 — xRAM Liquid Staking Token (hyperRAM on HyperEVM) | [0x5555c2542836e7a6c8D3E133D5AA9773b65D5555](https://hyperevmscan.io/address/0x5555c2542836e7a6c8D3E133D5AA9773b65D5555) | | Voter | [0x9aab8C415aF5936b09C595B09B1ff15cbaDCD843](https://hyperevmscan.io/address/0x9aab8C415aF5936b09C595B09B1ff15cbaDCD843) | | VoteModule | [0x6736102621f7c0dbB0E2989e3ad7A8793e71930b](https://hyperevmscan.io/address/0x6736102621f7c0dbB0E2989e3ad7A8793e71930b) | | Minter | [0x252aCC15430a26748CED7376b317e74e250FcF00](https://hyperevmscan.io/address/0x252aCC15430a26748CED7376b317e74e250FcF00) | | AutoVault | [0xdC88bAa97AB3284229D94d6CdabB88A66E809014](https://hyperevmscan.io/address/0xdC88bAa97AB3284229D94d6CdabB88A66E809014) | --- ### HyperCore Transfers coRAM is the HyperEVM contract linked to RAM on HyperCore. Hyperliquid's RAM system address fulfills transfers between HyperCore and HyperEVM for token index 400. See [Hyperliquid's transfer documentation](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/hypercore-less-than-greater-than-hyperevm-transfers). | Contract / System Address | Address | | --- | --- | | coRAM (Core RAM Proxy) | [0xcbcAbD0Af1aAc3209380aC606938d04DEDd49C8d](https://hyperevmscan.io/address/0xcbcAbD0Af1aAc3209380aC606938d04DEDd49C8d) | | Hyperliquid RAM Transfer System Address | [0x2000000000000000000000000000000000000190](https://hyperevmscan.io/address/0x2000000000000000000000000000000000000190) | --- ### V2 AMM (Legacy) | Contract Name | Contract Address | | --- | --- | | PairFactory | [0xd0a07E160511c40ccD5340e94660E9C9c01b0D27](https://hyperevmscan.io/address/0xd0a07E160511c40ccD5340e94660E9C9c01b0D27) | | Legacy Router | [0xdcC44285fBc236457A5cd91C2f77AD8421B0D8ED](https://hyperevmscan.io/address/0xdcC44285fBc236457A5cd91C2f77AD8421B0D8ED) | | Legacy GaugeFactory | [0x1AD1DC4430bD55FbD19f151F6f3CDB4Bb473Fa16](https://hyperevmscan.io/address/0x1AD1DC4430bD55FbD19f151F6f3CDB4Bb473Fa16) | | FeeDistributorFactory | [0xE7E05591362a74D3746F828941ec833e102a6E90](https://hyperevmscan.io/address/0xE7E05591362a74D3746F828941ec833e102a6E90) | | FeeRecipientFactory | [0xa0BDd8142568d478D69C0D601D46bfdDa04A7c4a](https://hyperevmscan.io/address/0xa0BDd8142568d478D69C0D601D46bfdDa04A7c4a) | --- ### V3 AMM (Concentrated Liquidity) | Contract Name | Contract Address | | --- | --- | | RamsesV3Factory | [0x07E60782535752be279929e2DFfDd136Db2e6b45](https://hyperevmscan.io/address/0x07E60782535752be279929e2DFfDd136Db2e6b45) | | Init Code Hash | `0x892f127ed4b26ca352056c8fb54585a3268f76f97fdd84d5836ef4bda8d8c685` | | FeeCollector | [0xA22fc9950bE328D8a32a8c1e2c92eAc4e6bADa00](https://hyperevmscan.io/address/0xA22fc9950bE328D8a32a8c1e2c92eAc4e6bADa00) | | RamsesV3PoolDeployer | [0x301d2E3c7Db5904b3971cf9C36195e37c5a14873](https://hyperevmscan.io/address/0x301d2E3c7Db5904b3971cf9C36195e37c5a14873) | | RamsesV3GaugeFactory | [0xE17988013E15d29B655634Da0056ba27BA4D3E27](https://hyperevmscan.io/address/0xE17988013E15d29B655634Da0056ba27BA4D3E27) | | RamsesV3PositionManager | [0xB3F77C5134D643483253D22E0Ca24627aE42ED51](https://hyperevmscan.io/address/0xB3F77C5134D643483253D22E0Ca24627aE42ED51) | | NonfungibleTokenPositionDescriptor | [0x615875E9141301EdEF36D17542CcdBb9b7512fE7](https://hyperevmscan.io/address/0x615875E9141301EdEF36D17542CcdBb9b7512fE7) | | UniversalRouter | [0xc43b33b5DF826A48DAE764817647824ED4f476a7](https://hyperevmscan.io/address/0xc43b33b5DF826A48DAE764817647824ED4f476a7) | | QuoterV2 | [0x403Bf94fe505cA0F0b1563C350B57dCeC8303ECd](https://hyperevmscan.io/address/0x403Bf94fe505cA0F0b1563C350B57dCeC8303ECd) | | QuoterV1 | [0x5126e63dD031301ACCDf1a5137EA5CAEB1125D52](https://hyperevmscan.io/address/0x5126e63dD031301ACCDf1a5137EA5CAEB1125D52) | | TickLens | [0x3F96AF2E8184838355249b8580cbFDAafA16bA5a](https://hyperevmscan.io/address/0x3F96AF2E8184838355249b8580cbFDAafA16bA5a) | | UniswapInterfaceMulticall | [0xD933929feBCe5494677EC22b7e7FaCA956311d37](https://hyperevmscan.io/address/0xD933929feBCe5494677EC22b7e7FaCA956311d37) | | MixedRouteQuoterV1 | [0x771b960165f9F3D79C2380C4CFC75b91E70d480f](https://hyperevmscan.io/address/0x771b960165f9F3D79C2380C4CFC75b91E70d480f) | | SwapRouter | [0x76D91074B46fF76E04FE59a90526a40009943fd2](https://hyperevmscan.io/address/0x76D91074B46fF76E04FE59a90526a40009943fd2) | --- ### Access Control | Contract Name | Contract Address | | --- | --- | | Ramses Team Multisig | [0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A](https://hyperevmscan.io/address/0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A) | | Ramses Timelock | [0xeaFD832EBB6a793A60E2b748392b3766ef62FA59](https://hyperevmscan.io/address/0xeaFD832EBB6a793A60E2b748392b3766ef62FA59) | | AccessHub ProxyAdmin | [0x428c031fFC2cDA747aD66e8bb8384988D60bD93B](https://hyperevmscan.io/address/0x428c031fFC2cDA747aD66e8bb8384988D60bD93B) | | AccessHub | [0x6631a487d59893831b331653225E0bfeBf6Ea1EC](https://hyperevmscan.io/address/0x6631a487d59893831b331653225E0bfeBf6Ea1EC) | ## Robinhood ## Robinhood ### Governance | Contract Name | Contract Address | | --- | --- | | RAM Token | [0x5173D45A1191eE33cBB7D8c7e65f21B04eD54802](https://robin.etherscan.io/address/0x5173D45A1191eE33cBB7D8c7e65f21B04eD54802) | | r33 — xRAM Liquid Staking Token (known as hyperRAM on HyperEVM) | [0x4e5195469A0360f5dfe811730C9CCaCFF0a0FeeE](https://robin.etherscan.io/address/0x4e5195469A0360f5dfe811730C9CCaCFF0a0FeeE) | | [Sarcophagus (Legacy)](https://www.ramses.xyz/docs/sarcophagus) | [0x712567e71a93Fb111510A790cAf3469677aAba3e](https://robin.etherscan.io/address/0x712567e71a93Fb111510A790cAf3469677aAba3e) | | [Buyback Module](https://www.ramses.xyz/docs/buyback-module) | [0x74F1e8Be68Ae7bf24Bc387Ee1a900d5bC23317a3](https://robin.etherscan.io/address/0x74F1e8Be68Ae7bf24Bc387Ee1a900d5bC23317a3) | --- ### V2 AMM (Legacy) | Contract Name | Contract Address | | --- | --- | | PairFactory | [0x43B2Bf9f33036a02fC7A00935571c2A6b0108e66](https://robin.etherscan.io/address/0x43B2Bf9f33036a02fC7A00935571c2A6b0108e66) | | Legacy Router | [0x33D3CDD45E4D64Ea762574789A2DB4842EC8262E](https://robin.etherscan.io/address/0x33D3CDD45E4D64Ea762574789A2DB4842EC8262E) | | FeeRecipientFactory | [0xA87c8308722237F6442Ef4762B7287afB84fB191](https://robin.etherscan.io/address/0xA87c8308722237F6442Ef4762B7287afB84fB191) | --- ### V3 AMM (Concentrated Liquidity) | Contract Name | Contract Address | | --- | --- | | RamsesV3Factory | [0xE0c4ceb92d08CA985bB70fe0a22fEb121A9854A8](https://robin.etherscan.io/address/0xE0c4ceb92d08CA985bB70fe0a22fEb121A9854A8) | | FeeCollector | [0x2Bef16A0081565E72100D73CBe19B1Bd2d802380](https://robin.etherscan.io/address/0x2Bef16A0081565E72100D73CBe19B1Bd2d802380) | | RamsesV3PoolDeployer | [0x4b37359BF291AbE8453692DB58d515a8b013Dca9](https://robin.etherscan.io/address/0x4b37359BF291AbE8453692DB58d515a8b013Dca9) | | RamsesV3PositionManager | [0x2eBd7B85a4E08D5B508b04BA147976C94afE6590](https://robin.etherscan.io/address/0x2eBd7B85a4E08D5B508b04BA147976C94afE6590) | | RamsesLocker | [0xf6cd2e03259150d4ff745cdd620c09fbf30de1dc](https://robin.etherscan.io/address/0xf6cd2e03259150d4ff745cdd620c09fbf30de1dc) | | RamsesSelfCompounderV1_1 | [0xA62C8Cc946Ca3210Df59A3d4CB6C09845Bc9d85D](https://robin.etherscan.io/address/0xA62C8Cc946Ca3210Df59A3d4CB6C09845Bc9d85D) | | IncentivesHelper (LP Incentivizer) | [0xc389e1af91f197762608a3541e0ba90019e14a77](https://robin.etherscan.io/address/0xc389e1af91f197762608a3541e0ba90019e14a77#code) | | NonfungibleTokenPositionDescriptor | [0x486EC4dda7fEB9871eEF0d6ccc0D79dD3f7af7a4](https://robin.etherscan.io/address/0x486EC4dda7fEB9871eEF0d6ccc0D79dD3f7af7a4) | | UniversalRouter | [0xbFbb2BCBc9dfFA029C27A249ae9BE031E1d83b1C](https://robin.etherscan.io/address/0xbFbb2BCBc9dfFA029C27A249ae9BE031E1d83b1C) | | QuoterV2 | [0x4730e03EB4a58A5e20244062D5f9A99bCf5770a6](https://robin.etherscan.io/address/0x4730e03EB4a58A5e20244062D5f9A99bCf5770a6) | | QuoterV1 | [0x807a31EF83342D279a1F7708Adbc3492405A4CbC](https://robin.etherscan.io/address/0x807a31EF83342D279a1F7708Adbc3492405A4CbC) | | TickLens | [0x0C20C6E42242DB7AF259CC40366A07B198f2C295](https://robin.etherscan.io/address/0x0C20C6E42242DB7AF259CC40366A07B198f2C295) | | UniswapInterfaceMulticall | [0x00d4FeA3Dd90C4480992f9c7Ea13b8a6A8F7E124](https://robin.etherscan.io/address/0x00d4FeA3Dd90C4480992f9c7Ea13b8a6A8F7E124) | | MixedRouteQuoterV1 | [0x23B6EC50Fe0197FbE436717a0676BC07c54ba562](https://robin.etherscan.io/address/0x23B6EC50Fe0197FbE436717a0676BC07c54ba562) | | SwapRouter | [0xFCBBe2Af83F94e7E2a9C35a535B3A04719aFD2Ae](https://robin.etherscan.io/address/0xFCBBe2Af83F94e7E2a9C35a535B3A04719aFD2Ae) | --- ### DLMM | Contract Name | Contract Address | | --- | --- | | DLMMFactory | [0xdcD5F77697914E27f56FD263EF82923C8524AbAc](https://robin.etherscan.io/address/0xdcD5F77697914E27f56FD263EF82923C8524AbAc) | | DLMMFeeCollector | [0xcc543a9EDBa25cEB2922b165047b6A7bE861C55b](https://robin.etherscan.io/address/0xcc543a9EDBa25cEB2922b165047b6A7bE861C55b) | | DLMMRouter | [0xd0019e86edB35E1fedaaB03aED5c3c60f115d28b](https://robin.etherscan.io/address/0xd0019e86edB35E1fedaaB03aED5c3c60f115d28b) | | DLMMQuoter | [0xb722efaAbe807FAeA16068f595EaA9aa1a62CECD](https://robin.etherscan.io/address/0xb722efaAbe807FAeA16068f595EaA9aa1a62CECD) | --- ### Access Control | Contract Name | Contract Address | | --- | --- | | Ramses Team Multisig | [0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A](https://robin.etherscan.io/address/0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A) | | Ramses Timelock | [0xE41c07CcD69A0f19A2186f3Ad30409BD585436CE](https://robin.etherscan.io/address/0xE41c07CcD69A0f19A2186f3Ad30409BD585436CE) | | AccessHub ProxyAdmin | [0xA203A21dCCB461E415DaA342E8e635B6CeE0cCb3](https://robin.etherscan.io/address/0xA203A21dCCB461E415DaA342E8e635B6CeE0cCb3) | | AccessHub | [0x83341F891f898cb5E0cacC8a70501BBa83d9CecF](https://robin.etherscan.io/address/0x83341F891f898cb5E0cacC8a70501BBa83d9CecF) | ## Elysium ## Elysium ### Governance | Contract Name | Contract Address | | --- | --- | | RAM Token | [0x2ea9E66Adb86b0Ed71f79ab2e81a31147eDc3215](https://elysium.kinetiq.xyz/explorer/address/0x2ea9E66Adb86b0Ed71f79ab2e81a31147eDc3215) | | Voter | [0x136d9D100A7e0363fd521b483F5FaE2B94d8fA09](https://elysium.kinetiq.xyz/explorer/address/0x136d9D100A7e0363fd521b483F5FaE2B94d8fA09) | | Buyback Module | [0xE565310BAa582C768a77a3BB7F86a892eF07D04e](https://elysium.kinetiq.xyz/explorer/address/0xE565310BAa582C768a77a3BB7F86a892eF07D04e) | --- ### V2 AMM (Legacy) | Contract Name | Contract Address | | --- | --- | | PairFactory | [0x088703700f4FA35BF9EABc8CDbCeAD3678432779](https://elysium.kinetiq.xyz/explorer/address/0x088703700f4FA35BF9EABc8CDbCeAD3678432779) | | Legacy Router | [0xf296bb0EAeAB6703d876b1BFe9d5693eF302B855](https://elysium.kinetiq.xyz/explorer/address/0xf296bb0EAeAB6703d876b1BFe9d5693eF302B855) | | Legacy GaugeFactory | [0x677e397d76cc2135bD15f1821B8CbD9Aa7ab35F2](https://elysium.kinetiq.xyz/explorer/address/0x677e397d76cc2135bD15f1821B8CbD9Aa7ab35F2) | | FeeDistributorFactory | [0x922b9Ca8e2207bfB850B6FF647c054d4b58a2Aa7](https://elysium.kinetiq.xyz/explorer/address/0x922b9Ca8e2207bfB850B6FF647c054d4b58a2Aa7) | | FeeRecipientFactory | [0x5eC69825fC45A5bE55b87a12500Bf4DEbd613f89](https://elysium.kinetiq.xyz/explorer/address/0x5eC69825fC45A5bE55b87a12500Bf4DEbd613f89) | --- ### V3 AMM (Concentrated Liquidity) | Contract Name | Contract Address | | --- | --- | | RamsesV3Factory | [0x29cd8852FF040CfE74fb20277A121eD1293AFb41](https://elysium.kinetiq.xyz/explorer/address/0x29cd8852FF040CfE74fb20277A121eD1293AFb41) | | FeeCollector | [0x0a397Fe8808a49215C8FbF3B23FF48006dC5eDB9](https://elysium.kinetiq.xyz/explorer/address/0x0a397Fe8808a49215C8FbF3B23FF48006dC5eDB9) | | RamsesV3PoolDeployer | [0x71775Fee4867597c721ff9E8dD705CBad955325A](https://elysium.kinetiq.xyz/explorer/address/0x71775Fee4867597c721ff9E8dD705CBad955325A) | | RamsesV3GaugeFactory | [0x13A466998Ce03Db73aBc2d4DF3bBD845Ed1f28E7](https://elysium.kinetiq.xyz/explorer/address/0x13A466998Ce03Db73aBc2d4DF3bBD845Ed1f28E7) | | RamsesV3PositionManager | [0x6F17dB548544a19162E82b20c67aBee99960a89a](https://elysium.kinetiq.xyz/explorer/address/0x6F17dB548544a19162E82b20c67aBee99960a89a) | | NonfungibleTokenPositionDescriptor | [0xdc6ec215659ec876e61dE4967502e3D6DA127ac7](https://elysium.kinetiq.xyz/explorer/address/0xdc6ec215659ec876e61dE4967502e3D6DA127ac7) | | UniversalRouter | [0x5AcC35397D2ce81Ac54A4B1c6D9e1FB29F8EC6C6](https://elysium.kinetiq.xyz/explorer/address/0x5AcC35397D2ce81Ac54A4B1c6D9e1FB29F8EC6C6) | | QuoterV2 | [0xAdAe75447D112cfC401C952744de3E6d32456465](https://elysium.kinetiq.xyz/explorer/address/0xAdAe75447D112cfC401C952744de3E6d32456465) | | QuoterV1 | [0xc8B8fCbDb5C019D7802fFb0b39603395D7d3915c](https://elysium.kinetiq.xyz/explorer/address/0xc8B8fCbDb5C019D7802fFb0b39603395D7d3915c) | | TickLens | [0xB7297301b7CC659BB96D51754643A0Df6eEA2138](https://elysium.kinetiq.xyz/explorer/address/0xB7297301b7CC659BB96D51754643A0Df6eEA2138) | | UniswapInterfaceMulticall | [0x3a7Aeb3c33922073F4F23207D0ff247e9694A100](https://elysium.kinetiq.xyz/explorer/address/0x3a7Aeb3c33922073F4F23207D0ff247e9694A100) | | MixedRouteQuoterV1 | [0x3265d621c7d993151C8EB2aCd4902CdA0499A8a0](https://elysium.kinetiq.xyz/explorer/address/0x3265d621c7d993151C8EB2aCd4902CdA0499A8a0) | | SwapRouter | [0x0B4478e810D48B5882D4019D435A2f864Bab4F39](https://elysium.kinetiq.xyz/explorer/address/0x0B4478e810D48B5882D4019D435A2f864Bab4F39) | | IncentivesHelper (LP Incentivizer) | [0x549bcfA59Eb52cD1D00ed75ec4BbfCcf3023a7Ea](https://elysium.kinetiq.xyz/explorer/address/0x549bcfA59Eb52cD1D00ed75ec4BbfCcf3023a7Ea) | --- ### DLMM | Contract Name | Contract Address | | --- | --- | | DLMMFactory | [0xF31632C73B8775e45Ce6d2539dEb008cB766D51b](https://elysium.kinetiq.xyz/explorer/address/0xF31632C73B8775e45Ce6d2539dEb008cB766D51b) | | DLMMFeeCollector | [0x81dD8a1B210CA1e97cD090725791eBbCAB783D27](https://elysium.kinetiq.xyz/explorer/address/0x81dD8a1B210CA1e97cD090725791eBbCAB783D27) | | DLMMRouter | [0x6a4113ed0915bCf5E48e758e8f4cEBFFC07C66f9](https://elysium.kinetiq.xyz/explorer/address/0x6a4113ed0915bCf5E48e758e8f4cEBFFC07C66f9) | | DLMMQuoter | [0xf29778ee08161177f7fA702a15678F85f1F6a52C](https://elysium.kinetiq.xyz/explorer/address/0xf29778ee08161177f7fA702a15678F85f1F6a52C) | --- ### Access Control | Contract Name | Contract Address | | --- | --- | | Ramses Team Multisig | [0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A](https://elysium.kinetiq.xyz/explorer/address/0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A) | | Ramses Timelock | [0xe0E637573494f12695E66C3024A9115Bd97c9300](https://elysium.kinetiq.xyz/explorer/address/0xe0E637573494f12695E66C3024A9115Bd97c9300) | | AccessHub | [0x002233Da1C54E3ABbF98b58B18C2b0DC29885b89](https://elysium.kinetiq.xyz/explorer/address/0x002233Da1C54E3ABbF98b58B18C2b0DC29885b89) | | ProxyAdmin | [0x2793C55368C78FE9177Eae30307Cc843077dfC65](https://elysium.kinetiq.xyz/explorer/address/0x2793C55368C78FE9177Eae30307Cc843077dfC65) | ## Polygon ## Polygon ### V2 AMM (Legacy) | Contract Name | Contract Address | | --- | --- | | PairFactory | [0xA87c8308722237F6442Ef4762B7287afB84fB191](https://polygonscan.com/address/0xA87c8308722237F6442Ef4762B7287afB84fB191) | | Legacy Router | [0x753bd1c77A0a94498aC6ffa3821d6474178A2c9b](https://polygonscan.com/address/0x753bd1c77A0a94498aC6ffa3821d6474178A2c9b) | | FeeRecipientFactory | [0xbD77D7E873fbb9C56950cc61D82b76a0699A361B](https://polygonscan.com/address/0xbD77D7E873fbb9C56950cc61D82b76a0699A361B) | --- ### V3 AMM (Concentrated Liquidity) | Contract Name | Contract Address | | --- | --- | | RamsesV3Factory | [0x2Bef16A0081565E72100D73CBe19B1Bd2d802380](https://polygonscan.com/address/0x2Bef16A0081565E72100D73CBe19B1Bd2d802380) | | FeeCollector | [0x83341F891f898cb5E0cacC8a70501BBa83d9CecF](https://polygonscan.com/address/0x83341F891f898cb5E0cacC8a70501BBa83d9CecF) | | RamsesV3PoolDeployer | [0x43B2Bf9f33036a02fC7A00935571c2A6b0108e66](https://polygonscan.com/address/0x43B2Bf9f33036a02fC7A00935571c2A6b0108e66) | | RamsesV3PositionManager | [0xcc543a9EDBa25cEB2922b165047b6A7bE861C55b](https://polygonscan.com/address/0xcc543a9EDBa25cEB2922b165047b6A7bE861C55b) | | RamsesSelfCompoundor | [0xedcbF7FB53869030283D06a9478BdA8E08188512](https://polygonscan.com/address/0xedcbF7FB53869030283D06a9478BdA8E08188512) | | NonfungibleTokenPositionDescriptor | [0x14411EB0ee08B600E31cBaf591D403f9E026E51E](https://polygonscan.com/address/0x14411EB0ee08B600E31cBaf591D403f9E026E51E) | | UniversalRouter | [0x7Cb761B11bbF8CFF1283f683F07ED14f4025FC8d](https://polygonscan.com/address/0x7Cb761B11bbF8CFF1283f683F07ED14f4025FC8d) | | QuoterV2 | [0x3c4532424Eb018013595e4960Fd3de5397B6f571](https://polygonscan.com/address/0x3c4532424Eb018013595e4960Fd3de5397B6f571) | | QuoterV1 | [0x4e857A78bcE4FcF41677f21Bfaf3e77890d5042b](https://polygonscan.com/address/0x4e857A78bcE4FcF41677f21Bfaf3e77890d5042b) | | TickLens | [0x2aB9BDBDEF8FA045d07ae95c62c4196619FD0C23](https://polygonscan.com/address/0x2aB9BDBDEF8FA045d07ae95c62c4196619FD0C23) | | UniswapInterfaceMulticall | [0x25E0B133AD88B8cd60AFBD9DD7651FCC5FEc97bd](https://polygonscan.com/address/0x25E0B133AD88B8cd60AFBD9DD7651FCC5FEc97bd) | | MixedRouteQuoterV1 | [0x8327450eE0bE3d6904FBb5178C99e948576d8Cd5](https://polygonscan.com/address/0x8327450eE0bE3d6904FBb5178C99e948576d8Cd5) | | SwapRouter | [0xdcD5F77697914E27f56FD263EF82923C8524AbAc](https://polygonscan.com/address/0xdcD5F77697914E27f56FD263EF82923C8524AbAc) | --- ### Access Control | Contract Name | Contract Address | | --- | --- | | AccessHub Proxy | [0xE41c07CcD69A0f19A2186f3Ad30409BD585436CE](https://polygonscan.com/address/0xE41c07CcD69A0f19A2186f3Ad30409BD585436CE) | | ProxyAdmin | [0xeBA9Af6A98BEA3D894e06b653C72F11fA26872aA](https://polygonscan.com/address/0xeBA9Af6A98BEA3D894e06b653C72F11fA26872aA) | | ProxyOwner | [0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A](https://polygonscan.com/address/0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A) | --- # Disclaimer Important disclosures and disclaimers for Ramses users. Source: https://www.ramses.xyz/docs/disclaimers-and-legal Using Ramses involves material risk. The protocol is noncustodial, and users are responsible for understanding each transaction, the contracts and networks involved, and the effect of any approvals they grant before interacting with the platform. ## No Guarantees or Advice Ramses does not set or guarantee the market price, liquidity, rewards, returns, or future benefits of RAM, xRAM, r33 (called hyperRAM on HyperEVM), liquidity positions, or any other asset. Protocol mechanisms such as emissions, fee routing, burns, and market operations may affect supply or demand but do not guarantee value. Nothing in these docs is legal, tax, investment, or financial advice, or a promise of profit. Nothing here should be read as a legal conclusion about how any asset, transaction, or activity is classified. Classification and legal obligations depend on the facts, the user, the transaction, and the applicable jurisdiction. Users should obtain advice from qualified professionals where appropriate. ## Key Protocol Risks - **Smart-contract risk:** Contracts may contain defects, unexpected behavior, integration failures, or vulnerabilities. Audits and testing reduce risk but do not eliminate it. - **Market and liquidity risk:** Asset prices, liquidity, fees, incentives, and expected execution can change rapidly. Liquidity providers may experience impermanent loss, inventory imbalance, out-of-range positions, or loss exceeding earned fees and incentives. - **Administrative and governance risk:** Authorized roles, multisigs, timelocks, voters, and connected governance contracts can change supported parameters and protocol configuration. Compromised keys, governance failures, or unexpected administrative actions may cause loss. - **Oracle and integration risk:** Ramses may depend on tokens, price feeds, routers, aggregators, lending markets, bridges, interfaces, and other external contracts. Failure or manipulation of an external dependency can affect Ramses transactions and positions. - **Cross-chain risk:** Bridged or omnichain assets can be affected by bridge, messaging, relayer, validator, finality, replay, depegging, or destination-chain failures. - **Network and execution risk:** Congestion, chain reorganization, sequencer or validator outages, gas-price changes, failed transactions, slippage, sandwiching, arbitrage, and other MEV can alter execution or cause loss. - **Wallet and interface risk:** Compromised devices, wallets, frontends, RPC providers, domain names, token approvals, or signatures may result in unauthorized transactions or loss. Users should independently verify contract addresses and transaction details. - **Legal, regulatory, and tax risk:** Laws, regulatory treatment, access restrictions, reporting duties, and tax consequences vary by jurisdiction and may change. Users should conduct their own research, assess whether these risks are appropriate for them, and consider all potential outcomes before using Ramses. --- # kBUSL 1.1 License Summary of the Kingdom Business Source License 1.1 used by Ramses contract source. Source: https://www.ramses.xyz/docs/busl ## Kingdom Business Source License 1.1 The Ramses contract repository's canonical license is the **Kingdom Business Source License 1.1 (kBUSL 1.1)**. It is a **source-available, non-open-source license**. > **License Text Controls** > > This page is a plain-language summary, not legal advice. The repository's `LICENSE.txt` and each file's SPDX identifier control. Individual files may use a different license and must be reviewed separately. ## Permitted Without a Commercial License Subject to the complete license terms, kBUSL permits: - Viewing and copying the source - Modifying the source and creating derivative works - Redistributing copies and derivative works - Using the software for non-production purposes Copies and derivative works must include the license text and comply with its terms. ## Restricted Use You may not deploy or use the licensed software, or a derivative of it, in a production environment without explicit IP approval and a commercial license from the Licensor. For this license, restricted production environments expressly include: - Mainnets - Testnets - Sidechains - Other production deployments > **Production Deployment** > > Viewing, copying, modifying, and redistributing the source are not categorically prohibited. The core restriction is unapproved production deployment or use. ## Covered Source The repository-level license applies to the licensed work, while file-level SPDX identifiers identify exceptions or separately licensed files. For example: | File | SPDX Identifier | | --- | --- | | `Voter.sol` | `kBUSL-1.1` | | `GaugeV3.sol` | `kBUSL-1.1` | | `AutoVault.sol` | `kBUSL-1.1` | | `FeeDistributor.sol` | `BUSL-1.1` — review its applicable license separately | ## Change Date and License | Term | Value | | --- | --- | | **Change Date** | October 31, 2028 | | **Earlier Conversion** | The fourth anniversary of a version's public release, if earlier | | **Change License** | GNU General Public License version 2.0 or any later version | The license does not grant rights to Ramses trademarks, service marks, or logos except where expressly permitted. ## Commercial Licensing For production-use approval or a commercial license, contact: - **Social Unicorn Foundation LLC** - `management@ramses.exchange` - [ramses.xyz](https://ramses.xyz) --- # Introduction to DeFi Learn the core concepts behind decentralized finance and protocols such as Ramses. Source: https://www.ramses.xyz/docs/intro-to-defi ## What Is DeFi? As you explore Web3, you will encounter many new terms. DeFi is one of the most important concepts to understand. **DeFi, short for decentralized finance,** uses blockchains and smart contracts to provide financial services without relying solely on centralized intermediaries. These services can include exchanges, lending markets, asset custody tools, and other programmable financial applications. Developers and communities can deploy and govern DeFi applications. Compared with traditional finance, DeFi is designed to be **permissionless**, **transparent**, and less dependent on intermediaries, but it introduces smart-contract, market, operational, and self-custody risks. ![Comparison of traditional and decentralized finance](https://www.ramses.xyz/docs-assets/tradfi.png) --- # Onboarding How to get started with wallets and tokens on Ramses. Source: https://www.ramses.xyz/docs/onboarding ## On-Ramp/Off-Ramp To use DeFi, you need supported assets in a self-custody wallet on the correct network. Availability, identity requirements, fees, and withdrawal support vary by provider and jurisdiction. > **Verify the Network** > > Before withdrawing or bridging, confirm that the sending service, receiving wallet, token, and destination network all match. Sending an asset through an unsupported network can result in permanent loss. ### Choose a Wallet Ramses uses an EVM-compatible self-custody wallet. The wallet controls your accounts and displays transaction requests, but it cannot recover a lost seed phrase or reverse a signed transaction. Download wallet software only from its official source. Review its security model, supported networks, and recovery process before funding it. ## Put It All Together Each blockchain transaction requires its network's native gas token. The required token varies by deployment, so confirm the selected network and its gas requirements before withdrawing funds. 1. Install and back up a compatible self-custody wallet. 2. Select the network you intend to use on Ramses. 3. Acquire the assets you plan to use plus enough of that network's native token for gas. 4. Send a small test transaction before transferring a larger amount. 5. Verify the wallet balance and network before opening Ramses. ## Connect to Ramses Open the [Ramses app](https://www.ramses.xyz/), select the intended network, and connect your wallet. Confirm the site domain, connected account, and network before approving or signing anything. ## Protect Your Funds and Wallets DeFi exposes users to scams ranging from social engineering to malicious contracts, so exercise extreme caution. Self-custody gives you control of your assets and makes you responsible for securing them. - Never share your seed phrase with anyone or enter it into a website or unsolicited prompt. Follow only your wallet vendor's verified recovery procedure. - Verify domains and contract addresses before connecting or signing. - Read wallet prompts and reject unexpected approvals or transactions. - Be vigilant about anything you install or download on a device that can access your wallet. - Consider a hardware wallet and separate accounts for long-term holdings and day-to-day activity. No checklist eliminates risk. Learn how approvals, signatures, recovery phrases, and network selection work before committing significant funds. --- # HyperEVM Big Blocks Use Ramses Big Blocks Auto-Switch for complex HyperEVM transactions and troubleshoot block-mode errors. Source: https://www.ramses.xyz/docs/big-blocks HyperEVM uses fast small blocks for standard transactions and higher-capacity Big Blocks for more complex execution. Ramses can switch block mode automatically when a transaction exceeds the small-block gas limit. ## How Big Blocks Work ![Big Blocks](https://www.ramses.xyz/docs-assets/bigblocks.png) HyperEVM's [dual-block architecture](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/dual-block-architecture) provides two execution modes: | Block Type | Production Rate | Gas Limit | Typical Use | | --- | --- | --- | --- | | **Small Blocks** | Every 1 second | 3 million gas | Standard swaps, transfers, and contract interactions | | **Big Blocks** | Every 1 minute | 30 million gas | Transactions whose estimated gas exceeds the small-block limit | ## Big Blocks Auto-Switch ![Big Blocks Auto-Switch](https://www.ramses.xyz/docs-assets/autoswitch.png) When **Big Blocks Auto-Switch** is enabled in Ramses settings, Ramses uses the transaction's gas estimate to select the appropriate block mode around eligible HyperEVM transactions. | Estimated Transaction Gas | Ramses Handling | | --- | --- | | **3 million or less** | Uses small blocks | | **More than 3 million** | Switches to Big Blocks before execution | Auto-Switch does not fund the required HyperCore or HyperEVM balances and does not remove wallet confirmations. Review every wallet request before signing. ## Requirements To switch block modes through Ramses, the connected address needs: 1. **An active HyperCore account** — The address must already exist on HyperCore. 2. **HYPE on HyperCore** — Ramses currently recommends at least 0.1 HYPE on Core for the `evmUserModify` action used by the switch flow. 3. **HYPE on HyperEVM** — The transaction itself still requires HYPE for gas. ## Fix Big Blocks Errors If the block-mode switch fails: 1. Open [Hyperliquid Portfolio](https://app.hyperliquid.xyz/portfolio). 2. Select **EVM ↔ Core Transfer**. 3. Transfer 0.1 HYPE from EVM to Core if the Core balance is insufficient. 4. Return to Ramses and enable **Big Blocks** or **Big Blocks Auto-Switch**. The 0.1 HYPE amount is Ramses' current operating recommendation, not a Hyperliquid protocol minimum. --- # How to Swap Learn what to review before submitting a token swap on Ramses. Source: https://www.ramses.xyz/docs/swapping Swap tokens through Ramses with a live route and a protected minimum output. --- ## Swap in Four Steps 1. **Connect your wallet** and select the intended network. 2. **Choose the pair** by selecting the token you are paying and the token you want to receive. 3. **Enter an amount** and review the expected output, minimum received, price impact, route, and fees. 4. **Confirm the swap** after completing an input-token approval if the app requests one. ## Before You Confirm - Confirm the connected network and wallet account. - Verify both token contract addresses; symbols and names can be imitated. - Review the input amount, expected output, minimum received, price impact, route, and fees. - Treat an approval as a separate transaction from the swap when the app requests one. - Confirm the final wallet prompt matches the action shown in the app. ## Slippage Slippage tolerance limits how far execution may move from the quoted output before the transaction reverts. A wider tolerance can improve execution reliability, but it can also allow a worse fill. Use the narrowest tolerance appropriate for the pool's liquidity and current market conditions. --- # How to Farm Learn how to provide liquidity across Ramses pool types and earn fees and eligible rewards. Source: https://www.ramses.xyz/docs/farming Learn the core considerations for providing liquidity and earning eligible pool rewards on Ramses. --- ## Farm in Four Steps 1. **Choose a pool type** — Select [Legacy](https://www.ramses.xyz/docs/legacy-liquidity), [Concentrated Liquidity](https://www.ramses.xyz/docs/concentrated-liquidity), or [DLMM](https://www.ramses.xyz/docs/dlmm). 2. **Set the position** — Enter the deposit amounts and, where applicable, choose the active price range. 3. **Create the position** — Review the transaction and complete any gauge-staking step shown by the app. 4. **Manage the position** — Track liquidity, fees, and eligible rewards from the dashboard. ## Before You Provide Liquidity - Confirm the network, pool, token addresses, and position type. - Review the selected price range and how the position changes when price moves outside it. - Displayed APR is an estimate that updates with trading volume, rewards, token prices, and time in range. - Verify whether the pool is eligible for emissions or other incentives. > **Liquidity Risk** > > Providing liquidity changes your asset exposure. Relative price moves can create impermanent loss, leave the position one-sided, or move concentrated liquidity outside its earning range. ## Position Dashboard Use the dashboard to monitor estimated APR, position value, unclaimed rewards, and the current price relative to your selected range. Position controls let you add, remove, or adjust liquidity. --- # How to Vote Learn how to use staked xRAM on HyperEVM to direct RAM emissions and earn eligible voter rewards. Source: https://www.ramses.xyz/docs/voting Manual xRAM voting currently runs on **HyperEVM**. Staked xRAM gives users voting power to direct weekly RAM emissions among active gauges. --- ## How to Vote 1. Connect your wallet to **HyperEVM** and open [Vote](https://www.ramses.xyz/vote). 2. If you do not have voting power, use **Convert RAM to xRAM**, return to **Vote**, and select **Stake xRAM**. 3. Search or filter the active gauges, then assign a percentage of voting power to each selected pool. Total allocation cannot exceed 100%. 4. Review the selected pools, remaining voting power, and estimated rewards in the vote panel. 5. Select **Cast Votes**, verify the pools and weights in the transaction details, and confirm in your wallet. 6. After confirmation, use **My Votes** to verify the recorded allocations. > **Review Before Signing** > > Displayed rewards are estimates. Votes, incentives, token prices, fee splits, and gauge status can change before the epoch closes. Verify the selected pools and weights in the transaction details; confirmation does not lock in the displayed estimate. --- ## Before You Vote - Voting requires xRAM staked in the VoteModule. - Only active gauges are eligible to receive directed emissions. - Under the default gauged-pool configuration, voters receive 100% of that pool's swap fees; a gauge can use a different fee split, so current configuration controls. - Eligible fees and vote incentives become claimable after epoch rollover. They are not sent automatically. - Reward share depends on the pools selected and the user's share of votes for those pools. - Read the [xRAM voting mechanics](https://www.ramses.xyz/docs/xram#voting) before participating. > **Epoch** > > An **epoch** is Ramses' seven-day accounting period. Each epoch begins Thursday at **00:00 UTC**. Recorded votes determine emission distribution for the following epoch. > **Vote Before the Deadline** > > Votes and incentives can change until Thursday at **00:00 UTC**. Submit early enough for the transaction to confirm, then verify the recorded allocation under **My Votes**. --- # For Launchpads Bring your token launches to Ramses. Compare liquidity models, explore creator and platform fee sharing, and plan your launchpad integration. Source: https://www.ramses.xyz/docs/for-launchpads Keep your launch experience, with Ramses liquidity underneath. A compatible fee-distribution integration can share the trading fees earned by your launch liquidity with creators and your platform. ## Your launch experience Add Ramses as a liquidity destination through the route that fits your platform. ### [Direct launches](https://www.ramses.xyz/docs/for-launchpads#connect-your-launch-flow) Create the token's trading pool on Ramses from the start. ### [Curve graduation](https://www.ramses.xyz/docs/for-launchpads#connect-your-launch-flow) Move launch liquidity to Ramses when your bonding curve completes. ### [Token sales](https://www.ramses.xyz/docs/for-launchpads#connect-your-launch-flow) Allocate part of a project's launch budget to its Ramses trading pool. ## Build around your business model | Your model | How it can work | | --- | --- | | **Fee recipients** | Keep your creator and platform economics. Configure a compatible distributor to split collected LP fees between your chosen recipients. | | **Liquidity commitments** | A compatible V3 locker can keep launch liquidity locked while authorized recipients claim earned fees. Confirm the lock terms and collection permissions for your integration. | | **Trading interface** | Connect pool creation, pricing, and swaps to your app so users can keep trading where they launched. | | **A team you can reach** | Discuss integration support, launch promotion, and co-marketing opportunities directly with the Ramses team. | ## Fees In the standard fee-only setup, **95% of swap fees go to LPs** and **5% go to the protocol**. - **Legacy and DLMM:** the LP share stays in pool or bin reserves and increases LP share value. - **Concentrated V3:** the LP share accrues to positions for collection. A compatible locker and distributor can route collected fees to your recipients. These are defaults and can vary by pool. Gauged pools use a different fee and reward model. Confirm the current configuration in the [fee reference](https://tech.ramses.xyz/concepts/protocol/fees) before integrating. ### More fees available to share ### From gross fees to collected LP fees Example · 0.01% fee tier Attributable gross fees: $100,000. | Fee allocation | Ramses (standard fee-only pool) | Uniswap V3 (0.01% tier, protocol fee enabled) | | --- | --- | --- | | LP share of gross fees | 95% | 75% | | Protocol share of gross fees | 5% | 25% | | Collected LP fees | $95,000 | $75,000 | | Protocol fees | $5,000 | $25,000 | Ramses retains $20,000 more in collected LP fees in this example: approximately 27% more than the Uniswap V3 baseline. ### 80/20 fee split 80% to creators, 20% to the platform, after the DEX protocol fee. | Recipient | Ramses | Uniswap V3 | Difference | | --- | --- | --- | --- | | Creator (80%) | $76,000 | $60,000 | +$16,000 | | Platform (20%) | $19,000 | $15,000 | +$4,000 | This example requires a compatible V3 fee-collection and distribution integration. Your launchpad configures the 80/20 split; Ramses does not pay it automatically. Assumptions and pool configuration: - The Uniswap V3 baseline applies only to 0.01% fee-tier pools with protocol fees enabled. When protocol fees are disabled, LPs retain 100% of swap fees and this uplift does not apply. - Uniswap's published rates at the 0.01% tier are 0.0075% for LPs and 0.0025% for the protocol: 75% and 25% of gross fees, respectively. - Both examples assume the same volume, attributable gross fees, LP exposure, and creator/platform split. No incentives are included, and pool fee configurations can vary. - Example amounts are USD equivalents of fees earned in the traded assets. Asset prices and trading activity affect realized amounts. - Additional locker, distributor, and gas costs are excluded. Sources: [Ramses protocol fees](https://tech.ramses.xyz/concepts/protocol/fees); [Uniswap protocol fee rates](https://developers.uniswap.org/docs/protocols/protocol-fee/concepts/fees). ## Choose a pool Ramses is deployed on **Arbitrum, HyperEVM, Polygon, and Robinhood Chain**. Choose the pool model that fits your token and liquidity strategy. | Pool model | How liquidity works | Available on | | --- | --- | --- | | [Legacy V2](https://www.ramses.xyz/docs/legacy-liquidity) | Full-range volatile pools, plus stable pools for correlated assets. | All four chains | | [Concentrated V3](https://www.ramses.xyz/docs/concentrated-liquidity) | Liquidity within a chosen price range. | All four chains | | [DLMM](https://www.ramses.xyz/docs/dlmm) | Liquidity distributed across fixed-price bins. | Robinhood Chain | In fee-only pools, V3 positions and DLMM bins earn swap fees when their liquidity is used by trades. Choose ranges with expected price movement and ongoing management in mind. ## Connect your launch flow 1. **Choose the destination.** Select the chain, token pair, and pool model. Confirm the [current contracts](https://www.ramses.xyz/docs/contract-addresses), fee settings, and pool-creation permissions for that deployment. 2. **Add liquidity at launch or graduation.** Connect your flow to the appropriate Ramses router or position manager. Set the starting price, deposit amounts, and who receives and manages the LP position. 3. **Verify the integration.** Check token compatibility, approvals, liquidity ownership, and slippage protection before going live. The Ramses team can help with integration questions. Your launchpad controls its launch and graduation mechanics. Ramses pool fees and protocol settings follow the applicable deployment configuration. ## Developer resources ### [Contract addresses](https://www.ramses.xyz/docs/contract-addresses) Published deployments by chain. ### [Ramses CL SDK](https://github.com/RamsesExchange/v3-sdk) Tools for V3 integrations. ### [DLMM integration](https://tech.ramses.xyz/contracts/guides/dlmm/integration) Router and bin-based liquidity guidance. ### [Fee reference](https://tech.ramses.xyz/concepts/protocol/fees) Fee settings and allocation mechanics. ## Start with one launch Tell us about your next token launch or graduation, preferred chain, and pool choice. We can compare the fees your creators and platform could retain, then scope an integration around your platform. Pre-launch teams can apply; share contract addresses when available. > **Share your next launch** > > [Get in touch with the Ramses team →](https://kindly-bobcat-66f.notion.site/c0b89cc4eb7b47eebb2723076a1970f9) --- # Sarcophagus (Legacy) Historical reference for Ramses' r33 burial mechanism, replaced as the Robinhood protocol fee recipient by the Buyback Module on October 14, 2026. Source: https://www.ramses.xyz/docs/sarcophagus > **Legacy mechanism** > > The **[Buyback Module](https://www.ramses.xyz/docs/buyback-module)** replaced the Sarcophagus as the Robinhood protocol fee recipient on **October 14, 2026**. Current protocol fees fund RAM buybacks. This page preserves the former r33 burial mechanism and its historical accounting; the replacement does not erase past burials or imply that the old contract has been disabled. ## The Sarcophagus: Fees In. r33 Buried. The Sarcophagus was Ramses' fee-funded r33 burial mechanism on Robinhood Chain. Protocol fee assets accumulated in the contract, and anyone could claim selected assets by supplying the required onchain amount of r33. **Each completed burial sent r33 to the dead address and transferred the selected assets to the caller.** ## The Fee-to-Burn Loop Under the former routing, the protocol share of trading fees accumulated in the Sarcophagus. A caller selected available tokens and paid the live r33 burial cost. The contract sent its balances of the selected tokens to the caller and the r33 to `0x000000000000000000000000000000000000dEaD` in one atomic transaction. ## Why It Matters Completed burials permanently retired r33 and its liquid claim on the underlying backing. Those historical transactions remain relevant to Ramses' tokenomics after the fee-routing change. ## Fee Distribution Before the replacement, fee-only or ungauged pools used the default 95% liquidity-provider / 5% protocol split, with the protocol share routed to the Sarcophagus. Gauged pools defaulted to 100% for xRAM voters, subject to their individual configuration. The current Robinhood protocol fee destination is the [Buyback Module](https://www.ramses.xyz/docs/buyback-module#fee-distribution). Current pool settings control the actual split. ## What a Burial Burns **r33 is liquid-staked xRAM**, and xRAM is backed by RAM. Sending r33 to the dead address permanently removes its liquid claim on that backing. The backing remains locked and remains part of RAM total supply; a burial does not directly burn the underlying RAM tokens or reduce the r33 token's ERC-20 `totalSupply`. The [tokenomics dashboard](https://www.ramses.xyz/tokenomics) retains historical r33 burial accounting separately from RAM retired by the Buyback Module. ## How to Participate The former flow was to select assets, check the current burial cost, approve the required r33, and submit a burial. This is preserved as historical context, not as the current fee-conversion flow. Any interaction with remaining legacy balances depends on the old contract's current state. For the current mechanism, see [Buyback Module execution and controls](https://www.ramses.xyz/docs/buyback-module#execution-and-controls). ## Legacy Contract - [Sarcophagus: 0x712567e71a93Fb111510A790cAf3469677aAba3e](https://robin.etherscan.io/address/0x712567e71a93Fb111510A790cAf3469677aAba3e) - [r33: 0x4e5195469A0360f5dfe811730C9CCaCFF0a0FeeE](https://robin.etherscan.io/address/0x4e5195469A0360f5dfe811730C9CCaCFF0a0FeeE) --- # Glossary Key terms and definitions used throughout Ramses documentation. Source: https://www.ramses.xyz/docs/glossary ## **Terms** ### Asset Digital tokens used in Ramses. These include ERC-20 tokens for trading and ERC-721 NFTs that represent concentrated liquidity positions. ### Automated Market Maker An automated market maker is a smart-contract system that lets users trade against pooled liquidity according to its pricing rules. Eligible liquidity providers may receive the pool's configured fee share, emissions, or [liquidity incentives](https://www.ramses.xyz/docs/hyperram#vote-incentives); these rewards are not available on every pool or position. ### Active Bin The DLMM price bin where swaps currently occur. A swap moves to the next available bin after consuming the liquidity available at the active price. ### Bin A discrete price level in a DLMM pool. Each bin holds its own liquidity and LP shares. Learn more [here](https://www.ramses.xyz/docs/dlmm#how-bins-work). ### Concentrated Liquidity A liquidity provision mechanism where providers can specify custom price ranges for their assets. Learn more [here](https://www.ramses.xyz/docs/concentrated-liquidity). ### Discretized Liquidity Market Maker / "DLMM" An AMM design that organizes liquidity into fixed-price bins. LPs select a range of bins, while swaps move across the available bins as needed. Learn more [here](https://www.ramses.xyz/docs/dlmm). ### Core Essential smart contracts for Ramses' functionality. Contracts that handle critical functions like swaps, liquidity management, and fee collection. View the core contracts [here](https://www.ramses.xyz/docs/contract-addresses). ### ERC20 Fungible token standard. ### Factory The smart contracts responsible for deploying new trading pairs and pools. ### Gauge A smart contract that distributes RAM emissions to eligible liquidity positions based on the pool's vote allocation and each position's qualifying liquidity. ### Invariant The constant `k` in the volatile `x*y = k` and stable `x^3*y + x*y^3 = k` formulas. Learn more [here](https://www.ramses.xyz/docs/legacy-liquidity#pair-types). ### Liquidity Assets in Ramses pools/pairs available for trading. ### Liquidity Provider / "LP" Users who supply assets to a pool. Liquidity providers assume price and smart-contract risk and may earn the pool's configured swap-fee share plus eligible emissions or [liquidity incentives](https://www.ramses.xyz/docs/hyperram#vote-incentives). ### Pair A smart contract created by Ramses' V2 factory that enables ERC20 trading. [Learn more](https://www.ramses.xyz/docs/legacy-liquidity#pairs) ### Periphery Smart contracts that interact with Ramses' core contracts to provide additional functionality. These include routers, position managers, and other utility contracts. View the periphery contracts [here](https://www.ramses.xyz/docs/contract-addresses). ### Pool A smart contract created by Ramses' V3 factory that enables trading between two ERC20 tokens. A token pair can have multiple pools with different configured fee settings; the active fee may adjust dynamically with market conditions. Learn more [here](https://www.ramses.xyz/docs/concentrated-liquidity#ramses-cl). ### Position A liquidity allocation in a pool. Concentrated liquidity positions are represented as NFTs, while DLMM positions consist of fungible shares in one or more bins. Learn about [concentrated liquidity](https://www.ramses.xyz/docs/concentrated-liquidity#ramses-cl) or [DLMM positions](https://www.ramses.xyz/docs/dlmm#providing-liquidity). ### Price Impact The effect a trade has on an asset's price due to the size of the order relative to pool liquidity. Larger trades typically result in higher price impact. ### Range An interval between two ticks of any distance. ### Range Order Limit order approximation using single-asset liquidity provision. Learn more [here](https://www.ramses.xyz/docs/concentrated-liquidity#range-orders). ### r33 / hyperRAM r33 is Ramses' liquid-staked xRAM product, called hyperRAM on HyperEVM. It automates voting and compounds rewards into its xRAM backing. Learn about [r33 liquid staking](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking) and find deployment-specific token addresses in [Contract Addresses](https://www.ramses.xyz/docs/contract-addresses). ### Slippage The difference between a quoted and executed amount. Slippage tolerance sets the maximum acceptable change before a transaction reverts. ### Spot Price The pool's current exchange rate before a trade, derived from its active price state. ### Swap Curve (Uniswap v2 or Correlated) The AMM formula that determines trade prices in pairs. Ramses uses two curves: volatile (`x*y = k`) for standard token pairs, and stable (`x^3*y + x*y^3 = k`) for correlated assets. Learn more [here](https://www.ramses.xyz/docs/legacy-liquidity#pair-types). ### Swap Fees Trading fees charged by a pool. By default, gauged pools direct 100% of swap fees to xRAM voters for that pool; ungauged pools retain 95% for liquidity providers and direct 5% to the protocol. Fee rates may vary [algorithmically](https://www.ramses.xyz/docs/hyperram#dynamic-fees). ### Tick Discrete boundaries in price space. ### Vote Incentive Rewards offered to xRAM holders to incentivize voting on gauges. These incentives help [direct emissions](https://www.ramses.xyz/docs/hyperram#directing-emissions) to desired liquidity pools. --- # Media Kit Brand guidelines, logos, and assets for Ramses. Source: https://www.ramses.xyz/docs/mediakit [Browse the Ramses brand and media assets on Google Drive](https://drive.google.com/drive/folders/1uWSLj5ZuuvWActq45fkJUJXrx9Y5BYDd). [Download media assets](https://www.ramses.xyz/docs-assets/Ramses_Mediakit.zip) ![Ramses Brand Kit](https://www.ramses.xyz/docs-assets/brandkit.png)