ANN Revenue Bonds Protocol – Permissionless on-chain revenue sharing (Arbitrum O

[equorumprotocol]

Hello everyone,

I’m sharing a new protocol that has just gone live on Arbitrum One.

Revenue Bonds Protocol is a permissionless framework that allows protocols to tokenize revenue-sharing agreements on-chain using standard ERC-20 tokens.

In short:
• Any protocol can create its own Revenue Series (self-issued)
• Each series deploys an ERC-20 token + a Router
• Protocols voluntarily deposit revenue (ETH)
• Token holders can claim revenue proportionally using a pull-based model
• No staking, no inflation, no admin-controlled payouts

The goal is not to enforce revenue sharing, but to provide transparent, on-chain accounting and trust-minimized distribution once revenue is deposited.

Key characteristics:
• Permissionless factory
• Immutable series parameters (share %, duration, supply)
• Pull-based claims (no mass payouts, no loops)
• Fully on-chain accounting
• No protocol fees (for now)

Mainnet (Arbitrum One):
Factory:
0x8afA0318363FfBc29Cc28B3C98d9139C08Af737b

Website:
https://equorumprotocol.org

App:
https://app.equorumprotocol.org

GitHub:
https://github.com/EquorumProtocol/Equorum-Revenue-Bonds

Whitepaper is available on the site.

This is experimental software and not audited yet. Feedback, questions and technical criticism are very welcome.

[BattleDog]

Since the ERC-20 is transferable, how are you handling the "who owned how much during which deposits" problem without snapshots or a giant mess?

If you're using the usual magnified-per-share + per-account correction approach, that's cool, but I'd want to know what invariants you're testing (total claimed never exceeds total received, transfers don't let you double-dip, etc).

[equorumprotocol]

Good question – this is exactly the core problem we focused on.

We do not use snapshots.

The model is the standard cumulative-per-token accounting (magnified-per-share style), implemented explicitly to support fully transferable ERC-20 tokens without historical ownership tracking.

High level:

– Each RevenueSeries keeps a cumulativeRevenuePerToken value.
– On each revenue deposit, we increment:
  cumulativeRevenuePerToken += msg.value / totalSupply.
– Each account tracks a lastClaimedPerToken checkpoint.
– Claimable revenue is:
  balance(account) * (cumulativeRevenuePerToken - lastClaimedPerToken).

This means ownership is evaluated lazily at claim time, not at deposit time.

Transfers are safe because:
– lastClaimedPerToken is updated on claim, not on transfer.
– A transferred token carries no historical entitlement beyond what has already been accounted for.
– There is no way to double-dip since entitlement is always relative to the last checkpoint.

Invariants we test explicitly:

1) Total claimed ≤ total ETH received by the series.
2) Sum of all future claimable amounts + total claimed = total received (within rounding bounds).
3) Transfers do not create or destroy claimable value.
4) Claiming updates checkpoints atomically before ETH transfer (no reentrancy window).
5) Zero-balance accounts always have zero claimable revenue.

Example:
- Series has 1,000 tokens total
- Alice holds 100 tokens (10%)
- Bob holds 900 tokens (90%)

Deposit 1: 10 ETH
- cumulativeRevenuePerToken = 10 / 1000 = 0.01 ETH per token
- Alice can claim: 100 * 0.01 = 1 ETH
- Bob can claim: 900 * 0.01 = 9 ETH

Alice claims her 1 ETH
- lastClaimedPerToken[Alice] = 0.01

Deposit 2: 5 ETH
- cumulativeRevenuePerToken = 0.01 + (5 / 1000) = 0.015 ETH per token
- Alice can claim: 100 * (0.015 - 0.01) = 0.5 ETH (only new revenue)
- Bob can claim: 900 * (0.015 - 0) = 13.5 ETH (all revenue)

This proves ownership is evaluated at claim time, not deposit time.

This is essentially the same invariant set used by well-known dividend-bearing token models, adapted to ETH-native revenue and optimized for Arbitrum gas costs.

If you want, I can point to the exact accounting code paths in RevenueSeries.sol.