Ramses exchange profile

Ramses is an automated market maker with several network deployments and RAM governance products. Users swap tokens or supply smart-contract liquidity. Each deployment retains its own pools: shared token connectivity does not merge their reserves or order flow.[1][2]

DefiLlama’s 20 October 2026 snapshot at 20:43:48 UTC recorded approximately US$1.862 billion of rolling 30-day volume across five Ramses adapters. Concentrated Liquidity V2 supplied US$1.852 billion of that total. This is adapter-reported spot turnover, not a count of registered people or active traders.[34]

A V3 range order approximates a limit trade by placing single-asset liquidity beyond the current price. Conversion occurs as price crosses the selected range. If price reverses before the user removes the position, the assets can convert back. It therefore needs an explicit withdrawal or authorised position manager to preserve the completed conversion. The documented design cannot reproduce ordinary buy-stop or stop-loss instructions.[6]

Launchpad integrations can create a Ramses pool at launch, move liquidity after a bonding curve finishes, or allocate sale proceeds to liquidity. A compatible locker or fee distributor can direct collected V3 fees to nominated recipients. The launchpad controls its own distribution and lock conditions; that integration does not make every Ramses pool a locked or managed product.[19]

The technical fee reference distinguishes governance-set V3 fees from DLMM’s on-chain variable fee. A V3 pool stores the current rate; authorised changes can override its initial tier. DLMM combines a base charge with a movement-sensitive component, subject to contract caps. Its volatility input comes from bin activity, not an external market-price feed. Obtain a complete route quote: deducting a nominal fee alone cannot reproduce price impact or multihop output.[7]

For an explicitly hypothetical 10,000 USDC input into a pool charging 0.05%, the swap fee is 5 USDC. Under a 95%/5% fee-only split, 4.75 USDC belongs to LP economics and 0.25 USDC to the protocol. This illustrates allocation, not the final bought-token amount; gas, price impact, additional route legs and token-specific effects remain outside the calculation.[7]

Emissions, fee income and vote incentives are different sources of return. RAM issuance expands supply, while conversions and some buybacks reduce usable supply in different ways. The published supply ceiling limits outstanding RAM at a point in time, not cumulative lifetime issuance. A displayed annualised emission rate is therefore different from a forecast of net dilution or an LP’s realised return.[29]

The V3 token-integration reference excludes ordinary fee-on-transfer tokens from its routers. It also warns that a negative rebase can reduce an LP’s assets when the position becomes active, without a protocol recovery mechanism. A familiar ticker or successful pool creation is insufficient to establish compatibility. Contract identity, token behaviour and network matter separately.[10]

HyperEVM transactions above the small-block gas limit can require big-block mode. Ramses documents automatic switching after estimation, but the user still needs an active HyperCore account, HYPE there for the mode-setting transaction, and HYPE on HyperEVM for execution. The suggested 0.1 HYPE on HyperCore is a preparation recommendation, not a universal exchange deposit minimum. A failed mode switch requires resolving that funding or account prerequisite before retrying.[11]

The published contract directory separates token endpoints, routers, position managers, governance and access-control addresses for each deployment. This matters when moving RAM or r33: an OFT transfer is a separate cross-chain action with its own message fee and destination gas requirements. A token appearing on another network does not create a corresponding Ramses trading pool there.[25]

The audit overview describes LP ownership through pool shares or position NFTs. Ordinary removal requires the holder or an approved operator; AccessHub is not presented as a universal withdrawal key for arbitrary LP principal. Those protections coexist with smart-contract, dependency and governance risk. The inspected audit material did not establish a retail deposit-insurance policy or a contractual compensation limit.[16]

An illustrative conversion of 2,000 RAM creates 2,000 xRAM, burns 1,000 RAM and leaves 1,000 RAM as redemption backing. Redeeming all 2,000 xRAM directly therefore returns 1,000 RAM before transaction costs. This example contains no token-price forecast and does not value any rewards earned while participating.[13]

AccessHub divides authority among operational roles, the treasury multisig and timelock-only functions. These can change swap fees, incentive gauges, whitelist settings, emissions, vote-module parameters and certain implementations. A timelock can also invoke an exceptional execution function. The published role design should not be read as a universal delay on every economic change: fast fee-setting powers and deployment-specific wiring remain material.[17]

The anti-reverse-JIT mechanism can penalise rewards claimed too soon after a liquidity change where enabled. Adding or removing liquidity may automatically attempt a reward claim before resetting the timer, so forfeiture can occur without a separate claim-button action. The documented penalty concerns emissions, not confiscation of LP principal. Collecting ordinary swap fees alone does not reset that timer.[15]

Access begins with a compatible wallet rather than a conventional funded broker account. That operational design does not establish unrestricted legal access. Ramses’ legal disclaimer places responsibility for applicable rules on the user; a complete country schedule, formal customer classification and interface contracting entity were not established from the inspected materials. Any separate wallet, bridge or fiat provider can impose additional conditions.[18]

