Skip to content
Merry MenMerry MenMerry Men

Protocol revenue

The house’s 0.10% of trade volume funds operations and a community-rewards loop that pays referrers (and, by extension, the traders they bring) in WETH: revenue routed back into the ecosystem rather than out to a team bag. (The burns on the current generation are the per-coin sell-fee burns, which are not revenue at all, nobody receives them; a legacy buyback also keeps running on first-generation coins’ fees, see Earlier generations.)

The rewards flywheel

Section titled “The rewards flywheel”

Referrers earn a cut of the fees generated by the volume they bring. Rewards are paid in WETH against a cumulative Merkle root that a keeper publishes each epoch. Claims are pull-based and proof-bounded.

The mechanism:

  1. A wallet is referred; the binding is recorded (first-write-wins).
  2. Every epoch (6h) a keeper reads each referred wallet’s windowed WETH volume from the indexer, computes each referrer’s cumulative reward, and builds a Merkle tree.
  3. The keeper publishes the reward data (so the claim page can show it) and calls setRoot(root) on the RewardsDistributor.
  4. Referrers claim their WETH from the distributor with a Merkle proof.

Economics: self-funding

Section titled “Economics: self-funding”

Rewards are sized to be paid out of the protocol’s own fee take, not out of pocket:

  • Rewards are 0.02% of referred volume.
  • The house takes 0.10% of volume, so the reward is one-fifth of the house’s take on referred volume, and nothing at all on unreferred volume.

A creator’s share never funds referrals; rewards come out of the house’s 0.10% only.

Referred volume (WETH) Rewards owed (WETH value)
100 0.02
1,000 0.2
10,000 2

Rewards accrue over a rolling referral window (90 days). The distributor holds a WETH pool that must stay ahead of the sum of unclaimed cumulative rewards; because claims are cumulative and pull-based, under-funding only makes a claim wait (it is never lost) and over-funding is recoverable.

Trust model

Section titled “Trust model”

The design keeps funds safe from the party that publishes roots:

  • updater (keeper). Can only call setRoot. It holds no funds and can never move them; it just posts the cumulative root each epoch.
  • authorizer (admin, immutable). Can rotate the updater (setUpdater) and recover undistributed WETH (recover). It cannot rewrite what has already been claimed, so it can never negate an executed claim.

A compromised keeper key can, at worst, publish a bad root; the authorizer rotates it. Neither role can claw back WETH a referrer has already claimed.

Live

Section titled “Live”

The rewards distributor is deployed and armed on Robinhood Chain mainnet (4663):

Piece Value
RewardsDistributor 0xb81Db9E11Ce95482Ce33cBf16317E22A8ea0c558
Reward token (WETH) 0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73

Referrers claim on the rewards page. See Contract addresses for the full deployment.

Referral codes

Section titled “Referral codes”

Referral links use opaque share codes (?ref=<code>) rather than raw wallet addresses, so a referrer’s wallet never appears in a shared URL. The code resolves to the referrer’s address server-side when a new wallet binds.

Section titled “Related”