Revenue operations
A receipt should be traceable from its source to its final allocation.
The browser routing is complete as an accounting exercise. Delivering the same behavior with real funds requires a source of revenue, an executable collection path and transparent reconciliation.
The native-ETH collection path
The treasury reference can collect credited native-ETH creator fees from a supported escrow interface. A Pons launch would first need a reviewed fee-recipient configuration and a compatible token. Fees must be swept from the curve or hook into escrow before collection can receive them.
The treasury attempts bounded collection during redemption. A collection failure does not make existing reserve ETH unavailable. Unswept and unclaimed fees are excluded from the reserve quote.
Independent product earnings
An external product can pay actual earnings into FoldRevenueRouter. Its two-recipient split is fixed at deployment, and each recipient claims separately. It cannot withdraw treasury principal.
The browser’s 50/30/20 route requires a separate live rewards allocation and distributor. Publishing that percentage on the site does not configure the Solidity router.
Evidence for a live receipt
- Identify the revenue-generating product and the period the receipt covers.
- Publish the collection transaction and reconcile actual ETH received.
- Show the split between rewards, reserve and operations, including rounding.
- Reconcile funded rewards against settled allocations and claims.
- Record empty periods, failed collections and outstanding unswept amounts separately.
No automatic live operator
No production sweep bot, scheduled stock trade or live reward distributor is operated by this release. The manual app clock changes only the simulation. A live operational role needs defined powers, observability and a reviewed failure procedure.