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

Pons V2 integration

Creator-fee recipient

The single most consequential parameter of the launch. It decides where every fee Plouto will ever earn is sent, and it is set at the moment the token is created.

The constraint

Pons requires a creatorFeeRecipient address in the launch parameters. That address must already exist as a contract, because fees will be credited to it from the first trade.

Therefore the deployment order is forced:

  1. Deploy PloutoRegistry.
  2. Deploy GravityStaking.
  3. Deploy BuybackExecutor.
  4. Deploy PloutoReserve.
  5. Deploy PloutoRevenueRouter — this address is the answer.
  6. Wire the four one-shot router references and call wireProtocol.
  7. Launch PLOUTO with creatorFeeRecipient set to the router.
  8. Call setPloutoTokenOnce(token, curve).

Between steps 5 and 8 the protocol exists but has no token.

What the app does in that window

Nothing is faked. The registry reports initialized() == false, and the interface:

  • Shows Protocol contracts live · PLOUTO launch pending in the status strip.
  • Disables every staking control.
  • Renders protocol figures as genuine zeroes or em dashes.
  • Marks PLOUTO registered as a failing health check on the status page.

The router can still claim fees during this window; it simply cannot route them, because the buyback destination has no token to buy.

Getting it wrong is unrecoverable-ish

If the wrong address is registered as the creator-fee recipient, every fee goes there instead. Pons does provide a timelocked recipient change:

solidity
function transferCreatorFeeRecipient(address token, address newRecipient) external;function executeCreatorFeeRecipientChange(address token) external;function cancelCreatorFeeRecipientChange(address token) external;

subject to CREATOR_FEE_RECIPIENT_TIMELOCK and CREATOR_FEE_RECIPIENT_EXECUTION_WINDOW. So it is recoverable, but slowly and publicly, and any fees earned in the interim are gone.

The checks that prevent it

Three independent layers:

prepare-pons-launch.ts

Verifies PLOUTO_REVENUE_ROUTER has bytecode on chain and that its feeEscrow() matches the official Pons escrow. Refuses to build launch calldata otherwise.

finalize-plouto.ts

Reads the factory record after launch and aborts if record.creatorFeeRecipient is not the registry's router.

PloutoRegistry.setPloutoTokenOnce

Reverts with FeeRecipientMismatch(expected, actual) on chain. Even if both scripts were bypassed, the registry will not register a token whose fees go elsewhere.

Publishing it

Once deployed, the Revenue Router address will be published in contract addresses and on the status page, where it is labelled explicitly as the Pons creator-fee recipient.