At launch, mining revenue is directed through ResonanceRouter into the Resonance revenue stream. The router is ownerless and permanently paired with one Resonance; the Mine's destination can be changed by the FundController owner.

Mine to Router

Every nonzero mining payment sends its remainder to the Mine's current revenueRouter, after recording outgoing-miner, creator and protocol claims. FundController.setRevenueRouter(address) can redirect future payments to another deployed contract. Only the presence of code is checked; compatible routing behavior is not enforced.

The change does not migrate old balances, allocations, strategies or rewards. FundController remains bound to its original Resonance. A replacement destination may use different rules or strand or divert the revenue. The rest of this page describes the launch-time routing setup.

Router to Resonance

The router is permanently paired with one Resonance and USDG. Anyone can call route() to forward its balance, subject to three checks:

1. There must be live allocations. If total live allocation weight is zero, route() reverts and the balance waits. This prevents a stream from starting with nobody to receive it.
2. The balance must be at least seven days of raw units. A stream is a whole number of raw USDG units per second over 604,800 seconds, so anything smaller would round to a zero rate. Below that, the router emits RevenueHeld and keeps the balance.
3. The balance must be at least what the current stream still owes. Restarting a stream folds the remaining amount into the new one, so a new notification must not be smaller than remainingRevenue(). Below that, the router again holds and retries later.

A qualifying attempt approves the exact amount, calls Resonance.notifyRevenue, transfers the USDG and emits RevenueRouted, all atomically. A downstream failure leaves the balance in the router, retryable. The app's auction fills through the Periphery and its Operations batch (OperationsPeriphery.run) try route() when these checks pass; the function is public so anyone, including a bot, can do it.

The revenue stream

notifyRevenue(amount) is callable only by the bound router. It checkpoints the global accumulator through the earlier of now and the current period's end, then starts a new seven-day period whose rate is:

rate = floor((amount + remaining of the previous period + saved remainder) / 604,800)

The division remainder is saved and included in the next qualifying notification. If no further funding qualifies, it remains pending. Separate accumulator and account conversions also round down. The accumulator is scaled by 1e36 per raw unit of allocation weight, and a lifetime cap of (2^256 - 1) / 1e36 raw USDG bounds what the Resonance will ever accept.

Every live strategy accrues its share of the stream continuously:

strategy share per second = rate * strategyWeight / totalSignalWeight

Weights change whenever allocations are added or removed; the accumulator is checkpointed at the old weight first, so no strategy can claim revenue that accrued before it had weight, and a strategy added later starts at the current index with nothing owed.

Distributing to a strategy

distributeRevenue(strategy) is permissionless. It checkpoints one strategy and transfers its accrued USDG to that strategy's own address, rounding down to whole raw units. It works for killed strategies too: a kill checkpoints the strategy under its full prior weight and preserves what it had earned. A strategy that has been distributed to holds that USDG until its auction is filled; earnedRevenue(strategy) shows what has accrued but not yet been distributed.

A running stream does not pause if live allocations fall to zero. Revenue elapsed with zero live weight becomes unallocated surplus and cannot be claimed by a strategy that receives allocations later.

A strategy's auction sells its complete USDG balance, and Auction.buy first pulls any undistributed revenue for itself, so buyers never need to distribute manually.

What can stall

• No allocations. With zero live allocation the router holds everything. Once a permitted participant allocates to a live strategy, routing can resume if the funding thresholds and lifetime cap also allow it.
• Small balances. Less than seven days of raw units, or less than the current stream's remainder, is held until more revenue arrives.
• A killed last strategy. The last live strategy cannot be killed, so there is always somewhere for revenue to go.

The original router has no rescue function. A lifetime funding cap, incompatible token, or abandoned allocation can leave balances pending indefinitely. Redirecting the Mine does not recover those balances. See creator authority for this trust boundary.