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% |
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 |
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.