Trading Fee Schedule

NET carries a 5% trading fee (fee-on-transfer tax), implemented in the token contract itself and keyed to a mapping of AMM pair addresses. It is the fund's load: charged on trades, never on shareholders moving their own assets.

1. Where the fee applies

The whitelist covers BondDepository, GenesisBond, Staking, Treasury, TaxCollector, InverseBond, PremiumSeller, and protocol-owned-liquidity operations. (There is no keeper exemption because there is no keeper role — see The Fund.) The 5% total is immutable — no admin can raise, lower, or remove it.

The pair mapping and whitelist are the protocol's only permissioned surface, and it is 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 genuine NET pool before accepting it. The worst a compromised key can do is map a legitimate pool, which is the setter's intended function.
• Asymmetric friction. Pair additions execute instantly (they only widen fee coverage); exemption additions sit behind a timelock, so the dangerous direction is visible and contestable before it executes.

The key is the team multisig (2-of-3 Safe recommended, hardware wallet minimum).

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 pTEAM vesting fraction v — the same on-chain clock, one source of truth, no admin setter:

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

The fee itself 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 (backing per token) that never expires and cannot be re-inflated toward management. See Management Compensation for why the schedule looks like this.

3. Why the canonical pool must be Uniswap v2

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

4. Collection and conversion

The fee accrues in NET inside the TaxCollector (collection and conversion are separated so a swap never re-enters the pool). TaxCollector.convert() — the batch swap of accrued NET to USDG on the canonical pool — is permissionless: anyone may call it, and every bound is enforced on-chain (out-of-bounds calls revert):

• Slippage: maximum deviation of 100 bps from the same 1-hour TWAP the Distributor uses (TAX_SWAP_MAX_DEV_BPS, default tunable before deploy).
• Clip size: at most 50 bps of the pool's NET reserves per swap (TAX_SWAP_MAX_CLIP_BPS, default tunable before deploy), keeping clips small relative to depth.

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

5. The unmapped-pool bypass, stated plainly

Uniswap v3, v4, and UniswapX are live on Robinhood Chain, and anyone can create an unmapped NET 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 — Uniswap v3 NET/USDG (all 4 fee tiers), v3 NET/WETH (all 4 fee tiers), and the v2 NET/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: pool-creation events and order flow are watched, and discovered venues are added to the mapping instantly via the add-only key.
3. The structural defense is liquidity depth, not whack-a-mole: fund-owned depth on the canonical v2 pool keeps it the best-execution venue, so organic flow concentrates where the fee applies.

The full risk statement lives in Risk Factors.