Skip to content
Protocol contracts not yet configured for this build
Enter app

Security

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 curveFeeBps and 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 feeSweepOperator to 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 UnexpectedPhase rather than guessing — pausing buybacks until reviewed.

What Plouto does about it

Detection, not adaptation.

  1. Deployment-time verification. Deploy.s.sol cross-checks factory.feeEscrow() before deploying anything.
  2. Launch-time verification. pnpm pons:prepare checks every Pons address against the factory's own getters and refuses to continue on a mismatch.
  3. Continuous verification. The status page runs the same checks live and shows a failing badge.
  4. Test-time verification. The fork suite asserts all of it against live mainnet state.
  5. 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:

  1. Deploy a new PloutoRevenueRouter pointed at the new escrow.
  2. Ask Pons to change the creator-fee recipient, using its own timelocked mechanism:
solidity
transferCreatorFeeRecipient(address token, address newRecipient);executeCreatorFeeRecipientChange(address token);   // after CREATOR_FEE_RECIPIENT_TIMELOCK
  1. 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.