The Pons creator-fee path

A fee travels through four distinct states before Plouto can spend it. Conflating any two of them produces a misleading number, so the protocol and the interface track all four separately.

The four states

1. Accrued, unswept

Sitting inside the Pons bonding curve or the meme hook. Owed in principle, but not credited to any recipient. Plouto cannot read this as a balance.

2. Credited in escrow

Pons has swept it into the Pons Fee Escrow. Readable as feeEscrow.balanceOf(revenueRouter). Owed to Plouto, not yet held by Plouto.

3. Claimed

Plouto called claim() and the ETH is now in the Revenue Router. Recorded in totalRevenueClaimed. This is the only figure that means "fees earned".

4. Allocated

Split 60/30/10 and forwarded. Recorded in totalRevenueRouted.

Why state 1 is shown as unknown

On the Core page, stage one displays an em dash rather than a number. That is not an oversight.

Unswept fees live inside Pons contracts in a form that is not a per-recipient balance. There is no view function Plouto can call to learn "how much is owed to me but not yet swept". Any number displayed there would be a guess, and a guess presented next to four real figures reads as a fifth real figure.

Pull, not push

Pons does not send fees to the recipient. The recipient must call claim():

interface IPonsV2FeeEscrow {    function claim() external returns (uint256 amount);    function claim(uint256 amount) external returns (uint256);    function balanceOf(address recipient) external view returns (uint256);}

Plouto uses the no-argument form, which claims the entire credit. It is called by claimPonsFees() on the router, and it is permissionless — anyone can trigger it.

A fork test credits the real escrow on forked mainnet state, calls claim(), and confirms the exact amount arrives.

The delay nobody controls

Between states 1 and 2 there is a wait, and Plouto has no influence over its length. Pons sweeps when Pons sweeps. Post-graduation, converting hook fees may additionally require the Pons feeSweepOperator to act.

This is a genuine, unmitigable dependency. It is listed in sweeps and in the threat model, and the only thing Plouto does about it is refuse to misreport it.

What the router credits

Only the measured ETH balance delta. Never the value claim() returns.

uint256 balanceBefore = address(this).balance;uint256 reported = feeEscrow.claim();received = address(this).balance - balanceBefore;

reported is emitted in the event for observability. received drives the accounting. A test drives an escrow that deliberately over-reports and confirms only the real amount is credited.

Reading it in the interface

The Core page lays the states out in order, labelled by number, with the honest gap at the top. The keeper script pnpm keeper:route prints the same four categories before it does anything, so an operator sees the same distinction from the command line.