Skip to main content
Sarcophagus is a permissionless, fixed-cost mechanism for exchanging r33 for ERC-20 protocol fees accumulated by the contract. A successful caller sends the current r33 threshold directly to the dead address and receives the Sarcophagus’s entire balance of every selected fee token.

Permissionless execution

Any address can call bury with a valid nonce, token list, minimum outputs, r33 balance, and allowance.

Atomic settlement

The r33 payment and every selected token transfer succeed together or the whole transaction reverts.

Fixed on-chain cost

There is no oracle or auction curve. The owner-configured r33 threshold is the contract’s only exchange price.

Searcher-directed claims

Callers choose which ERC-20 balances to claim, up to the current maxTokenClaim value.
The Robinhood contract is deployed and verified. A viable claim exists only after ERC-20 fees have reached it and their realizable value exceeds the r33 cost, gas, slippage, and execution risk. Fee routing and balances must be checked live.

Robinhood deployment

The following values were read at Robinhood block 38,278,392 on August 16, 2026. Mutable values can change after this block.
Canonical addresses
exchangeAmountThreshold, maxTokenClaim, nonce, token balances, and the caller’s r33 allowance are execution inputs—not constants. Read them at one block, build the call, and simulate the exact transaction against current state.

Execution flow

bury is an atomic first-valid-transaction race. It is not a Dutch auction, sealed-bid auction, or oracle-priced swap. The first included transaction that satisfies every check consumes the current nonce and claims the selected balances.
1

Validate the call shape

The token list must be non-empty, no longer than maxTokenClaim, and the same length as the minimum-output array.
2

Consume the expected nonce

The supplied nonce must equal nonce(). The contract increments it for the successful claim. A later revert rolls the increment back with the rest of the transaction.
3

Send the r33 threshold

safeTransferFrom moves exactly exchangeAmountThreshold r33 from the caller directly to 0x000...dEaD.
4

Sweep selected fee assets

For each selected token, the contract reads its complete Sarcophagus balance, checks it against the paired minimum, and transfers that full balance to the caller.
5

Emit the receipt

A successful call emits Buried(nonce, user, tokensClaimed) using the nonce supplied by the caller.
This Robinhood deployment sends r33 to 0x000...dEaD; it does not call an r33 burn function. The transfer removes the tokens from ordinary circulation but does not reduce the ERC-20 totalSupply value.

Searcher runbook

1. Discover candidate fee assets

Sarcophagus does not maintain an enumerable token registry. Searchers must discover candidates from trusted Ramses fee-source configuration, ERC-20 Transfer logs into the contract, or another independently maintained index. Treat discovery as untrusted input:
  • Confirm every candidate is the intended token contract on chain 4663.
  • Read balanceOf(Sarcophagus) at the same pinned block used for the other quote inputs.
  • Exclude zero balances and tokens with incompatible or reverting ERC-20 behavior.
  • Deduplicate token addresses before constructing the call.
  • Do not assume the contract holds only assets shown by a block explorer UI.

2. Price the opportunity

For candidate tokens (T_i), a claim is economically attractive only when the expected realizable output exceeds all costs: ivalue(balancei)>value(r33Threshold)+gas+slippage+risk\sum_i \operatorname{value}(balance_i) > \operatorname{value}(r33Threshold) + gas + slippage + risk The contract does not calculate this inequality and does not validate token prices. Searchers are responsible for pricing, liquidity checks, gas estimation, and downstream execution.

3. Set minimum outputs

_minAmountsOut[i] is compared with the raw Sarcophagus balance of _tokens[i]. It is not a price, quote, or decimal-normalized value. Use minimums to protect against another transaction reducing a selected balance before inclusion. Setting every minimum to zero removes that protection and can allow the call to pay r33 while receiving no value from one or more selected tokens.

4. Approve and simulate

The caller needs at least the threshold amount of r33 and sufficient allowance for Sarcophagus. Approval is made on the r33 token; r33 should not be transferred to Sarcophagus manually. Simulate the exact bury call from the intended sender immediately before submission. A successful simulation is only a point-in-time result: another claim or owner update can still make the pending transaction revert.

5. Submit competitively

Public-mempool transactions reveal the selected assets and minimums. Another searcher can independently submit a valid claim with the same nonce if it has r33 and allowance. The contract does not reserve an opportunity for the first observer. After inclusion, verify the transaction status and Buried event rather than inferring success from submission alone.

TypeScript example

This viem example pins quote reads to one block, applies a 0.5% balance buffer, checks allowance, and simulates the exact call. Candidate-token discovery and economic pricing are intentionally separate.
The example uses an environment variable only to keep the transaction flow concise. Production searchers should use an appropriate signer, isolated key policy, transaction replacement strategy, and private-orderflow decision for their operating environment.

Contract interface

State reads

bury

The function is nonReentrant. On success it transfers the r33 threshold from msg.sender to the dead address, then transfers the complete pre-transfer Sarcophagus balance of each selected token to msg.sender.

Owner functions

  • rescue can move any ERC-20 balance from the contract at any time.
  • The threshold and maximum claim count must each remain greater than zero.
  • Parameter setters do not emit dedicated events in this deployment. Track owner transactions and confirm storage directly.

Events and errors

Buried

The event records the consumed nonce, successful caller, and requested token-address array. It does not include transferred amounts; reconstruct amounts from transaction traces, ERC-20 Transfer logs, or pre-transaction state.

Custom errors

ERC-20 calls can also revert with token-specific errors or SafeERC20 failures.

Atomicity and token behavior

The entire transaction reverts, including the r33 transfer and nonce increment. A malformed or incompatible token therefore blocks only batches that include it; retry without that token.
The first occurrence can transfer the token’s full balance. A later occurrence observes the remaining balance, normally zero. A positive minimum on the duplicate reverts the entire call; a zero minimum adds no value and wastes gas.
No. The minimum is checked against balanceOf(Sarcophagus) before transfer, not the caller’s received amount. A transfer-tax token can deliver less than its checked balance, and unusual rebasing or callback behavior may cause different results or a revert.
Yes. Token selection is not allowlisted, and the contract does not exclude r33. The claim payment goes directly from the caller to the dead address, while any r33 already held by Sarcophagus can be selected like another ERC-20 balance.
No. bury and rescue operate on ERC-20 token contracts. Native ETH is not part of the claim interface.

Security and trust boundaries

Searchers should assume that the owner can change the threshold or maximum token count and can rescue tokens before a claim is included. Token balances can also change independently as fees arrive or other transfers occur. Use live reads, explicit minimums, and exact-call simulation.

Verified build

The constructor was deployed with the Ramses owner address and r33 token address listed above. The deployment is not a proxy; mutable behavior is limited to the exposed owner-controlled parameters and rescue function.

Resources