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

Core concepts

Permanent retirement

When the protocol buys PLOUTO, it removes it from circulation in the same transaction. There are two ways to do that, they are not equivalent, and Plouto reports them as separate numbers.

The two mechanisms

Real burn

The token implements burn(uint256). Calling it destroys the tokens and reduces the value totalSupply() reports. Tracked as totalPloutoBurned.

Dead-address transfer

The tokens are sent to 0x000000000000000000000000000000000000dEaD, an address with no known private key. They are unspendable forever, but totalSupply() is unchanged. Tracked as totalPloutoSentToDead.

What the executor actually does

It tries a real burn first, and — critically — verifies that the burn worked before recording it as one:

solidity
function _retire(address token, uint256 amount) private returns (bool realBurn) {    if (amount == 0) return false;     uint256 supplyBefore = _totalSupply(token);    (bool ok,) = token.call(abi.encodeWithSignature("burn(uint256)", amount));    if (ok && _totalSupply(token) + amount == supplyBefore) {        totalPloutoBurned += amount;        return true;    }     // Either the token has no burn entrypoint, or it did not actually reduce    // supply. Fall back to the dead address, and never claim a supply reduction.    IERC20(token).safeTransfer(DEAD_ADDRESS, amount);    totalPloutoSentToDead += amount;    return false;}

The check is _totalSupply(token) + amount == supplyBefore — not merely "the call did not revert". A token could implement burn as a no-op that returns successfully; that would be caught here and routed to the fallback.

What PLOUTO will actually do

Pons launch tokens are OpenZeppelin ERC20Burnable. Selector extraction from a deployed Pons token confirms burn(uint256) and burnFrom(address,uint256) are present, and that there is no reachable mint.

So in practice PLOUTO retirement should be a real burn that genuinely reduces totalSupply(). A mainnet-fork test confirms this against live liquidity.

The dead-address path exists anyway, because a fallback that has never run is better than an assumption that turns out to be wrong.

Reading the figures

On the Core page you will see all four:

  • Retired by real burn — totalSupply() genuinely decreased by this amount.
  • Retired to the dead address — unspendable, but still counted in totalSupply().
  • Total retired by the protocol — the sum of those two.
  • Dead address balance (all sources) — what the dead address holds from anyone, not only from Plouto.

That last one is deliberately labelled, because anybody can send tokens to the dead address and Plouto should not take credit for it.

Verifying it yourself

Every execution emits BuybackExecuted(ethSpent, tokensRetired, phase, realBurn, minTokensOut, newBudget, executionIndex), and the realBurn flag tells you which path was taken. Verify a retirement walks through checking one on Blockscout without trusting this interface.