Wallet keys and recovery remain the wallet holder’s responsibility. Ramses’ onboarding guidance does not provide a support-assisted recovery route for a lost seed phrase or a reversal of a finalised transfer. Retaining a wallet connection in a browser is separate from maintaining custody of the keys or ownership of an on-chain position.[8]

Official technical documentation links to Ramses’ Discord and contract repositories. Developer support is especially relevant when an integration cannot obtain a complete quote, encode a route, or interpret bin-share removal. No committed consumer telephone service, emergency telephone dealing facility or response-time agreement was established. A support conversation cannot substitute for a wallet signature or make an unconfirmed transaction final.[30]

The farming dashboard displays positions, value, range status, unclaimed rewards and estimated annual returns. Those estimates change with volume, token prices, incentive allocation and time in range. Preserve the transaction hashes, amounts, token addresses and reward claims needed to reconstruct activity; the inspected guide does not establish a tax-ready statement or a complete downloadable cost-basis ledger.[20]

A submitted on-chain position survives closing the browser. For swaps built through the V3 SDK, the signer specifies a recipient, slippage tolerance and deadline; an excessive deadline can leave an instruction pending much longer than intended. Changing a webpage setting after submission does not change the already signed transaction. Check its chain state before replacing it.[24]

The REST reference publishes chain-specific data endpoints and GraphQL conversion, with a limit of 30 requests per 30 seconds per client IP. Its shared gateway also lists infrastructure for other networks, which is not evidence that Ramses operates a DEX on each one. The V3 SDK separately supplies TypeScript/JavaScript tools for interacting with deployed contracts; code can construct transactions, but execution still depends on the signing authority granted by the user.[22][23]

AutoVault delegates weekly voting to an operator and lets a depositor choose an enabled ERC-20 reward output. Fees and incentives are converted and credited for manual claim rather than automatically reinvested into the deposited position. Deposits and output changes pause during the vote cooldown. This is defined contract and operator automation; no general discretionary AI trading mandate was established.[14]

No current entity-specific financial authorisation was established for the interface from the inspected legal material. A protocol contract, source-code licence or audit does not supply such a permission. This profile therefore records no positive regulator entry; the unresolved point is the contracting and authorisation position, not a finding that every use is prohibited.[18]

The contract licence identifies Social Unicorn Foundation LLC as the commercial licensing contact. It describes kBUSL 1.1 as source-available, with production deployment requiring approval under its terms. That identifies a software-licensing role; it does not, by itself, identify the entity contracting with every swap user or establish supervision of client assets.[26]

Ramses X is the multichain architecture of this Ramses profile, not a separately counted exchange. Each deployment can have its own fee policy, incentive activation and governance state, so an older Arbitrum-era product description is insufficient for a current satellite pool.[2]

HyperRAM and r33 name the same liquid-staked xRAM product; HyperRAM is the name used on HyperEVM.[12]

On 14 October 2026, the Robinhood fee recipient changed from the Sarcophagus to the Buyback Module. The new module lets an authorised fee-setter execute constrained aggregate routes and retire received RAM to the dead address; administrators control approved routes and rescue functionality. An accumulated balance is not a completed buyback, and the documentation supplies no fixed execution schedule.[27]

Earlier Sarcophagus transactions retired r33 claims and permanently locked the associated backing. They remain historical activity. The replacement of its fee-recipient role does not demonstrate that every legacy contract function has been disabled. Robinhood transfers to the dead address also do not reduce the ERC-20 totalSupply field, so they must not be counted again as HyperEVM supply-reducing burns.[28]

Operator

Ramses protocol; interface contracting entity not established

Exchange model

Decentralised

Service scope

AMM swaps, liquidity provision and RAM governance products.

Client types

Not established

Pricing publication

Public pricing

Other names

Ramses Exchange; Ramses X

Pricing scope

Pool-specific fees, gas and configured reward splits.

Funding scope

Supported on-chain tokens and native network gas.

Custody and asset handling

Wallet keys remain with users; deposited assets follow pool, staking and governance contracts.

Client eligibility

Wallet access; complete territorial and contracting terms not established.

Support

Official documentation, Discord and developer repositories.

Authorisation and registration scope

No entity-specific financial permission established.

Exchange metadata checked 20 Oct 2026Source 1Source 2Source 18Source 26

Manual voting uses weekly epochs beginning Thursday at 00:00 UTC. Eligible xRAM voters allocate their voting weight among active gauges, influencing the next emission period, then claim eligible fees and incentives after rollover. A vote does not by itself establish an immediately withdrawable cash bonus, and claims are not automatically paid simply because the wallet remains connected.[21]

RAM distributions include community, incentive, treasury and protocol-owned-liquidity allocations. The live supply presentation distinguishes issued tokens, supply-reducing burns and retired claims. Its projection assumes current emission settings and an optional historical burn pace; authorised future changes and future trading demand are not predictable from that display.[29]

For transaction reconciliation, retain the network and token contract together with the hash, position identifier and relevant epoch. The same name can refer to different contract addresses across chains. The published deployment directory also separates team multisigs, timelocks and access hubs, allowing a reader to identify the applicable administrative structure without assuming that one address or configuration applies everywhere.[25]