← Protocols
ERC-7641 — Intrinsic RevShare Token
Standard / EIP·EVM

ERC-7641 — Intrinsic RevShare Token

01Description

Draft ERC extending ERC-20 with built-in revenue sharing: token holders periodically claim their pro-rata share of a communal revenue pool, and can burn tokens to redeem a proportional slice of the pool's underlying assets. Status: Draft.

02Best for
  • 01fee-sharing tokens
  • 02protocol revenue distribution to holders
  • 03buyback-and-distribute models
  • 04tokenized cash-flow assets
03Install
  • # Reference impl in the ERC-7641 EIP — no canonical library yet
05Prompt snippet
Implement ERC-7641 on top of ERC-20 by maintaining a `revenuePool` (in ETH or ERC-20) replenished by protocol fees. Define epochs with `snapshotInterval` and accumulate per-epoch snapshots. Required surface: `claimableRevenue(address account, uint256 snapshotId) returns (uint256)`, `claim(uint256 snapshotId)`, `redeem(uint256 amount)` — burns tokens and pays out a pro-rata share of the current pool, `redeemableOnBurn(uint256 amount) returns (uint256)`. Emit `Snapshot`, `Claim`, `Redeem`. Pair with OZ `ERC20Snapshot` (or the newer `ERC20Votes` checkpoint pattern) for historical balance lookup. Keep snapshot creation cheap (only `_totalSupply` snapshot, lazy per-account) so distribution gas stays bounded.
06Gotchas
  • Status is Draft — function names and event signatures will likely change before Final. Do not rely on exact selectors when integrating from a third-party dApp.
  • Naive per-snapshot iteration in `claim` is O(snapshots since last claim) — if a holder is dormant for years they cannot fit a claim into block gas. Use a pull-based accumulator-per-share pattern (à la MasterChef) instead of literal snapshots.
  • `redeem` (burn-for-pool-share) is a back-door exit from the token — combined with low liquidity it can be more advantageous than market sell, draining the pool and crashing token value. Cap `redeem` per epoch or charge a redemption fee.
  • Front-running snapshots: if a snapshot timestamp is predictable, an attacker buys tokens just before, claims, then sells. Mitigate with random/VRF-driven snapshot timing or a minimum-hold period.
  • Revenue token mismatch: paying out in WETH while protocol earns in USDC requires a swap router — adding swap dependency means failed swaps block claims for everyone. Distribute in the native fee asset and let users swap themselves.
07Alternatives