Fund Documents · 03 of 08

Trading Fee Schedule

The fund's load: charged on trades, never on shareholders moving their own assets.

RPT carries a 5% trading fee, implemented in the token contract itself as a fee-on-transfer keyed to a mapping of AMM pair addresses.

1. Where the fee applies¶

The whitelist covers the BondDepository, GenesisBond, Staking, Treasury, TaxCollector, InverseBond, PremiumSeller and fund-owned-liquidity operations. There is no keeper exemption because there is no keeper role. The 5% total is immutable: no key can raise, lower or remove it.

The pair mapping and whitelist are the protocol's only permissioned surface, constrained three ways:

• Add-only. No removal functions exist in code. Pairs and exemptions are permanent; the key can never narrow the fee.
• Factory-validated. The setter verifies on-chain, against the canonical Uniswap v2/v3/v4 factories, that a submitted address is a real RPT pool before accepting it. The worst a compromised key can do is map a legitimate pool, which is the setter's intended job.
• Asymmetric friction. Pair additions execute instantly, since they only widen fee coverage. Exemption additions sit behind a timelock, so the dangerous direction is visible and contestable before it executes.

2. The decay schedule: 4%/1% → 0%/5% in 30 days¶

The fee is split between management and the treasury as a pure function of the management vesting fraction v, the same on-chain clock, one source of truth, no setter:

teamBps     = 400 × (1 − v)      v = elapsed / 30d, clamped to [0, 1]
treasuryBps = 500 − teamBps       total is always exactly 500 bps

The fee only exists from finalize() onward, so the decay begins with the first taxable trade. After day 30 the trading fee is entirely a treasury inflow: a structural tailwind to NAV that never expires and cannot be re-inflated toward management. See Management Compensation.

3. Why the canonical pool must be Uniswap v2¶

The canonical RPT/USDG pool, seeded at finalize(), lives on the Uniswap v2 deployment on Robinhood Chain. This is a hard requirement: the v3 router's exact-output and callback flow reverts on fee-on-transfer tokens, while v2's swapExactTokensForTokensSupportingFeeOnTransferTokens path handles them. The fee is enforced at the token level rather than as a v4 hook on purpose: token-level enforcement works on every venue the fund maps, not only hooked pools.

4. Collection and conversion¶

The fee accrues in RPT inside the TaxCollector; collection and conversion are separated so a swap never re-enters the pool. TaxCollector.convert(), the batch swap of accrued RPT to USDG on the canonical pool, is permissionless, with every bound enforced on-chain:

• Slippage: at most 100 bps from the same 1-hour TWAP the Distributor uses.
• Clip size: at most 50 bps of the pool's RPT reserves per swap.

Proceeds split per the table above; the treasury share is deposited to Morpho per treasury policy, the management share goes to the management Safe.

5. The unmapped-pool bypass, stated plainly¶

Uniswap v3, v4 and UniswapX are live on Robinhood Chain, and anyone can create an unmapped RPT pool that dodges the fee. The fund treats this as a managed, disclosed risk rather than a solved problem:

1. Pre-mapped at deploy. The deploy script maps CREATE2-predicted pool addresses computed on-chain from the canonical factories: v3 RPT/USDG and RPT/WETH across all fee tiers, and the v2 RPT/WETH pair. Those pools are taxed from the moment anyone creates them.
2. v4 cannot be pre-mapped (its singleton uses pool IDs, not addresses), so v4 and UniswapX remain a standing monitoring duty. Discovered venues are added instantly through the add-only key.
3. The structural defense is depth. Fund-owned depth on the canonical v2 pool keeps it the best-execution venue, so organic flow concentrates where the fee applies.