The payroll,
with the panel off.
Every figure below is read from the contract on a poll, or summed across a full scan of the floor. Nothing is estimated. Where a number could not be read it prints an em-dash, and where a number rests on an assumption the assumption is on screen next to it.
Where a swap fee ends up
Every $PONSTRO swap pays a fee. A harvest claims it and splits it three ways, in equal parts: one leg buys $PONS and deposits it in the NFT contract for the monsters, one buys $PONSTRO and burns it, and one mints a full-range liquidity position and hands it to whoever is on overtime. There is no fourth destination and no dev leg. The burn and liquidity legs are each wrapped in try/catch so a failure there can never roll back the reward leg — that exact coupling is what broke harvests in the earlier project.
- $PONS LEG—
- BURN LEG—
- LIQUIDITY LEG—
Each leg is settable behind the timelock and bounded 20% – 50%, and the three must still sum to the whole fee — so raising one is always taking from another, and there is no destination outside these three. An earlier project froze its split as a constant and then could not fix it, which is most of why this board exists.
No harvest counter exists on the contracts, and inventing one from an unindexed log would be a guess. The vault figures above are the cumulative effect of every harvest so far.
Credited plus unbanked. What a harvest has delivered and nobody has taken out yet.
Still counting the floor — partial.
Who the next deposit goes to
Everything burned, by which burn
- FEEDING—
- EVERYTHING ELSE—
Burn per round, against what is left
Half-life cannot be computed until the burn per round and the outstanding supply are both known. Both are shown above; whichever is an em-dash is the one missing.
Feeding only. Mint burns are one-off and excluded, and the burner leg — which spends swap fees buying $PONSTRO to burn — is excluded too, because this page cannot read it. Both make the real rate faster, so this figure is a floor, not a forecast. The one thing assumed is that the next round looks like the last one: — monsters were actually fed inside the last window, out of — that have ever been fed at all. When feeding drops the burn slows and the redistribution on the shift board speeds up.
Anyone can turn the crank
Nothing here waits on an operator. The fee harvest is callable by anyone through the relay, and notifyReward() — the call that credits $PONS already sitting in the vault to the monsters, by weight — is callable by anyone, always, with no arguments. Whoever presses it pays gas and receives nothing extra. That is what makes it safe to leave open.
In the contract, not yet in the accumulator. Every monster's pending balance understates its earnings by its share of this.
No arguments. No permissions. No reward for the caller.
PonstroNFT
The pinned selector, never a guessed one.
harvest(minRewardOut, minBurnOut) — also open to anyone, but it takes slippage bounds, so it belongs in a script rather than behind a button.
What can be changed, and how slowly
Every number on this board moves through the same gate: propose, wait 1d 0h, then execute with the identical value, and only ever inside walls that were compiled in and can never move. There is no emergency path and no admin withdrawal.
| Parameter | Contract | Gate | Now | Hard min | Hard max | Queued change |
|---|---|---|---|---|---|---|
FEED COST What one feed burns, flat. SPEC-V4 §1.1 deleted the cap that used to sit on top of this — it compared $PONSTRO against a reward-token balance, two different assets at two different prices, and floored every feed at MIN_FEED_COST forever. Raising this burns supply faster and prices out small holders; lowering it makes tenure cheap to buy. The floor is strictly above zero on purpose: if feeding is free, nobody ever lapses and the whole mechanic stops firing. | PonstroNFT | TIMELOCKED 1d 0h wait, then the identical value. | — | 100 $PONSTRO | 100.0K $PONSTRO | — |
MINT PRICE What hiring one monster costs, in ETH. THE ONLY IMMEDIATE NUMERIC SETTER on the contract: it is a peg to $10, and a peg cannot track the ETH price through a 24-hour timelock. It is fenced three other ways instead — absolute bounds that hold the peg from roughly $500 to $100,000 an ETH, a maximum 20% move per step, and a 12h 0m cooldown between steps. The ETH it collects is not a treasury; the only function that can move it sends all of it to the burner. | PonstroNFT | IMMEDIATE Rate limited: 20% max per step, once every 12h 0m. | — | 0.0001 ETH | 0.02 ETH | — |
FEED WINDOW THE ONE CLOCK. Feed inside it and your streak is safe; every whole window past the first one costs a level. Shorter means the ladder is harder to hold and more weight moves to the monsters that do hold it. | PonstroNFT | TIMELOCKED 1d 0h wait, then the identical value. | — | 6h 0m | 7d 0h | — |
POKE BOUNTY What a stranger is paid for settling somebody else's lapsed monster, out of what the settle releases. The accuracy of totalWeight depends on this being worth calling — at zero, nobody clears the backlog and everyone still feeding is paid slightly less than they earned. | PonstroNFT | TIMELOCKED 1d 0h wait, then the identical value. | — | 0% | 5% | — |
WALLET LIMIT Mints per wallet. A fairness signal, not a security control — it is bypassable with more wallets and the contract's own natspec says so. It is timelocked anyway, and cannot be raised after sunset, because it is the other half of leaving setMintOpen immediate: a cap the owner could lift at will would let the owner open the mint, take the rest of the supply and hold most of the vault's weight. | PonstroNFT | TIMELOCKED 1d 0h wait, then the identical value. | — | 1 | 100 | — |
REWARD LEG SPLIT Share of each harvest that buys $PONS for the monsters; the other two legs buy $PONSTRO and burn it, and mint liquidity for the overtime crew. All three are bounded and must still sum to the whole fee, so raising one is always taking from another — there is no destination outside the three. An earlier design froze this as a constant and then could not fix it, which is most of why this page exists. | PonstroFeeRouter | TIMELOCKED 1d 0h wait, then the identical value. | — | 20% | 50% | — |
Every bound above is compiled in and checked twice: once when a change is proposed and again when it is executed.
Doors that used to survive the sunset
An adversarial review found owner paths that outlived sunsetSetters() — the switch this site tells people is what makes the project safe. The 3 that still exist are listed with what each could have done, because a page that only shows the current state is asking to be taken on trust for the part that changed. One more is missing from this list because it is not merely closed: the setter was deleted along with the mechanism it configured, which is a burn inside our own marketplace now.
Immediately point the reward leg at a venue that skims up to the maximum slippage on every harvest, forever. It routes money, so it is economic, so it waits out the timelock now.
Redirect the buy-and-burn leg. Closed in the previous pass, and the mint-proceeds sweep is hard-wired to whatever this points at, so it stays closed.
Deploy with an ordinary wallet in that slot, so every 'burned' mint and feed landed in it. It is now validated in the constructor against the one canonical dead address and the deployment reverts otherwise. 'The mint is burned' is a property of the code, not a promise about a deploy argument.
Immediate, no timelock
Switches and pointers — a gate, an artwork URL set at deployment, a slot that can only be written once, and who is allowed to do work anybody can already do. The one IMMEDIATE NUMBER is the mint price, and it is in the table above rather than hidden down here: it is fenced by absolute bounds, a 20% maximum move per step and a 12h 0m cooldown between steps, because a peg to a dollar figure cannot track the ETH price through a 24-hour wait.
A gate, not a price. It can stop hiring and it can restart it; it cannot move anybody's money. The drain it would otherwise enable — open the mint, take the rest of the supply, hold most of the vault's weight — is closed on the other side by walletLimit, which IS timelocked and cannot be raised after sunset.
Artwork location, set at deployment. There is no setter at all, so there is nothing here to timelock.
Set once at wiring time and never again — the mint runs before the token exists, so the slot has to be fillable later. A second write is impossible, so a timelock would guard nothing.
Who may call harvest. Bounded by the relay that makes harvesting permissionless anyway, so the worst an owner can do here is fail to stop somebody else doing the work.
Not settable by anyone
- There is no admin withdrawal of user funds anywhere in the codebase. Not behind a timelock, not behind a bound — the function does not exist.
- The mint takes ETH and holds it as mintProceedsWei. The only function that can move it is sweepMintProceeds(), which anybody may call, which takes no destination argument, and which can only reach the burner — where it buys $PONSTRO and burns it.
- Feeding burns $PONSTRO to 0x…dEaD directly. It is a burn, not a deposit: there is no withdrawal because there was never a balance.
- rescueToken() reverts for the reward token and for $PONSTRO. It can only move genuinely stray tokens.
- renounceOwnership() is disabled and reverts, so ownership cannot be dropped into a hole with the setters still live.
- Bounds are checked at propose AND at execute, and execute must be handed the same value that was proposed.
- sunsetSetters() is one-way. After it, every propose and every execute reverts forever.