Fee Flow Topology

(Deterministic Routing of Native Value)

2.2 Fee Flow Topology

This page describes how native value moves through the system during recycle execution.

All routing occurs atomically within the recycle() transaction.

No off-chain allocation exists.

---

I. Native Value Entry

When a user calls:

recycle(token) payable

Native value enters the RecyclingEngine as msg.value.

The engine does not retain discretionary custody.

Value is routed immediately through the configured Router contract.

---

II. Router Rail Split

The RecyclingEngine reads:

router()

The Router contract defines rail splits.

Typical rails include:

• Ops Rail • Provider Rail • Recycle Rail

The split is deterministic and executed within the same transaction.

If rails are misconfigured, execution reverts:

ENGINE_ROUTER_MISMATCH
ENGINE_ROUTER_ZERO_RAIL

There is no partial routing.

---

III. Recycle Rail

The recycle rail portion of native value:

• Remains within the RecyclingEngine • Increases accNativePerWeight • Becomes distributable via claim()

This is the only rail that affects weight holders.

The formula applied:

accNativePerWeight += (recycleRailWei × ACC_SCALE) / totalWeight

If totalWeight == 0, behavior is determined by contract logic (must be documented per deployment).

---

IV. Provider Rail

If configured, the provider rail:

• Transfers native value to inventory provider • Occurs immediately within transaction • Is visible in internal transfer logs

This rail does not affect ledger math.

---

V. Ops Rail

If configured, the ops rail:

• Transfers native value to designated ops address • Is visible in internal transaction logs • Is not part of distribution math

---

VI. Share Rail (Optional Cross-Chain Flow)

If configured, a portion of native may be routed to:

FeeVault (on execution chain)

From FeeVault:

• Funds may be bridged • Forwarded to Fund (Ethereum) • Enter treasury ledger

This process is separate from recycle distribution.

Recycle distribution remains local to execution chain.

---

VII. Atomicity Guarantee

All routing occurs within one transaction:

1. Units consumed

2. Rails split

3. Weight minted

4. Ledger updated

5. Events emitted

If any step fails:

Transaction reverts entirely.

No partial state mutation.

---

VIII. Verifying Rail Transfers

To verify fee routing:

1. Locate recycle transaction

2. Inspect internal transfers

3. Confirm:

   • Provider transfer

   • Ops transfer

   • Remaining recycle rail in engine

4. Confirm event:

   Recycled(...)

Internal native transfers must match rail percentages.

---

IX. Separation of Concerns

Recycle execution does not:

• Control Fund directly • Allocate treasury funds • Modify governance state

Fee routing is mechanical.

Governance is separate.

---

X. Value Flow Summary

Rail	Destination	Affects Weight	Governance Controlled
Recycle Rail	Engine	Yes	No
Provider Rail	Provider	No	No
Ops Rail	Ops Address	No	No
Share Rail	FeeVault → Fund	No	Yes (via Fund)

This table prevents confusion between recycle math and treasury flows.