# 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 is multichain DeFi infrastructure with concentrated liquidity, automated vaults, and unified tokenomics across chains. Source: https://www.ramses.xyz/docs ## Quick Start Use the links below to get started on **Ramses!** ### [Ramses X](https://www.ramses.xyz/docs/ramses-x) Learn about the planned multichain architecture, future OFT connectivity, and fee-first deployments. ### [Tokenomics](https://www.ramses.xyz/docs/tokenomics) Read about RAM supply, emission schedule, distribution and more. ### [Guides](https://www.ramses.xyz/docs/intro-to-defi) Step-by-step guides to bridging, providing liquidity, and interacting with the protocol. ### [Security](https://www.ramses.xyz/docs/audits) Security measures, audit reports, and contract 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. ### [Ramses X](https://www.ramses.xyz/docs/ramses-x) Planned multichain architecture with canonical RAM on Ethereum and future OFT connectivity via LayerZero. ### [AutoVaults](https://www.ramses.xyz/docs/autovaults) Stake xRAM, select your reward token, and let automated voting handle the rest. ### [The Sarcophagus](https://www.ramses.xyz/docs/sarcophagus) Ungauged pools direct 95% of swap fees to LPs and 5% to the protocol/Sarcophagus; gauged pools direct 100% to voters. ### [xRAM](https://www.ramses.xyz/docs/xram) Escrowed RAM token for directing emissions, earning fees, and voting incentives. ### [Concentrated Liquidity](https://www.ramses.xyz/docs/concentrated-liquidity) Orderbook-style AMM that lets LPs focus capital in custom price ranges. ### [DLMM](https://www.ramses.xyz/docs/dlmm) Discrete price-bin liquidity with flexible ranges, dynamic fees, and auto-compounding LP fees. ### [Competitive Farming](https://www.ramses.xyz/docs/concentrated-liquidity#competitive-farming) Rewards scale based on liquidity efficiency, encouraging optimal range selection and active management. ### [Dynamic Fees](https://www.ramses.xyz/docs/hyperram#dynamic-fees) Algorithm-driven fee adjustment based on market volatility and trading volume. ### [r33 Liquid Staking](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking) Automate voting and reward claims with r33 (hyperRAM on HyperEVM), the liquid-staked version of xRAM whose redemption ratio is designed to increase as rewards compound. ### [MEV](https://www.ramses.xyz/docs/mev) Captures eligible MEV opportunities and retains the resulting value within the protocol under each module's allocation rules. --- # Ramses X Ramses X is the planned multichain architecture for a unified RAM supply, 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** describes the planned next phase: automation, fee-first deployments, and a multichain architecture that coordinates RAM supply while each chain retains its own execution and liquidity. **Less effort. More rewards.** ### [Canonical RAM](https://www.ramses.xyz/docs/ramses-x#ram-token-and-oft-connectivity) Canonical RAM and its LayerZero OFT connection are planned for Ethereum. They are not yet deployed. ### [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. ### [The Sarcophagus](https://www.ramses.xyz/docs/sarcophagus) The planned protocol share from fee-only or ungauged pools can fund permissionless RAM-for-fee claims. ### [AutoVaults](https://www.ramses.xyz/docs/autovaults) Stake xRAM, select a reward token, automate voting and conversion, then claim converted rewards. --- ## Architecture Overview The planned Ramses X architecture has three core components: **canonical RAM supply**, **chain-specific execution and liquidity**, and a **shared fee sink**. --- ## RAM Token & OFT Connectivity Canonical RAM on **Ethereum Mainnet** and its LayerZero OFT connectivity are **work in progress**. No production Ethereum RAM token or OFT adapter address has been published. | Component | Planned Function | | --- | --- | | **Canonical RAM** | Ethereum token intended to be the source of truth for RAM supply | | **OFT Adapter** | Intended to lock canonical RAM on Ethereum and coordinate cross-chain messages through LayerZero | | **RamsesOFT** | Planned chain-specific representation that debits supply on the source chain and credits it on the destination chain | | **Messaging Fees** | Cross-chain transfers require source-chain gas and a quoted LayerZero messaging fee | If deployed as designed, the OFT architecture would: - 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 Under the planned rollout model, a new chain begins with **governance inactive** and fee-only or ungauged liquidity. ### Phase 1: Fee-Only Mode In this initial phase: | Feature | Status | | --- | --- | | LP fee share | 95% of swap fees | | Protocol / Sarcophagus share | 5% of swap fees | | Emissions | Inactive | | Gauges & Voting | Inactive | The 5% protocol share can be routed to the Sarcophagus. RAM supply changes only when a caller completes a RAM-for-fee claim and the chain-specific burn or removal mechanism executes. No emissions are distributed during this phase. ### Phase 2: Governance Activation Once a deployment reaches predefined performance and consistency thresholds, governance can be enabled. 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 | > **Maker Rebates** > > An optional maker rebate of up to 1% is treasury-funded and additive. It is not deducted from the 95% LP / 5% protocol swap-fee split. **The intended sequence is demand first, incentives second.** > **Governance Thresholds** > > Specific parameters including governance activation thresholds will be published alongside each chain deployment. --- ## What This Enables | Outcome | Benefit | | --- | --- | | **Coordinated Supply** | Planned Ethereum canonical RAM and OFT connections maintain shared supply accounting | | **Independent Scaling** | Chains retain independent execution and liquidity while starting fee-only | | **Earned Governance** | Governance can be activated after published requirements are met | | **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 the roadmap for evolving Ramses from a governance-centric DEX into **modular DeFi infrastructure**. --- ## Ramses X Rollout Status | Chain | Ramses X Status | Governance Status | | --- | --- | --- | | **Ethereum** | Canonical RAM and OFT adapter in development; no production address published | Not applicable | | **HyperEVM** | Ramses DEX live; connection to the planned canonical OFT architecture is not deployed | Active | | **Additional Chains** | Announced only when deployment details are published | Deployment-specific | > **Deployment Status** > > This table describes the Ramses X rollout, not every chain where a Ramses DEX deployment exists. New production token, OFT, Sarcophagus, and deployment-specific governance addresses will be published in the contract-addresses documentation when available. --- # 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 (Relays) AutoVaults are built to remove governance friction while preserving optimized outcomes. **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#x33-voting-methodology) The operator submits votes automatically each epoch using the x33 methodology. Users do not vote manually. ### [Low Maintenance](https://www.ramses.xyz/docs/autovaults#benefits) No weekly votes or manual reward conversion. Users still claim their converted rewards. ### [Automated Strategy](https://www.ramses.xyz/docs/autovaults#x33-voting-methodology) An operator-managed strategy allocates votes using available fee, incentive, and liquidity data. --- ## How It Works AutoVaults simplify the xRAM staking experience into three 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. Relax** | The system handles voting, underlying reward collection, and conversion; converted rewards become claimable | The vault submits votes automatically each epoch using the same **x33 methodology** that powers r33, the liquid-staked xRAM product called hyperRAM on HyperEVM. Users do not vote manually, but they do submit a transaction to claim converted rewards. --- ## Reward Tokens AutoVault is currently available on **HyperEVM**. The available output tokens are maintained in the AutoVault contract and displayed in the app's **Reward Token** selector. Because this list can change, the in-app selector is the authoritative source. > **Token Formats** > > AutoVault output tokens are ERC-20 tokens. Native assets appear through their supported wrapped or tokenized representation where applicable. --- ## x33 Voting Methodology AutoVaults use an operator-managed version of the x33 methodology that powers r33: | Feature | Benefit | | --- | --- | | **Strategy Inputs** | Vote allocation can consider pool fees, vote incentives, and liquidity depth | | **Epoch Execution** | Voting happens automatically each epoch | | **Aggregator Routing** | Collected rewards are converted through approved aggregators | | **Reward Conversion** | Converted output tokens are credited as claimable rewards; they are not reinvested into the xRAM deposit | The operator uses these inputs to select votes and conversion routes. Outcomes depend on realized fees, incentives, liquidity, execution, and market conditions; the strategy does not guarantee the highest possible return. --- ## Benefits ### No Manual Voting Traditional xRAM staking requires weekly votes to direct emissions. AutoVaults eliminate this entirely—voting is fully automated. ### No Maintenance - No weekly decisions to make - No manual collection or conversion of underlying voting rewards - Claim converted rewards when you choose - No positions to rebalance ### No Decision Fatigue Users do not need to analyze which pools to vote for. The operator manages the strategy each epoch. ### Automated by Default AutoVaults apply the x33 methodology automatically. Realized results vary and are not guaranteed. --- ## AutoVaults vs Manual Staking vs r33 | Feature | AutoVaults | Manual xRAM | r33 | | --- | --- | --- | --- | | Voting | Automated | Weekly manual | Automated | | Reward Token | Selectable | Mixed tokens | r33 | | Claiming | Manual claim | Manual | Automatic | | Optimization | Operator-managed | User-dependent | Algorithmic | | Effort Required | Low | Weekly | Low | | Liquidity | Withdrawable during unlocked periods | Withdrawable | Liquid (tradeable) | --- ## Getting Started 1. **Acquire xRAM** — Convert RAM to xRAM or earn through emissions 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, withdrawals, output changes, and claims are available only while the AutoVault is unlocked. The vault locks while epoch rewards are processed and during the final hour before an epoch flip. Deposits can also pause during the VoteModule cooldown. Withdrawing before an epoch's reward processing is complete may forfeit that epoch's rewards. The contract does not charge a withdrawal fee, but withdrawals are not available at every moment. --- # The Sarcophagus The Sarcophagus is a permissionless claim mechanism intended for the 5% protocol share from fee-only or ungauged pools. Source: https://www.ramses.xyz/docs/sarcophagus ## The Sarcophagus: Deflationary Module A **5% protocol share** from fee-only or ungauged pools can flow into the Sarcophagus. Callers exchange an exact, owner-configured amount of RAM for selected accumulated fee tokens. **Fee accumulation creates a potential RAM-for-fees claim; it does not guarantee that a claim or burn will occur.** --- ## How It Works | Step | Description | | --- | --- | | **Fee Collection** | The 5% protocol share from configured fee-only or ungauged pools flows to the Sarcophagus | | **Accumulation** | Owner-allowlisted fee tokens accumulate until selected in a claim | | **Claim Mechanism** | Any caller can transfer the exact `exchangeAmountThreshold` of RAM and claim selected allowlisted token balances | | **Chain Handling** | Ethereum burns the received RAM; other chains send it to the configured dead address in the current implementation | Calling the claim function is permissionless, but its threshold, token allowlist, maximum token count, and rescue function are owner-controlled. --- ## Fee Distribution | Pool State | Liquidity Providers | xRAM Voters | Protocol / Sarcophagus | | --- | --- | --- | --- | | **Gauged** | 0% | 100% | 0% | | **Fee-only / Ungauged** | 95% | 0% | 5% | > **Maker Rebates** > > Maker rebates are treasury-funded and additive, up to 1%. They are not deducted from the 95% LP / 5% protocol swap-fee split. --- ## Claim Mechanics Any address can call `bury` when the selected fee-token balances are worth exchanging for the configured RAM threshold. Searchers may monitor this opportunity, but execution and profitability are not guaranteed. | Action | Result | | --- | --- | | Transfer exact RAM threshold | `exchangeAmountThreshold` is set by the owner and must be greater than zero | | Select fee tokens | Claim the full Sarcophagus balance of each selected, owner-allowlisted token, subject to `maxTokenClaim` | | Protect execution | Supply the current nonce and minimum amounts for the selected tokens | > **Permissionless Execution, Managed Parameters** > > Anyone can submit a valid claim. The owner can change the RAM threshold, maximum number of claimed assets, and token allowlist, and can rescue tokens from the contract. --- ## Deflationary Impact The Sarcophagus can remove RAM from circulation when fee balances make a claim economical: - More trading volume = more fees - More fees = larger Sarcophagus balance - A larger balance may create more incentive to exchange the configured RAM threshold - A completed Ethereum claim burns RAM; the current non-Ethereum path sends RAM to a dead address Fee accrual alone does not burn RAM, and reduced supply does not guarantee an increase in token price. --- ## Chain-Specific RAM Handling Sarcophagus behavior depends on the chain where a contract is actually deployed: | Chain | Effect | | --- | --- | | **Ethereum** | Calls the RAM token's burn function, reducing token total supply | | **Non-Ethereum Chains** | Sends RAM to the `0x…dEaD` address in the current implementation, reducing circulating supply but not ERC-20 `totalSupply` | | **Undeployed Chains** | No effect until a Sarcophagus contract and fee route are deployed and published | Any later canonical reconciliation or Ethereum burn is a separate process and should not be inferred from the non-Ethereum transfer alone. --- ## Maker Rebate Program Ramses may fund a **Maker Rebate Program** from treasury resources. This program is separate from the pool's swap-fee split: | Feature | Details | | --- | --- | | **Allocation** | Up to 1%, funded by the treasury and additive to pool fees | | **Recipients** | High-performing liquidity providers | | **Goal** | Reward efficient market making | Eligibility, measurement periods, and payment amounts depend on the published rebate program. A rebate is not guaranteed by the Sarcophagus contract. ### Benefits for Market Makers - Potential additional treasury-funded rebates - No need to participate in governance - Eligibility can be based on published performance criteria - Compatible with automated strategies --- ## Combined Fee Flows The two default swap-fee states and the separate rebate program are: | Mechanism | Flow | | --- | --- | | **Fee-only / Ungauged** | 95% to LPs and 5% to the protocol / Sarcophagus | | **Gauged** | 100% to xRAM voters and 0% to LPs by default | | **Maker Rebates** | Up to 1% treasury-funded and additive; not part of either swap-fee percentage | These flows describe token routing. They do not guarantee returns or token-price appreciation. --- # 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 you may see in token lists, contracts, and integrations. > > This page covers the HyperEVM ecosystem. For liquid staking mechanics, see [r33 (hyperRAM)](https://www.ramses.xyz/docs/xram#hyper-ram); for the core 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 **[hyper-efficient DEX](https://www.ramses.xyz/docs/hyperram#hyper-efficient)**, **[x(3,3)](https://www.ramses.xyz/docs/hyperram#x-3-3)**, and **[HyperEVM native integration](https://www.ramses.xyz/docs/hyperram#hyper-evm-native-integration)**. The vision for Ramses is simple: build the **most efficient exchange possible**, keep captured value within the protocol, and allocate it through participant incentives, compounding, or supply reduction according to each module's rules. With significant portions of the initial supply dedicated to [community allocations and incentives](https://www.ramses.xyz/docs/tokenomics#breakdown), Ramses prioritizes **community-first development** and **sustainable value creation**. --- ## Hyper-efficient **Maximum value capture, minimal leakage.** Ramses combines **dynamic fees** that respond to market conditions with permissioned MEV infrastructure designed to capture eligible opportunities. Captured value remains within the protocol and is allocated under the active module's documented rules. | Feature | Description | | --- | --- | | **LP Protection** | Dynamic fees and MEV prevent value leakage and protect LPs from toxic flow | | **Revenue generation** | AMO and backrun arbitrage, with cross-chain and cross-venue expansion planned | | **Cheap transactions** | Compiler upgrade (solc 0.8 + viaIR) = **~2x gas efficiency** | | **Privileged arbitrage** | Atomic zero-fee swaps through privileged infrastructure | | **Complex strategies** | Complex strategies leveraging oracle and market inefficiencies | | **Cross-venue arbitrage** | Planned integrations across HyperCore, Ethereum, Arbitrum, and DeFi protocols | Planned **HyperCore integration** is intended to support atomic execution between Hyperliquid spot markets and Ramses. The roadmap also includes broader cross-venue arbitrage integrations. Security reviews, contests, and bounties help reduce risk, but they do not eliminate it. See the [security reviews and risk disclosures](https://www.ramses.xyz/docs/audits) before interacting with the protocol. ### HyperEVM Native Integration On HyperEVM, users can select a HYPE-denominated AutoVault that converts its allocated rewards into **HYPE from the market**. Fee allocation depends on gauge state: gauged-pool swap fees go entirely to voters for those pools, while ungauged-pool swap fees are split 95% to liquidity providers and 5% to the protocol/Sarcophagus. Ramses prioritizes **community-first development and sustainable value creation**. The Hyperliquid community allocation represents **30% of the initial supply**: 20% for the initial NFT and PiP allocation and 10% for incentives, including 3% for RXP. See the full [token distribution](https://www.ramses.xyz/docs/tokenomics#breakdown). --- ## x(3,3) ![Trilemma](https://www.ramses.xyz/docs-assets/trilemma3.png) **x(3,3) is a more accessible version of ve(3,3)** that aligns participation with value creation rather than forced lockups. To understand how x(3,3) works, first consider ve(3,3): ### ve(3,3) The Solidly model, introduced by Andre Cronje, brought together two key concepts: #### Vote Escrow (ve) Curve's 2020 innovation introduced **time-weighted voting**. Instead of voting with liquid tokens, users lock tokens in a *VotingEscrow* for a selected period; longer locks grant more governance power. [Voting power — interactive visualization](https://www.ramses.xyz/docs/hyperram#vote-escrow-ve) Illustrative four-year vote escrow: voting weight declines linearly to zero over 1,460 days while the locked token amount remains constant. #### Rebase An anti-dilution mechanic inspired by [OHM (3,3)](https://www.olympusdao.finance/) where locked positions rebase as emissions are distributed, helping veTOKEN holders maintain their ownership share without buying and locking more tokens. [Rebasing example — interactive visualization](https://www.ramses.xyz/docs/hyperram#rebase) Illustrative 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. Modern implementations have proven ve(3,3) can achieve massive scale, but they rely on artificial restrictions: **forced lock-ups** create high friction and **unfair access to rewards**. Users must make upfront commitments to participate equitably, creating a system driven by obligation rather than ongoing value. --- ### ve(3,3) → x(3,3) ![ve(3,3)](https://www.ramses.xyz/docs-assets/ve33x33.png) **ve(3,3) has a fundamental design flaw:** it relies on **static commitment** rather than **dynamic value creation**. Even the most successful ve(3,3) exchanges still require users to make upfront commitments to earn meaningful rewards, creating a system where participation is driven by obligation rather than ongoing value. **x(3,3) flips this entirely**—it rewards users based on their active contribution to protocol success, with [exit flexibility](https://www.ramses.xyz/docs/xram#how-to-exit-x-ram) that ensures only those who genuinely value the protocol remain engaged. This creates a **self-selecting community** of active participants rather than passive token holders who do not participate. **Without an exit measure**, the system accumulates dead voting power, as users hold veTOKENs indefinitely without active participation, still influencing the protocol without contributing to its success. --- ### Burns This shift from static to dynamic participation requires a fundamentally different approach to dilution protection. Instead of minting new tokens to locked positions, **x(3,3) introduces a burn mechanism**—a deflationary system that protects remaining holders while enabling flexible participation (**50% burn when RAM → xRAM, exit anytime**). This creates a **self-reinforcing cycle**: as users convert **RAM into xRAM**, 50% of each converted RAM amount is burned. Remaining holders benefit from the resulting supply reduction, while users retain the flexibility to exit xRAM. 1. Deflation scales with the protocol **(user activity)**- Strong incentive to stay instead of lock-ups 2. Removes the need for locks or wrappers- **xRAM** solves the need for token lock-ups - **hyperRAM** (Liquid staked xRAM) solves the need for liquid wrappers --- #### Burn vs Rebase In a model where conversions happen often, **burning is more efficient than rebasing:** | Feature | Burn Model (xRAM) | Rebase Model (Traditional ve(3,3)) | | --- | --- | --- | | **Supply Impact** | Permanently removes tokens from circulation | Maintains total supply, redistributes ownership | | **Deflationary Pressure** | Continuous deflationary pressure from RAM → xRAM conversions | No deflationary pressure, inflationary emissions | | **Dilution Approach** | Conversion burns reduce supply; market value is not guaranteed | Rebases offset holder dilution while emissions increase supply | | **Exit Economics** | Each RAM → xRAM conversion contributes to deflationary economics | Exits don't affect overall supply dynamics | | **Innovation** | **First deflationary ve(3,3) protocol** | Traditional inflationary model | --- ## Trilemma The history of decentralized finance has been marked by repeated attempts to solve the **"DEX Trilemma"**—the challenge of aligning incentives between **traders**, **liquidity providers**, and **token holders**. While the ve(3,3) model sought to balance incentives between participants, long lockups created a **high-friction system** that required users to lock tokens to participate fully in the incentive model. ![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).* Uniswap focused on a simple **two-party system**: traders and liquidity providers (LPs). ve(3,3) improved this by properly aligning incentives with token holders as well, but access to those incentives was **unfair and heavily skewed towards protocols.** | Uniswap | ve(3,3) | x(3,3) | | --- | --- | --- | | - LPs earn the pool's configured share of swap fees - Susceptible to **vampire attacks** - **ZERO** token alignment | - **Forced lock-ups** to participate - **Unfair access** to rewards - **No exit** mechanism | - Can **exit anytime** - **MEV revenue** flows to holders - **hyperRAM** LST - **Strong incentives** instead of locks | --- ## x(3,3) model ![x(3,3)](https://www.ramses.xyz/docs-assets/ramsesflywheel.png) **xRAM is where x(3,3) shines** by creating an **incentive system** that responds to real user behavior. While ve(3,3) exchanges create value through artificial scarcity and forced commitments, x(3,3) instead generates value through **genuine user activity** and **captured value**. When xRAM is minted, the burned tokens protect remaining holders from dilution. This creates a **dynamic system** where ownership naturally concentrates among those who contribute most value. | Traders | Liquidity Providers | xRAM Holders | | --- | --- | --- | | 1. Benefit from Ramses' deep liquidity and **best price execution** 2. Access to the most competitive fees on the network **([dynamic fees](#dynamic-fees), [custom fee-splits](#fee-split))** 3. Protected from toxic flow by **[MEV infrastructure](https://www.ramses.xyz/docs/mev)** | 1. Earn token emissions based on liquidity productivity 2. [Competitive farming](https://www.ramses.xyz/docs/concentrated-liquidity#competitive-farming) + [dynamic fees](#dynamic-fees) = network-leading productive liquidity 3. Protected from adverse selection by MEV capture and dynamic fees | 1. Receive **100% of swap fees from gauged pools they vote for, plus vote incentives** 2. Earn **MEV revenue** 3. Benefit from deflationary [burns](#burns) 4. Auto-compounding via **[hyperRAM](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking)** liquid staking | --- ### Exit Options Ramses separates the conversion burn from exit flexibility. When xRAM is minted, **50% of the RAM being converted is burned**, permanently reducing circulating supply. Exiting does not burn additional RAM. Users can exit their position anytime to realize the remaining 50% backing: 1. **No lock-ups required** - Exit anytime 2. **Deflationary protection** - Burns reduce supply for remaining holders 3. **Liquid alternative** - [hyperRAM](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking) provides instant liquidity through open market trading The combination of **xRAM (direct participation)** and **hyperRAM (liquid staking)** removes the need for complex ve-token wrappers while maintaining strong alignment incentives. **The result?** A more fluid and accessible system that provides strong incentives while removing the friction of ve-token models **(token lock-ups)**. --- ### Directing Emissions As discussed in [DEX Trilemma](#trilemma), prior to ve(3,3) users had no choice but to suffer from misaligned incentives from centralized parties. This led to inefficient capital allocation and reduced long-term sustainability for exchanges. x(3,3) solved this by putting **emission control directly in the hands of xRAM stakers who are incentivized to optimize for value.** Directing emissions is an extremely powerful use case for xRAM stakers as it gives holders primary power over what the platform incentivizes. Combined with swap-fee rewards and MEV modules that retain value within the protocol, this creates a feedback loop where voters are incentivized to direct emissions to the most productive liquidity: those pools that generate the most fees, trading volume, and arbitrage opportunities. Less rewards from the pool **=** less emissions **=** less liquidity. Each week, during a protocol epoch, xRAM stakers choose which liquidity pools receive RAM emissions. Voting closes every `Thursday at 00:00 UTC`, and emissions are allocated according to the result. Read more about [voting and emission distribution](https://www.ramses.xyz/docs/xram#voting). Voters earn **swap fees and vote incentives** in a lump sum immediately after epoch flip. These rewards are based on the liquidity you voted for in the previous epoch. If you vote for a liquidity pool in Epoch X, you will receive your accumulated rewards instantly when Epoch Y begins, proportional to your vote compared to the total votes. --- ### Vote Incentives On Ramses we utilize two different types of vote incentives: **liquidity pool incentives** & **voter incentives**. A vote incentive can be in the form of ANY whitelisted token. As a protocol, incentivizing your liquidity will attract voters and result in higher directed emissions. As an xRAM staker, you earn a portion of the incentives. A **voter incentive** can be designated at any time during the current epoch and is paid in a lump sum to xRAM voters. Once added, it remains visible and can influence votes until the epoch rolls over. A **liquidity incentive** is another method protocols can use to attract liquidity provision. This incentive is distributed directly to liquidity providers and is a great way to bootstrap new liquidity on the platform. | **Voter Incentives** | **Liquidity Incentives** | | --- | --- | | Paid as lump sum at epoch start | Distributed over 7 days after epoch | | Designated during current epoch | Used to boost pool visibility **(direct yield)** | | Influences votes until epoch rollover | Helps bootstrap new tokens | | **Distribution** | | To voters at epoch flip | To LPs for full week after epoch | > **Be in the know!** > > A vote incentive can be in the form of any whitelisted token, and must be applied to only active gauges. Be sure to read & understand [voting](https://www.ramses.xyz/docs/voting) before participating. --- ## Fees Ramses' x(3,3) model takes a straightforward approach to fee distribution: - **100% to xRAM voters on gauged pools** - Gauged-pool swap fees flow to the voters for those pools - **95% to LPs and 5% to the protocol/Sarcophagus on ungauged pools** - Ungauged-pool swap fees retain the default LP and protocol split - **MEV value** - Captured value from [privileged infrastructure](https://www.ramses.xyz/docs/mev) follows module-specific rules, including RAM burns and hyperRAM compounding This creates a **powerful flywheel** where: 1. High-performing pairs generate more fees and MEV opportunities 2. xRAM stakers are incentivized to vote for productive liquidity 3. Increased emissions attract deeper liquidity 4. Deeper liquidity drives more volume, fees, and arbitrage opportunities > **Speaking of swap fees!** > > Fees are adjusted algorithmically based on market volatility and trading volume, working alongside the MEV infrastructure to improve LP protection and xRAM holder returns. ### Fee-Split Fee splits can be configured per gauge. The default pool swap-fee states are: | Gauged Pool | Ungauged Pool | | --- | --- | | **100%** to xRAM voters | **0%** to xRAM voters | | **0%** to Liquidity Providers | **95%** to Liquidity Providers | | **0%** to Protocol / Sarcophagus | **5%** to Protocol / Sarcophagus | > **Customizable Fee Splits** > > Each gauge can be configured with custom fee splits tailored to specific pool characteristics. This allows for optimized fee distribution based on pool type, volatility, and strategic importance to the protocol. --- ### Dynamic Fees ![Dynamic Fees](https://www.ramses.xyz/docs-assets/dynamicfees.png) Ramses' algorithm adjusts fees based on market conditions and trading volume. The goal is to reduce adverse selection during volatile periods while keeping fees competitive in stable markets. **Below is a visual of Ramses' dynamic fees versus other exchanges:** ![Fee Comparison](https://www.ramses.xyz/docs-assets/fee-comparison.png) While dynamic fee mechanisms are not entirely novel, Ramses' algorithm uses market data to adjust fees. The roadmap includes deeper integration across HyperEVM, [HyperCore](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/hypercore-less-than-greater-than-hyperevm-transfers), and other venues. Learn more about the current and planned [MEV protection](https://www.ramses.xyz/docs/mev) mechanisms. #### Real-Time Market Protection The algorithm is designed to adapt its parameters on **sub-minute time scales**. Faster adjustments can increase fees during volatile periods, but they do not eliminate inventory loss, adverse selection, or other liquidity-provider risks. ![Algo in Volatile Time](https://www.ramses.xyz/docs-assets/algoinvolatile.png) **During volatile periods**, the central objective is to shield LPs from excessive toxic flow while simultaneously capturing the highest possible trading fees. The algorithm continuously monitors: - Relative liquidity distributions across venues - Price deviations and typical trade sizes - Real-time on-chain and market data - Cross-venue volume patterns ![Algo in Stable Markets](https://www.ramses.xyz/docs-assets/algoinstable.png) **During stable markets**, the focus shifts toward maintaining a smooth trading experience and optimizing fee collection from non-toxic order flow. Since we continuously compete with other DEXs for volume, maintaining an optimal balance between fee level, liquidity depth, and spot price is crucial. | Fee Range | Market Conditions | | --- | --- | | Base: **0.05%** Cap: **1.00%** | Normal market conditions, Stable trading pairs, High liquidity pools | | Base: **0.30%** Cap: **2.00%** | Less liquid pairs, Higher volatility, Complex trading pairs | | Up to **5.00%** | Extreme market conditions, Flash crash protection, MEV resistance | Our team continuously monitors and optimizes the algorithm, implementing specialized algorithms for different pool categories including volatiles, stables, LST (Liquid Staking Tokens), and meme pools, with novel approaches that account for trading patterns, redemption mechanics, liquidity cycles, and cross-protocol dynamics. --- ## Big Blocks ![Big Blocks](https://www.ramses.xyz/docs-assets/bigblocks.png) HyperEVM uses a [dual-block architecture](https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/hyperevm/dual-block-architecture) that balances transaction speed and capacity. This design allows for both rapid confirmations and the handling of larger, more complex transactions. | Block Type | Production Rate | Gas Limit | Use Case | | --- | --- | --- | --- | | **Small Blocks** | Every 1 second | 2 million gas | Quick, lightweight transactions | | **Big Blocks** | Every 1 minute | 30 million gas | Complex operations & large contracts | **Small blocks** are ideal for simple swaps, standard token transfers, and quick transactions that require fast confirmations. **Big blocks** accommodate complex operations like deploying large smart contracts, adding liquidity to concentrated liquidity positions, and transactions that exceed the small block gas limit. --- ### Big-Blocks Auto-Switch ![AutoSwitch](https://www.ramses.xyz/docs-assets/autoswitch.png) Ramses automatically toggles between small and big blocks based on transaction complexity, eliminating the need for manual configuration. | Block Type | Transaction Examples | | --- | --- | | **Small Blocks** | Simple swaps, standard transfers, quick transactions | | **Big Blocks** | Adding CL liquidity, complex interactions, large deployments, transactions >2M gas | The system analyzes transaction size and complexity in real time, switching between block types in the background. When a transaction requires big blocks, the system automatically: 1. Disables small blocks 2. Executes the transaction on big blocks 3. Re-enables small blocks after completion **No more manual toggling**—just sign your transactions. Enable "Big Blocks Auto-Switch" in your Ramses settings to activate this feature. --- ### Fix Big Blocks Errors To utilize big blocks, you need: 1. **A HyperCore user account** - Created by having a spot balance on HyperCore 2. **HYPE on HyperCore** - HYPE tokens on Core to pay for the `evmUserModify` action that enables big blocks The `evmUserModify` action that sets `usingBigBlocks: true` runs on HyperCore, which is why HYPE on the Core account is required. For actual big block transactions on HyperEVM, you'll also need HYPE on EVM for gas fees. **If you're encountering errors with big blocks, follow these steps:** 1. Navigate to [Hyperliquid Portfolio](https://app.hyperliquid.xyz/portfolio) 2. Click "EVM <-> Core Transfer" 3. Transfer 0.1 HYPE from EVM → Core (needed for the `evmUserModify` action) 4. Enable Big Blocks or Big Blocks Auto-Switching in the UI. > **Pro Tip** > > With Ramses' Big Blocks Auto-Switching enabled, you don't need to manually toggle `usingBigBlocks`. The system handles this automatically based on transaction complexity. --- # xRAM Stake xRAM to direct emissions and earn fees, 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 a token developed by the Ramses team to address the sustainability challenge associated with earlier ve(3,3) models. xRAM combines the best of vote-escrow models with the flexibility of traditional escrow incentive systems. **No more lengthy lock-ups to participate fairly.** ### [Incentives](https://www.ramses.xyz/docs/xram#voting) Vote to direct rewards and earn 100% of swap fees from gauged pools you vote for, plus vote incentives. ### [Instant Exit](https://www.ramses.xyz/docs/xram#how-to-exit-x-ram) Exit anytime with immediate liquidity when needed. ### [AutoVaults](https://www.ramses.xyz/docs/xram#auto-vaults-relays) Delegate voting automatically, receive rewards in a supported output token, and claim them when ready. ### [Vote Incentives](https://www.ramses.xyz/docs/xram#voting) Earn a % of the voting incentives for pairs you vote on, claimable immediately after epoch flip. ### [r33 Liquid Staking](https://www.ramses.xyz/docs/xram#x-ram-liquid-staking) Automate voting and compound 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 RAM is burned when xRAM is minted; deflationary dilution protection (not distributed). --- ### What can I do with xRAM? xRAM stakers can vote to direct emissions to their favorite LP pairs and earn **100% of swap fees from gauged pools they vote for, plus vote incentives.** Stake to earn HYPE from buybacks, or mint **r33 (hyperRAM on HyperEVM)**, the liquid staked version of xRAM, to auto-compound rewards. - **Voting & incentives:** Vote to direct emissions and earn 100% of protocol fees and vote incentives. - **Earn HYPE:** Earn HYPE from buybacks funded by fees and vote incentives. - **Mint r33 (LST):** Mint r33 (hyperRAM on HyperEVM), the liquid-staked xRAM that auto-compounds rewards via fees and incentives. --- ![xRAM](https://www.ramses.xyz/docs-assets/ramsesflywheel.png) --- ## **Token** xRAM is a non-transferable token minted 1:1 from RAM input. For every RAM amount converted, **50% is burned** and the remaining 50% stays in the xRAM smart contract to fund direct redemption at a 1:0.5 ratio. Only holders of xRAM have voting rights on Ramses. While xRAM itself is **non-transferable**, it offers users the ability to exit their position when needed. --- ### How is xRAM obtained? Users can acquire xRAM through vote incentives, token emissions, or by converting RAM. ![Conversion](https://www.ramses.xyz/docs-assets/convert.png) ### **RAM > xRAM conversion** RAM can be freely converted into xRAM at any time. **The process is instant: 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 their xRAM position in two ways: 1. **Direct redemption**: Convert xRAM back to RAM instantly for the underlying (1:0.5 ratio) 2. **Liquidity exit**: Use r33 (hyperRAM on HyperEVM), the liquid staked version of xRAM, to trade your position on the open market > **Burn on Mint** > > The 50% burn occurs when xRAM is minted, not when exiting. --- ## AutoVaults (Relays) ![Hype Buybacks](https://www.ramses.xyz/docs-assets/hypebuyback.png) Users can choose to **stake xRAM in AutoVaults** to receive rewards in a supported output token without voting manually or minting r33. The available output tokens are maintained on-chain and shown in the application. After each epoch flip, the AutoVault operator collects the allocated fees and vote incentives, converts them to each user's selected output token, and credits claimable rewards. **Users claim those rewards manually.** > **Stake and Chill** > > AutoVaults use the same x33 voting methodology as r33. The operator submits votes automatically each epoch, so users do not vote manually. [Learn more about AutoVaults →](https://www.ramses.xyz/docs/autovaults) | Source | Conversion | Distribution | | --- | --- | --- | | Fees & Vote incentives | Converted to the selected output token after epoch flip | Credited to stakers pro-rata for manual claiming | Stakers accrue their selected output token pro-rata based on stake; unstaked xRAM does not earn AutoVault rewards. Accrued rewards become claimable after processing and must be claimed by the user. --- ## 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.** r33 is the name used throughout these docs, with hyperRAM retained where it identifies the HyperEVM token or existing integrations. ![Mint r33 (hyperRAM on HyperEVM)](https://www.ramses.xyz/docs-assets/xRAMconvert.png) Ramses was designed to eliminate friction from the ve(3,3) model, and managing voting positions is one of the biggest sources of this friction. The liquid staked version of xRAM simplifies this process by **automating voting and compounding rewards** without disrupting xRAM's core mechanics. > **Minting Lock** > > Before each epoch flip, there is a **1-hour period** where liquid staking tokens cannot be minted so votes can be calculated. ### r33 (hyperRAM) ![r33, known as hyperRAM on HyperEVM](https://www.ramses.xyz/docs-assets/hyperRAM.png) **r33** can be minted with xRAM. The **r33:xRAM ratio** (also called the **hyperRAM:xRAM ratio** on HyperEVM) starts at 1.00:1.00 and increases in **r33's** favor as rewards accrue from fees and vote incentives. | Feature | Benefit | | --- | --- | | **Automated Voting** | Strategy-based automated voting | | **RAM Buybacks** | Converts rewards through integrated aggregators | | **Auto-compounding** | All vote incentives and fees increase the **r33:xRAM ratio** | | **No Protocol Fees** | No protocol fee for deposits, withdrawals, or compounding; network gas still applies | | **Tradable Token** | Can trade on available open markets, subject to market liquidity | | **Redemption Reference** | Redemption value can create arbitrage opportunities when redemption is available | | **Redemption ratio (`ratio()` on the hyperRAM contract)** | Designed to increase as compounded rewards accrue | After every weekly epoch flip, rewards from fees and vote incentives are automatically sold to increase the **r33:xRAM ratio**. The example below illustrates how the ratio may increase as rewards accrue. [r33:xRAM redemption ratio — interactive visualization](https://www.ramses.xyz/docs/xram#hyper-ram) Illustrative 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. #### Does not bypass exit fee While **r33** can trade on available markets, it does not circumvent xRAM's exit penalty. When redemption is available, a discount to redemption value may create an arbitrage opportunity. Market price can still deviate because of liquidity, execution costs, cooldowns, and protocol risk. > **Post-Epoch Cooldown** > > After each epoch flip while rewards are being sold and compounded, there is a **12-hour cooldown period** during which new r33 cannot be minted from xRAM. **Withdrawals are not affected**, so users can still withdraw their xRAM during this period. --- ## Conversion Burn Ramses incorporates a **burn mechanism** that provides dilution protection for xRAM holders and permanently reduces circulating supply when xRAM is minted. This mechanism is **deflationary** and does not distribute burned tokens to users. Burns occur during the conversion process, protecting remaining holders through lower circulating supply over time. ### Why? As discussed in the [ve(3,3)](https://www.ramses.xyz/docs/hyperram#ve-3-3) section, ve(3,3) introduced important improvements to user alignment but still had fundamental limitations. xRAM builds on these improvements while addressing the core issues, moving the power balance back towards users. Instead: - Stakers who remain in xRAM longer earn more fees and vote incentives.- Users can exit their position at any time, ensuring rewards flow to those who value it the most. The conversion penalty creates a system where 50% of every RAM amount converted to xRAM is permanently burned and active stakers benefit from reduced supply. Positions of any size can exit, unlike wrappers whose exits depend on market liquidity or large veNFTs that may be difficult to sell. Each RAM → xRAM conversion reduces the remaining RAM supply. --- ## Voting xRAM holders are rewarded for actively participating and voting. For gauged pools, **100% of swap fees go to voters**, distributed in proportion to their votes for that liquidity, along with any additional vote incentives offered by protocols to attract emissions. Ungauged pools instead direct 95% of swap fees to liquidity providers and 5% to the protocol/Sarcophagus. | **Swap Fees** | **Vote Incentives** | | --- | --- | | **100%** of swap fees from gauged liquidity you vote for | Additional rewards offered by protocols to attract votes to their pairs | > **Claiming Rewards** > > - Both fees and vote incentives are claimable immediately after the epoch flip. > - Vote incentives can be in any whitelisted token, [learn more](https://www.ramses.xyz/docs/voting). --- ### Voting Breakdown The main purpose of the xRAM token is to vote to direct emissions to liquidity. This is achieved through weekly voting for gauged liquidity. Emissions are distributed proportionally to each pool's share of votes in the epoch. ### Emission Calculation The expected emissions can be calculated by multiplying total epoch emissions by the pair's share of all votes: - **Pair emissions = total epoch emissions × (pair votes / total votes)** For example, **100,000 RAM** is distributed in a single epoch. If **10%** of all votes are allocated to the **RAM / USDC** pair, that pair will receive **10,000 RAM** tokens distributed linearly to liquidity providers of the relevant LP pair throughout the epoch. ### Vote Weight Calculation Voting power is based on the user's xRAM voting balance in the VoteModule. Users allocate that voting power proportionally across their selected pools: **Pool vote weight = xRAM voting balance × (submitted pool weight / sum of submitted weights)** > **Weekly Epochs** > > - Epochs reset every Thursday at **00:00 UTC** > - Votes determine emission distribution for the following week > - Emissions are distributed linearly throughout the epoch --- # 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 On Ramses, users can swap tokens for other tokens. Each trade's exchange rate and slippage is determined by the total value of the liquidity pair and the current pair balance, whose price arbitrage bots help maintain. ### Pair Types **Ramses features two types of Liquidity Pairs, each with its own swap curve:** - **Volatile (Uniswap v2)**: This is the most common pair type, where tokens are paired with equal weights in terms of dollar value. - Volatile swap formula: `x * y = k`. - **Stable (Correlated)**: These pairs use an optimized curve designed specifically for correlated assets like stablecoins. The curve features a modified invariant that allows for highly efficient swaps with minimal slippage between tokens of similar value. - 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 around the mean. [Interactive swap-curve graph](https://www.desmos.com/calculator/1brdmaxdgx?embed) **Solid** = Correlated Curve, **Dotted** = Volatile Swap Curve ### Fee Structure > **Speaking of swap fees!** > > Fees are adjustable if required, and typically range from: > > - Volatile **(0.2-2%)** > - Correlated **(0.001%-0.03%)** > - Native **(1%-3%)**. > > The theoretical **MIN** and **MAX** for legacy fees is **(0.01<= Fee <= 5000bps)**. This means the minimum fee is **0.0001%**, and the highest is **50.00%**. --- ## Pairs In the x(3,3) model, liquidity providers stake their LP tokens in a gauge to earn emissions from Ramses. Ramses encourages liquidity provision with incentives. The more votes allocated to a liquidity pair by xRAM voters, the more RAM that will be emitted to the gauge in the following epoch. ### Rewards & Incentives Legacy pairs can be staked to earn emissions and [liquidity incentives](https://www.ramses.xyz/docs/hyperram#vote-incentives). Once you have the LP tokens, you can deposit them within their corresponding gauge (if the pair is whitelisted) and start earning rewards in real time. By default, gauged-pair swap fees go 100% to xRAM voters. If the pair does not have a gauge, 95% of swap fees remain in the pair and increase LP-token value, while 5% goes to the protocol/Sarcophagus. --- # 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 is an **order-book-style AMM designed for capital-efficient liquidity provision.** By allowing LPs to concentrate capital within specific price ranges, Ramses creates liquidity zones that resemble traditional order book depth while retaining automated market-making behavior. 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. Liquidity spread from `0 to ∞` is exponentially less efficient than, say, one with a defined range of **$3400-$3500**. By focusing liquidity in a narrower range, concentrated liquidity pools can improve slippage, as more liquidity is available to support trades at desired prices, **reducing the price impact of transactions.** ![Position Overview](https://www.ramses.xyz/docs-assets/positionoverview.png) The **cyan line** represents the **7 day historical price range** of the pool. This historical context helps liquidity providers visualize price volatility before selecting their position ranges. The **shaded area on the left** represents the liquidity depth summed between all ticks within the liquidity pool (within the same fee-tier, more on this [here](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. Traditional **"set it and forget it"** strategy. | Allocates approximately **$48,927** within the **$45-$55** price range. Keeps approximately **$951,073** 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, a $50 spot price, and ignores fees and rounding. Equal liquidity depth does not guarantee equal or higher returns. Realized fees and rewards depend on trading volume, fee configuration, competing active liquidity, in-range time, gauge eligibility, and incentives. Concentrated liquidity can provide more depth per dollar while a position is active. It also concentrates inventory and price risk: an out-of-range position stops supporting trades and is held entirely in one asset. --- ## 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? Concentrating a position can provide more active liquidity per dollar, but only while the market remains inside the selected range. A position's rewards depend on its active liquidity share, in-range time, gauge eligibility, votes, and any additional incentives. Productive liquidity can improve execution and 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? Concentrated liquidity can provide substantially more depth per dollar than full-range liquidity, but the improvement depends on range width, current price, and competing active liquidity. Tighter ranges increase capital efficiency while active, but also increase the chance of going out of range and can increase inventory, adverse-selection, and rebalancing risk. No range guarantees higher earnings. Users should weigh expected fees and incentives against price risk, inactive time, and management costs. --- ## 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 it is active, it may earn fees or gauge rewards depending on the pool's fee configuration and whether the position is eligible and staked. Earnings are not guaranteed. ### 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. #### Impossible Range Order Types | **Buy Stop Orders** | **Stop-Loss Orders** | | --- | --- | | Cannot place **USD₮0** orders above current price | Cannot place **HYPE** orders below current price | > **Pro Tip** > > When setting range orders, consider the execution interval carefully. A wider range may remain active longer and execute across more prices, but provides less concentrated liquidity per dollar. Any completed conversion can reverse while the position remains deployed. --- ## Fee Tiers There are multiple default fee tiers when creating a Concentrated Liquidity position on Ramses: | 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 | ### Distribution By default, swap fees are distributed according to the pool's gauge state: | Pool State | Liquidity Providers | xRAM Voters | Protocol / Sarcophagus | | --- | --- | --- | --- | | **Gauged** | 0% | 100% | 0% | | **Fee-only / Ungauged** | 95% | 0% | 5% | > **Important** > > These percentages can be configured per pool to better align with specific market conditions and liquidity requirements. --- # 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** > > As of July 29, 2026, Ramses DLMM is deployed on Robinhood Chain in fee-only mode. Deployment status and configuration can change; see the [live technical deployment reference](https://tech.ramses.xyz/contracts/reference/dlmm/deployments) for the latest documented snapshot. ## 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 share holder or an approved operator can burn those shares; protocol configuration controls do not provide a general withdrawal path for user principal. ## 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. The variable component does not read prices or volatility from a centralized exchange. The combined swap fee is capped by the contracts, and current parameters should be checked in the app or on-chain before trading. | Pool state | LP share of swap fees | Voter/protocol share | Emissions | | --- | --- | --- | --- | | Fee-only (ungauged) | 95% | 5% to the protocol/Sarcophagus | None | | Gauged | 0% | 100% to voters | Eligible | The current Robinhood Chain deployment is fee-only. It does not currently have live gauge reward hooks, so LP returns come from the LP share of swap fees rather than emissions. ## Risks DLMM liquidity carries many of the same risks as other concentrated liquidity: - **Inventory risk:** swaps can leave a position holding mostly or entirely one token. - **Out-of-range risk:** bins away from trading activity do not earn fees. - **Impermanent loss:** relative token price changes can make LP returns lower than simply holding the assets. - **Price impact and slippage:** thin or widely separated liquidity can produce worse execution. - **Dynamic fees:** the fee paid by a trader can change with on-chain activity. - **Smart contract and configuration risk:** contracts, integrations, and administrative settings can contain defects or change over time. Only provide liquidity to assets and ranges whose risks you understand. ## 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) --- # Tokenomics & Emissions Initial distribution, supply schedule and elastic emissions for RAM token Source: https://www.ramses.xyz/docs/tokenomics --- ## 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 Below is an illustrative projection of the baseline weekly emission schedule (before elastic emissions) and supply for the first 500 Epochs (~10 years). The burn scenario assumes all emitted RAM is converted to xRAM and, as with every RAM → xRAM conversion, 50% of the converted RAM is burned. Actual burns depend on how much RAM is converted. ### Emissions vs. Supply [RAM supply and emissions — interactive visualization](https://www.ramses.xyz/docs/tokenomics#emissions-vs-supply) Illustrative emission schedule. Gross supply approaches 883.75M RAM. Net supply approaches 616.875M only if all emitted RAM is converted to xRAM and 50% of each conversion is burned. Actual burns depend on conversions. Left axis: supply and burns; right axis: weekly emissions. - Initial supply: 350M tokens - The **Gross supply** dashed line shows initial supply plus emissions before burns - Filled supply area shows net supply after subtracting burns under the illustrated conversion assumption - The **Assumed cumulative burns** line shows cumulative burns under that same assumption > **Emission Schedule** > > - Epoch 0: 7M weekly emissions > - Epoch 1: 12.5% decrease > - Epoch 2: 15% decrease > - Epoch 3+: 1% decay per epoch in perpetuity without intervention ### Elastic Emissions **Emissions can be modified by up to ±25% per epoch** depending on protocol revenue to maintain sustainable inflation. 100% of ALL emissions go to gauges—**there are no team allocations or other distributions, ensuring fully decentralized emissions.** Emissions may be increased when **revenue is greater than or equal to emissions** for several consecutive epochs, or when near-term catalysts are expected to increase revenue. Emissions may be decreased when **revenue remains substantially below emissions** for several consecutive epochs, or when revenue is expected to decline. *Note: These are approximate projections and actual emission numbers may vary. This model demonstrates our commitment to sustainable, long-term supply growth.* --- ## Multichain Token Architecture Ramses plans for RAM to exist canonically on **Ethereum Mainnet** and extend to other chains using an **OFT (Omnichain Fungible Token)** model powered by LayerZero. This architecture is a work in progress and is not yet deployed. ### Canonical RAM | Property | Details | | --- | --- | | **Native Chain** | Planned for Ethereum Mainnet | | **Bridge Technology** | Planned LayerZero OFT | | **Cross-chain Transfers** | Planned transfers via an OFT adapter | | **Supply Management** | Intended single canonical supply | Once deployed, this architecture is intended to keep RAM as a **single canonical asset** with shared supply accounting across deployments. Trading liquidity will remain local to each chain. ### How OFT Works The planned architecture will use the following components: | Component | Function | | --- | --- | | **Canonical RAM** | Planned native token on Ethereum and source of truth for total supply | | **OFT Adapter** | Will coordinate cross-chain transfers via LayerZero | | **Lockbox** | Will hold canonical RAM on Ethereum when RAM moves to a remote chain | | **RamsesOFT** | Planned chain-specific RAM representation backed by canonical RAM | > **Unified Supply** > > Once deployed, canonical-to-remote transfers will lock RAM and mint the remote representation; remote transfers will burn the source representation before minting or unlocking the destination asset. These operations are intended to preserve one shared total supply. [Learn more about Ramses X multichain architecture →](https://www.ramses.xyz/docs/ramses-x) --- # MEV How Ramses captures MEV and protects liquidity emissions with an onchain anti-Sybil timer that slashes rewards claimed too soon. Source: https://www.ramses.xyz/docs/mev ## Overview Ramses uses permissioned engines designed to capture eligible MEV opportunities and retain the resulting value within the protocol. Allocation depends on the module described below. Ramses' liquid-staked xRAM product is called **r33**, with the name **hyperRAM on HyperEVM**. The hyperRAM AMO flow below describes its HyperEVM implementation. --- ## MEV Solutions | Solution | Status | Description | | --- | --- | --- | | hyperRAM AMO (HyperEVM) | **LIVE** | Arbitrages the hyperRAM redeem floor and allocates the resulting value according to the AMO flow below. | | Backrun Arbitrage | **LIVE** | Captures eligible arbitrage opportunities and retains the resulting value within the protocol. | | Cross-chain Arbitrage | **COMING SOON** | Planned capture of price discrepancies across supported chains. | | Native Market Integration | **COMING SOON** | Planned atomic arbitrage between chain-native spot markets and Ramses deployments. | | Cross-venue Arbitrage | **COMING SOON** | Planned multi-step arbitrage across integrated protocols and venues. | --- ### Automated Market Operations (AMO) Ramses' AMO system is designed to optimize protocol efficiency and maximize value for all participants through systematic arbitrage when the hyperRAM redeem floor triggers. The AMO system executes a systematic arbitrage process: 1. Target liquidity pool identification 2. Application of the module's fee privileges 3. **RAM** → **hyperRAM** conversion 4. **hyperRAM** → **xRAM** redemption 5. Instant exit: **xRAM** → **RAM** 6. Allocation of the resulting value according to the rules below | Revenue Stream | Allocation | | --- | --- | | Exit Proceeds | 100% → Burn (deflationary; not distributed) | | Arbitrage Earnings | 100% → hyperRAM compounding | The AMO bot targets market inefficiencies through the atomic conversion and allocation flow above. > **Security Framework** > > - MEV executor authorization required (permissioned) > - Atomic transaction execution > - On-chain transaction visibility --- ### Backrun Arbitrage The backrun arbitrage bot is designed to capture eligible opportunities that would otherwise be available to external extractors. Its goal is to reduce loss-versus-rebalancing (LVR) and adverse selection for liquidity providers while retaining captured value within the protocol. --- ## MEV Infrastructure Ramses' current MEV infrastructure includes the live modules above. The roadmap expands that system across additional chains, venues, and protocols. ### Planned Multi-Venue Arbitrage | Dimension | Planned Capability | | --- | --- | | **Cross-chain arbitrage** | Capture discrepancies across supported chains | | **DEX-DEX arbitrage** | Trade across integrated DEXs to address cross-venue inefficiencies | | **CEX-DEX arbitrage** | Connect centralized and decentralized venues for price discovery | | **Native market integration** | Atomically arbitrage chain-native spot markets against Ramses deployments | ### Planned Privileged Atomic Execution | Feature | Benefit | | --- | --- | | **Zero-fee swaps** | Execute eligible arbitrage on Ramses pools without a pool swap fee | | **Atomic multi-protocol arbitrage** | Complete integrated supply → borrow → swap → repay workflows atomically | | **Sub-block execution** | Capture opportunities that exist only within block construction | | Example: Cross-protocol arbitrage | Flow | | --- | --- | | Cross-protocol price discrepancy | Swap → supply → borrow → swap → repay **(single atomic transaction)** | ### Dynamic Fee Integration The MEV infrastructure works with Ramses' [dynamic fee algorithm](https://www.ramses.xyz/docs/hyperram#dynamic-fees), which uses available market data to adjust fee levels in real time. This creates a **feedback loop** where: 1. Dynamic fees protect LPs during volatile periods 2. MEV bots capture arbitrage opportunities that would otherwise extract value from LPs 3. Arbitrage proceeds are allocated according to the active module 4. The protocol retains value that could otherwise leak to external extractors > **Revenue Generation** > > The MEV infrastructure is designed to retain value through current and planned arbitrage modules. Distribution depends on each module's documented allocation rules. --- ## Stopping Reverse JIT Liquidity Ramses pioneered **timer-based protection against reverse-JIT emissions farming**. The principle is direct: **claim rewards or change liquidity too soon, and the affected emissions are slashed.** Emissions should support liquidity that stays available for trading. ### How Ramses' Anti-Sybil Timer Works The **Voter** controls the anti-Sybil switch and the reward timer. For protected concentrated-liquidity positions, the position manager records the latest liquidity change, and the gauge checks the reward validator when processing a claim. 1. **A liquidity change starts the timer.** Creating a position, adding liquidity, or removing liquidity records a timestamp for that position. 2. **A reward claim checks the timer.** While anti-Sybil protection is enabled, the validator compares the time since that checkpoint with the threshold configured in the Voter. 3. **Claim too soon and lose those rewards.** If the timer has not cleared, the affected claim is slashed and redirected to **r33 (hyperRAM on HyperEVM)**. Once the timer has cleared, the timing check passes; other reward eligibility checks still apply. Liquidity increases and decreases also automatically attempt to claim emissions against the previous checkpoint **before resetting the timer**. Rapidly changing liquidity can therefore trigger the penalty even without pressing a separate claim button. > **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 duration and enabled state are configurable in the Voter and can differ by deployment. Integrators should read `timeThresholdForRewarder()` and `isAntiSybilEnabled()` from the relevant [Voter contract](https://www.ramses.xyz/docs/contract-addresses), rather than assume a fixed waiting period. This describes the concentrated-liquidity reward path; other pool types can settle rewards differently. Implementation references: [position checkpoints and automatic claims](https://github.com/RamsesExchange/ramses-v3-contracts/blob/main/contracts/CL/periphery/RamsesV3PositionManager.sol), [gauge reward validation and slashing](https://github.com/RamsesExchange/ramses-v3-contracts/blob/main/contracts/CL/gauge/GaugeV3.sol). --- # Audits Security audits, bounty program and reviews of Ramses. Source: https://www.ramses.xyz/docs/audits ## Ramses Architecture Ramses V3 is based on Uniswap V3, with several enhancements. These improvements include [dynamic system and protocol fee mechanisms](https://www.ramses.xyz/docs/hyperram#fees) and [x(3,3)](https://www.ramses.xyz/docs/hyperram#x-3-3). Ramses V3 also introduces a new accounting system to track how much active liquidity each concentrated liquidity position provides. ![Ramses Architecture](https://www.ramses.xyz/docs-assets/architecture.png) ### Pool Custody and System Mutability Ramses V2 and V3 liquidity pools are noncustodial. AccessHub does not expose a function that can withdraw an arbitrary LP's pool deposits or transfer a user's V3 position NFT. Withdrawing liquidity 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. This custody protection is distinct from system-wide immutability. Authorized AccessHub roles can change parameters and connected protocol configuration, including swap fees and fee splits, gauge status, emissions and reward settings, token whitelists, tick-spacing availability, and fee-collection settings. Multisig- and timelock-restricted paths can also update designated protocol dependencies and implementations. These controls do not give AccessHub custody of an individual user's pool position, but they can change the economic and governance conditions around that position. ### Access Control AccessHub uses three role-based permissions in addition to functions restricted directly to the treasury multisig or timelock. Actual role holders are deployment-specific and should be verified on-chain. - `DEFAULT_ADMIN_ROLE` can grant and revoke AccessHub roles. Early-stage deployments retain both multisig and timelock administration while controls are progressively transferred to the timelock; this transition is planned rather than assumed complete. - `PROTOCOL_OPERATOR` covers operational governance and configuration. Its authority includes whitelisting, creating, killing, and reviving gauges; changing emissions and reward settings; enabling tick spacings; and changing several treasury, fee, and factory parameters. - `SWAP_FEE_SETTER` sets pool swap fees and participates in fee-split and protocol maintenance paths used by the dynamic fee system. Some sensitive configuration and implementation changes remain restricted by direct multisig or timelock checks rather than these three roles. During the early operating stage, Ramses therefore retains non-timelock controls. The governance objective is to move appropriate authority progressively behind the timelock as the system matures. --- ![Total Audits](https://www.ramses.xyz/docs-assets/audits.png) --- ## Audits ### 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) | | --- | ### 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) | | --- | --- | ## Security Competition ### **Code4rena** Ramses V3 CLMM Contest [Report](https://code4rena.com/reports/2024-10-ramses-exchange) --- ## Additional Security Coverage - **Specialized Testing Review** by 100Proof via C4rena - **Post-Competition CL Audit** by Zenith Mitigation - **Private Development Review** by yAudit - **Testing Review** with Spearbit researchers --- # Contract Addresses Published contract addresses and deployment statuses for Ramses across supported chains. Source: https://www.ramses.xyz/docs/contract-addresses Select a chain to view published contract addresses, explorer links, and planned deployment entries. **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. --- ## Ethereum ## Ethereum Mainnet ### Core Contracts | Contract Name | Contract Address | | --- | --- | | RAM Token (Canonical) | Coming Soon | | OFT Adapter | Coming Soon | > **Ethereum Deployment** > > Canonical RAM on Ethereum and its OFT adapter are still in development and are not deployed. Contract addresses will be published alongside the mainnet deployment. ## 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) | --- ### 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://robinhoodchain.blockscout.com/address/0x5173D45A1191eE33cBB7D8c7e65f21B04eD54802) | | r33 — xRAM Liquid Staking Token (known as hyperRAM on HyperEVM) | [0x4e5195469A0360f5dfe811730C9CCaCFF0a0FeeE](https://robinhoodchain.blockscout.com/address/0x4e5195469A0360f5dfe811730C9CCaCFF0a0FeeE) | --- ### V2 AMM (Legacy) | Contract Name | Contract Address | | --- | --- | | PairFactory | [0x43B2Bf9f33036a02fC7A00935571c2A6b0108e66](https://robinhoodchain.blockscout.com/address/0x43B2Bf9f33036a02fC7A00935571c2A6b0108e66) | | Legacy Router | [0x33D3CDD45E4D64Ea762574789A2DB4842EC8262E](https://robinhoodchain.blockscout.com/address/0x33D3CDD45E4D64Ea762574789A2DB4842EC8262E) | | FeeRecipientFactory | [0xA87c8308722237F6442Ef4762B7287afB84fB191](https://robinhoodchain.blockscout.com/address/0xA87c8308722237F6442Ef4762B7287afB84fB191) | --- ### V3 AMM (Concentrated Liquidity) | Contract Name | Contract Address | | --- | --- | | RamsesV3Factory | [0xE0c4ceb92d08CA985bB70fe0a22fEb121A9854A8](https://robinhoodchain.blockscout.com/address/0xE0c4ceb92d08CA985bB70fe0a22fEb121A9854A8) | | FeeCollector | [0x2Bef16A0081565E72100D73CBe19B1Bd2d802380](https://robinhoodchain.blockscout.com/address/0x2Bef16A0081565E72100D73CBe19B1Bd2d802380) | | RamsesV3PoolDeployer | [0x4b37359BF291AbE8453692DB58d515a8b013Dca9](https://robinhoodchain.blockscout.com/address/0x4b37359BF291AbE8453692DB58d515a8b013Dca9) | | RamsesV3PositionManager | [0x2eBd7B85a4E08D5B508b04BA147976C94afE6590](https://robinhoodchain.blockscout.com/address/0x2eBd7B85a4E08D5B508b04BA147976C94afE6590) | | NonfungibleTokenPositionDescriptor | [0x486EC4dda7fEB9871eEF0d6ccc0D79dD3f7af7a4](https://robinhoodchain.blockscout.com/address/0x486EC4dda7fEB9871eEF0d6ccc0D79dD3f7af7a4) | | UniversalRouter | [0xbFbb2BCBc9dfFA029C27A249ae9BE031E1d83b1C](https://robinhoodchain.blockscout.com/address/0xbFbb2BCBc9dfFA029C27A249ae9BE031E1d83b1C) | | QuoterV2 | [0x4730e03EB4a58A5e20244062D5f9A99bCf5770a6](https://robinhoodchain.blockscout.com/address/0x4730e03EB4a58A5e20244062D5f9A99bCf5770a6) | | QuoterV1 | [0x807a31EF83342D279a1F7708Adbc3492405A4CbC](https://robinhoodchain.blockscout.com/address/0x807a31EF83342D279a1F7708Adbc3492405A4CbC) | | TickLens | [0x0C20C6E42242DB7AF259CC40366A07B198f2C295](https://robinhoodchain.blockscout.com/address/0x0C20C6E42242DB7AF259CC40366A07B198f2C295) | | UniswapInterfaceMulticall | [0x00d4FeA3Dd90C4480992f9c7Ea13b8a6A8F7E124](https://robinhoodchain.blockscout.com/address/0x00d4FeA3Dd90C4480992f9c7Ea13b8a6A8F7E124) | | MixedRouteQuoterV1 | [0x23B6EC50Fe0197FbE436717a0676BC07c54ba562](https://robinhoodchain.blockscout.com/address/0x23B6EC50Fe0197FbE436717a0676BC07c54ba562) | | SwapRouter | [0xFCBBe2Af83F94e7E2a9C35a535B3A04719aFD2Ae](https://robinhoodchain.blockscout.com/address/0xFCBBe2Af83F94e7E2a9C35a535B3A04719aFD2Ae) | --- ### DLMM | Contract Name | Contract Address | | --- | --- | | DLMMFactory | [0xdcD5F77697914E27f56FD263EF82923C8524AbAc](https://robinhoodchain.blockscout.com/address/0xdcD5F77697914E27f56FD263EF82923C8524AbAc) | | DLMMFeeCollector | [0xcc543a9EDBa25cEB2922b165047b6A7bE861C55b](https://robinhoodchain.blockscout.com/address/0xcc543a9EDBa25cEB2922b165047b6A7bE861C55b) | | DLMMRouter | [0xd0019e86edB35E1fedaaB03aED5c3c60f115d28b](https://robinhoodchain.blockscout.com/address/0xd0019e86edB35E1fedaaB03aED5c3c60f115d28b) | | DLMMQuoter | [0xb722efaAbe807FAeA16068f595EaA9aa1a62CECD](https://robinhoodchain.blockscout.com/address/0xb722efaAbe807FAeA16068f595EaA9aa1a62CECD) | --- ### Access Control | Contract Name | Contract Address | | --- | --- | | Ramses Team Multisig | [0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A](https://robinhoodchain.blockscout.com/address/0x20D630cF1f5628285BfB91DfaC8C89eB9087BE1A) | | Ramses Timelock | [0xE41c07CcD69A0f19A2186f3Ad30409BD585436CE](https://robinhoodchain.blockscout.com/address/0xE41c07CcD69A0f19A2186f3Ad30409BD585436CE) | | AccessHub ProxyAdmin | [0xA203A21dCCB461E415DaA342E8e635B6CeE0cCb3](https://robinhoodchain.blockscout.com/address/0xA203A21dCCB461E415DaA342E8e635B6CeE0cCb3) | | AccessHub | [0x83341F891f898cb5E0cacC8a70501BBa83d9CecF](https://robinhoodchain.blockscout.com/address/0x83341F891f898cb5E0cacC8a70501BBa83d9CecF) | ## 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) | | 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. --- # How to Swap Learn what to review before submitting a token swap on Ramses. Source: https://www.ramses.xyz/docs/swapping Learn what to verify before swapping tokens on Ramses. --- > **Guide in Progress** > > The illustrated swap walkthrough is being updated. Always review the transaction details shown by the current app before signing. ## Before You Swap - 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 and earn rewards through concentrated liquidity farming on Ramses. Source: https://www.ramses.xyz/docs/farming Learn the core considerations for providing liquidity and earning eligible pool rewards on Ramses. --- > **Guide in Progress** > > The step-by-step farming walkthrough is being updated. Review the [concentrated liquidity](https://www.ramses.xyz/docs/concentrated-liquidity) and [DLMM](https://www.ramses.xyz/docs/dlmm) documentation before creating a position. ## 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. - Treat displayed APR as an estimate, not a guaranteed return. - Verify whether the pool is eligible for emissions or other incentives. > **Liquidity Risk** > > Providing liquidity exposes you to smart-contract, token, inventory, and impermanent-loss risk. A concentrated position may stop earning fees when the market moves outside its selected range. ## Position Dashboard Use the dashboard to monitor estimated APR, position value, unclaimed rewards, and the current price relative to your selected range. Position-management controls let you add or remove liquidity when the relevant contracts and network are available. --- # How to Vote Learn how xRAM voting directs emissions and determines eligible voter rewards each epoch. Source: https://www.ramses.xyz/docs/voting Use xRAM voting to direct RAM emissions to eligible liquidity pools. --- > **Guide in Progress** > > The illustrated voting walkthrough is being updated. Review the current app state, gauge status, and transaction details before submitting a vote. ## Before You Vote - Voting requires staked xRAM. - Only active gauges are eligible to receive directed emissions. - Voter fees and incentives depend on the pools selected and your share of the votes for those pools. - Review the [xRAM voting mechanics](https://www.ramses.xyz/docs/xram#voting) before participating. > **Definition** > > An **epoch** is Ramses' seven-day accounting period. Each epoch begins Thursday at **00:00 UTC**; voting and reward accounting roll over at the epoch boundary. > **Vote Timing** > > Voting later in an epoch can provide a more complete view of incentives and vote dilution, but waiting also increases the risk of missing the epoch deadline. --- # 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 Illustrative comparison at the 1% fee tier, with Uniswap V3 protocol fees enabled. Same attributable gross fees and equal LP exposure. Attributable gross fees: $100,000. | Fee allocation | Ramses (standard fee-only pool) | Uniswap V3 (1% tier, protocol fee enabled) | | --- | --- | --- | | LP share of gross fees | 95% | 83.34% | | Protocol share of gross fees | 5% | 16.66% | | Collected LP fees | $95,000 | $83,340 | | Protocol fees | $5,000 | $16,660 | Ramses retains $11,660 more in collected LP fees in this example: approximately 14% more than the Uniswap V3 baseline. ### An illustrative 80/20 fee split Apply an 80% creator / 20% platform split to collected LP fees, after the DEX protocol fee. | Recipient | Ramses | Uniswap V3 | Difference | | --- | --- | --- | --- | | Creator (80%) | $76,000 | $66,672 | +$9,328 | | Platform (20%) | $19,000 | $16,668 | +$2,332 | 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 1% 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 rounded rates are 0.8334% for LPs and 0.1666% for the protocol at the 1% tier: 83.34% and 16.66% of gross fees, respectively. These rounded rates determine the dollar amounts shown. - 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. - Amounts are illustrative 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) --- # 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 A smart contract that holds liquidity reserves. Users can trade against these reserves at prices determined by a fixed formula. Anyone can contribute liquidity to earn fees, emissions, and [liquidity incentives](https://www.ramses.xyz/docs/hyperram#vote-incentives). ### 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 rewards to LP tokens based on voting distribution. ### 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 pair and pool ERC20 tokens. Liquidity providers assume price risk and are compensated with emissions and [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. Each token pair can have multiple pools with different fee tiers, which adjust dynamically based on market volatility. 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 Price change between trade submission and execution. ### Spot Price The current exchange rate between two assets in a pool, calculated from the pool's reserves before any trade occurs. ### 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/Sarcophagus. 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 [Download media assets](https://www.ramses.xyz/docs-assets/Ramses_Mediakit.zip) ![Ramses Brand Kit](https://www.ramses.xyz/docs-assets/brandkit.png)