The Plouto Reserve

Ten percent of every routed epoch accrues to the PloutoReserve contract. It exists so the protocol can pay for its own upkeep out of revenue rather than out of anyone's token supply.

What it is for

Stated intent, in rough priority order:

1. Security — audits, reviews, bug bounties.
2. Infrastructure — RPC, indexing, hosting, monitoring.
3. Automation — funding the buyback and routing keepers.
4. Integrations — work that makes PLOUTO usable in more places.
5. Protocol-owned liquidity — liquidity the protocol itself holds.

It is not a trading account and not a discretionary fund. Every movement records a purpose string on chain, so the stated reason for any outflow is permanent and public.

How money leaves

There is no single-transaction withdrawal. The path is deliberately slow:

1. Propose

A holder of GOVERNOR_ROLE calls proposeWithdrawal(token, recipient, amount, purpose). An empty purpose reverts with EmptyPurpose(). The proposal records a readyAt timestamp.

2. Wait

TIMELOCK_DELAY is 2 days. Executing early reverts with TimelockNotElapsed.

3. Execute — or expire

After the delay, a governor may execute. EXECUTION_WINDOW is 14 days; past that the proposal reverts with ProposalExpired and must be re-proposed.

Veto, at any point

A holder of GUARDIAN_ROLE can call cancelWithdrawal(id, reason) during the window. The reason is recorded on chain.

The governor and guardian are intended to be different signers. If one entity holds both, the veto is decorative — this is stated as an operational requirement in multisig and timelock.

Inflows are classified

The reserve distinguishes protocol revenue from unsolicited ETH:

function depositRevenue() external payable {    if (msg.sender != revenueRouter) revert NotRouter();    if (msg.value == 0) revert ZeroAmount();    totalRevenueReceived += msg.value;    _deposits.push(Deposit(uint64(block.timestamp), msg.value, true, msg.sender));    emit RevenueDeposited(msg.sender, msg.value, address(this).balance);} receive() external payable {    totalDonationsReceived += msg.value;    _deposits.push(Deposit(uint64(block.timestamp), msg.value, false, msg.sender));    emit DonationReceived(msg.sender, msg.value, address(this).balance);}

The isProtocolRevenue flag on every deposit means the history can always be separated, and a large donation can never inflate the "revenue received" figure.

What it cannot do

• It cannot buy or sell PLOUTO. It has no trading logic at all.
• It cannot pay stakers. That is the staking contract's 30%, and the two never mix.
• It cannot be swept by an owner. There is no rescue() or withdrawAll().
• It cannot execute a proposal that exceeds its balance — that reverts with InsufficientBalance rather than partially filling.

Full transparency

The reserve page shows the current balance, lifetime inflows split by classification, every deposit, and every proposal — including ones that were cancelled or expired. Nothing is filtered out for looking bad.