B. Illustrative future fee waterfall

This is a proposed design for a future deployment. It applies only if implemented, funded, and adopted through published governance and participant terms. It does not describe a current Protocol v1.1.0 fee, contributor right, reserve, guarantee, or insurance arrangement.

Let F_in be revenue actually received by the proposed network budget during an epoch: the proposed network rake, separate routing or service fees, and any other expressly designated revenue. Gross Pool fees that remain with Pools are not included.

Revenue assets must be classified as:

• E_cash: assets eligible for a stated cash-denominated use under the adopted policy; or
• E_kind: in-kind vouchers or other assets that are not treated as cash-convertible.

Any conversion policy would need asset and venue allowlists, responsible authorities, price sources, slippage limits, reporting, and applicable legal controls.

A proposed waterfall could apply received revenue in this order:

1. Covered reserve target: fund an adopted reserve or insurance target based only on defined covered exposure, eligible assets, exclusions, and claim rules.
2. Core operations: fund a disclosed, capped operating budget.
3. Liquidity mandates: fund approved, separately governed Pool or routing programs.
4. Remaining budget: allocate any remaining amount among operations, liquidity programs, and an additional buffer under published caps.

A reserve target is not itself a guarantee. Any insurance or guarantee must identify the obligated party, covered event, funding, cap, exclusions, duration, evidence, claim process, and loss allocation.

Guardrail: Waterfall allocations are intended for adopted coverage, operations, and liquidity services. They must not be framed or executed as price-support operations.

Under the proposed model, any proposed CLC governance tokens acquired through a separately enabled external-liquidity program would be retired or placed in a disclosed non-voting sink. This mechanism is not deployed.