Skip to content
Browse docsBuyback Module

Buyback Module

Markdown

How the Robinhood Buyback Module collects protocol fees, converts assets into RAM, and permanently removes RAM from circulation.

From Protocol Fees to RAM Buybacks

The Buyback Module is the current destination for Ramses protocol fees on Robinhood Chain. Accumulated assets fund automated RAM buybacks, with execution restricted to authorized callers. RAM received by the module is sent to the dead address, permanently removing it from usable circulation.

The Fee-to-Buyback Loop

  1. Collect fees. The configured protocol share of pool fees is collected into the module as token balances.
  2. Execute a buyback. An authorized executor chooses an input asset, a maximum input amount, a whitelisted aggregator, and a minimum RAM output.
  3. Check the result. The contract measures the actual input spent and RAM received. The transaction reverts if the input limit is exceeded or the minimum RAM output is not met.
  4. Retire RAM. The module transfers the received RAM to 0x000000000000000000000000000000000000dEaD in the same transaction and emits a BuybackExecuted event.

If the module already holds RAM, an authorized executor can send that RAM directly to the dead address without a swap. These executions also emit BuybackExecuted; a completed event therefore does not always represent a market purchase.

Buybacks depend on available balances, executable liquidity, and authorized execution. The contract does not enforce a fixed schedule or guarantee a buyback amount.

Fee Distribution

On Robinhood Chain, each pool's configured protocol fee share is routed to the Buyback Module to fund RAM buybacks.

Execution and Controls

The verified BuybackModule implementation restricts buybackAndBurn to callers with the AccessHub SWAP_FEE_SETTER role. Users do not approve or bury r33 to claim the module's assets.

  • Approved routes: swaps must use a whitelisted aggregator contract.
  • Bounded input: the aggregator receives an allowance for the specified input amount, and that allowance is cleared after the call.
  • Minimum output: each execution requires a nonzero minimum RAM output and checks the actual balance increase.
  • Atomic execution: the swap, output check, and RAM transfer complete together or revert together.
  • Administrative controls: the AccessHub default admin can update the aggregator whitelist and rescue ERC-20 balances.

The minimum output is supplied by the authorized executor; it is not an independent price oracle or a guarantee of the best available price.

What the Burn Means

Here, burned RAM means RAM transferred to the dead address. This removes RAM from usable circulation but does not reduce the Robinhood token's ERC-20 totalSupply. It is tracked separately from supply-reducing RAM burns on HyperEVM.

Legacy Sarcophagus burials sent r33 to the dead address, retiring the liquid claim on its underlying xRAM and RAM backing. The Buyback Module instead retires RAM itself. Historical r33 burials remain part of the record and should not be counted again as new RAM buybacks.

Contracts and Activity

The tokenomics dashboard tracks confirmed Buyback Module activity alongside other burn mechanisms. Its buyback history matches BuybackExecuted events to RAM transfers to the dead address in successful transaction receipts. Assets still held by the module are not completed buybacks.

View all contract addresses →