Pons dependency
Plouto's revenue comes from a system it does not control. This page states what that exposes, and is honest that most of it cannot be mitigated from inside the protocol.
What Plouto depends on
- The token contract
Deployed by Pons. Plouto cannot alter it, and inherits whatever it does — including whether
burn()exists.- The fee schedule
Pons sets
curveFeeBpsand the protocol/creator division. A change directly changes Plouto's revenue.- Sweep timing
Fees are unavailable until Pons sweeps them. Plouto cannot force this. See sweeps.
- The sweep operator
Post-graduation, converting hook fees may require
feeSweepOperatorto act.- The factory and escrow addresses
Immutable in Plouto's contracts. A Pons redeployment makes them stale.
- Phase semantics
If Pons adds a phase value, the executor reverts with
UnexpectedPhaserather than guessing — pausing buybacks until reviewed.
What Plouto does about it
Detection, not adaptation.
- Deployment-time verification.
Deploy.s.solcross-checksfactory.feeEscrow()before deploying anything. - Launch-time verification.
pnpm pons:preparechecks every Pons address against the factory's own getters and refuses to continue on a mismatch. - Continuous verification. The status page runs the same checks live and shows a failing badge.
- Test-time verification. The fork suite asserts all of it against live mainnet state.
- Refusal over improvisation. Unknown phase, mismatched route or disagreeing curve all revert.
Recovery, if Pons redeploys
There is a path, but it is manual and slow:
- Deploy a new
PloutoRevenueRouterpointed at the new escrow. - Ask Pons to change the creator-fee recipient, using its own timelocked mechanism:
transferCreatorFeeRecipient(address token, address newRecipient);executeCreatorFeeRecipientChange(address token); // after CREATOR_FEE_RECIPIENT_TIMELOCK- The registry cannot be repointed, so the new router would be published separately.
Staker principal is unaffected throughout. It sits in GravityStaking, which does not depend on Pons for anything except reading the token address from the registry.
What is not at risk
- Staked principal. Held by Plouto, returnable at maturity regardless of Pons state.
- Already-claimed revenue. Once in the router, it is Plouto's.
- Already-retired supply. Permanent, regardless of what Pons does next.
- The reserve balance.
Audit status
Pons V2's disclosed audit status is external and not verifiable from chain state. Consult the official Pons documentation directly rather than taking a claim about it from here.