EMPLOYEE HANDBOOK

How it works,
with the numbers.

Every mechanic on this page is a statement about deployed bytecode. Where there is arithmetic, this page runs the same function the contract runs rather than repeating a result. There are no projected returns here, and there will not be any.

SECTOR 00

THE GAME, IN ONE PARAGRAPH

There are 1,000 monsters and there will never be more. Every $PONSTRO swap is charged 3.00%, of which 2.70%reaches this project's fee router — two different numbers, and this site will not merge them. Anybody can harvest what the router holds. One leg of it buys $PONS — Pons, the launchpad's own token on this chain — and deposits it in the NFT contract; another buys $PONSTRO and destroys it.

The $PONS is divided between monsters by weight, and your weight is your streak. Feed today: +1. Miss a day: −1. A monster on a streak of one carries 10,000; one that has kept it up for 10 days carries ten times that. Let it fall all the way over and it is on 1,000; a monster that has never eaten at all is on 100.

That is a spread of 1,000x from an abandoned intern to a maxed streak, and it is the whole game. There is no separate penalty taken at claim time: the weight IS the penalty, it lives in the denominator, and a monster that stops eating loses share to everybody else automatically and exactly. Rewards belong to the token id, not to your wallet — sell the monster and the unclaimed $PONS goes with it, so claim before you list.

INTERN· 0.01x

ON THE CLOCK· 1.00x – 10.00x

QUIET QUITTING· 0.10x

SECTOR 01

WHERE THE $PONS COMES FROM

PERMISSIONLESS HARVEST

$PONSTRO was launched with a creator fee that accrues into an escrow. The fee router is the registered recipient. Anybody can call the harvest — it is not gated on us existing — and each cycle the router claims what has accrued and splits it three ways.

REWARD · 33.34%

BURN · 33.33%

LIQUIDITY · 33.33%

HOW FAR THAT SPLIT CAN EVER TRAVEL

0%20%33.34% now50%100%

LEG ONE

BUY $PONS

Buys $PONS on a Uniswap V3 pool and sends it straight into the NFT contract, which folds it into the accumulator and credits it to token ids by weight. A permissionless caller cannot be trusted to pick its own minOut, so a Chainlink feed sets the floor and the caller's own figure may only tighten it. That pool charges 0.30% to its own liquidity providers on the way in, the same friction any buyer of anything pays — which is 0.10% measured against the whole fee. It is a cost on this one swap, not a fourth leg.

LEG TWO

BUY AND BURN

Buys $PONSTRO in its own pool and sends every unit to 0x000000000000000000000000000000000000dEaD. If this leg fails — a broken venue, a stalled pool — it is caught rather than reverting the whole cycle: the reward leg still settles, the ETH is kept for the next cycle, and the failure is published on-chain as a counter anyone can read.

LEG THREE

MINT LIQUIDITY

Splits itself in half: 50% buys $PONSTRO and the rest stays as ETH, and the pair is minted as a full-range position. The position is credited to whoever is on overtime, and it is theirs — they can clock out, unwind it and sell both sides. So this leg is an emission, not a moat: the pool is deeper while shifts are running and thinner again as the crew leaves.

There is a gap between a harvest landing and the $PONS being folded into the accumulator. During it, every monster card understates what its monster earned. The site shows that amount separately as unbanked $PONS rather than folding it into what you can claim, because folding it in would promise money claim() will not transfer.

What can change, and what it is trapped inside

SETTING	CAN ONLY EVER BE	HOW IT MOVES
Each router leg	20.00% – 50.00%	24h timelock, and all 3 must still sum to 100%
Feed cost ($PONSTRO)	100 – 100.0K	24h timelock
Mint price (ETH)	0.0001 ETH – 0.02 ETH	immediate, max 20% per step, once per 12h
Feed window	6h – 7d	24h timelock
Mints per wallet	1 – 100	24h timelock
Poke bounty	0% – 5% of what a settle frees	24h timelock
Marketplace burn	0% – 10%	24h timelock

EVERY ECONOMIC CHANGE IS ANNOUNCED 24 HOURS AHEAD

A setter proposes; the change only executes after the delay, and it must land inside the bounds beside it. The bounds are constants — a proposal outside them does not wait, it reverts. So the worst governance can do is walk a number to the wall you can read here, in public, a day before it happens.

THE SPLIT CANNOT GROW A FOURTH DESTINATION

Each of the 3 legs is bounded 20.00% to 50.00%, and the three must sum to exactly 100%. A proposal that starved one leg to fund something else does not wait out the timelock — it reverts. There is no dev leg to cap, no dev wallet to point one at, and no setter anywhere in the router that takes an address.

SUNSETSETTERS() ENDS ALL OF IT, PERMANENTLY

One call, one way, no undo. After it, every propose and every execute reverts and the parameters are frozen where they stand — the three legs included. It is the only governance action that cannot be reversed, and that is the point of it.

THERE IS NO ADMIN WITHDRAWAL FUNCTION

Not behind the timelock, not behind a bound, not for “emergencies”. There is no function anywhere in this codebase that moves a holder’s $PONS, a monster, a locked overtime position, or the vault to an owner address. The mint’s ETH has exactly one exit — sweepMintProceeds(), which anyone may call and which can only reach the burner.

SECTOR 02

WHAT FEEDING COSTS

HIRE A MONSTER0.004 ETHETH, pegged to $10. mint() is the only payable entry point on the contract; every other call carries zero.

FEED A MONSTER250$PONSTRO, burned, per monster per feed. Flat — there is no cap and no min() — with a hard floor of 100.

MINTS PER WALLET10Bypassable with more wallets, and we are saying so rather than calling it security.

Both of those end at 0x000000000000000000000000000000000000dEaD — not at a treasury — but they get there differently and the difference is worth knowing. A FEED burns $PONSTRO directly, in the same transaction. A HIRE takes ETH, which sits in the NFT contract as mintProceedsWei until anybody at all calls sweepMintProceeds(), which sends the entire balance to the burner to buy $PONSTRO and burn it. That function takes no destination and no amount, so there is no owner path and no partial withdrawal. It is also why there is no withdraw() to argue about: the function does not exist.

Feeding does two things. It adds one to the streak, capped at 10 — so weight climbs by 10,000 every time until the top rung. And it stamps lastFedAt with the current block time, which restarts the window.

The cost is per monster and it is flat. feedCostFor(tokenIds) charges feedCost times the number of ids, and nothing else. There USED to be a cap on top of it — the lesser of feedCost and a percentage of that monster's own pending — and it was removed because the two sides of that comparison were denominated in different assets at different prices, which made it meaningless and floored every feed at 100 regardless. Making it work would have needed an on-chain price of the reward token in $PONSTRO, which is a new dependency and a new manipulation surface: a manipulable oracle is a manipulable feed price.

The floor stays, and it is the game. A feed has to cost clearly less than the streak level it buys, or nobody rationally feeds; and clearly more than nothing, or nobody ever lapses, no streak ever falls, and the whole mechanic stops firing. This site publishes the live ratio — what a feed costs against what a monster earns in a day — precisely so that calibration is falsifiable in public.

Ids must be unique. A duplicated id used to buy one streak level per array entry, so ten repeats bought the top of the ladder in a single transaction and a newcomer reached parity with a ten-day incumbent instantly. feed now reverts DuplicateTokenId, and a monster may gain at most one level per window across separate transactions too, not merely within one array.

Feeding also records fedTotal, a permanent lifetime figure that never decreases. It is tenure. It does not affect the payout; it is the number the shift board ranks by.

SECTOR 03

THE STREAK LADDER

10.00x AT THE TOP

Your weight is your streak. Feed inside the window and the streak goes up one, to a maximum of 10. Miss a whole window past the first and it comes down one. Weight is streak × 10,000, so the ladder runs from 1.00x to 10.00x and there is nothing else to it.

There is no partial decay. A level is owed or it is not. That is what makes the mechanic explainable, and it is why the picture below is a set of steps rather than a curve — a monster cannot sit between two rungs.

The grace is one full window. levelsOwed is (now − lastFedAt) / feedWindow − 1, floored at zero. The subtraction is deliberate: feeding once a window never costs a level even if you drift by hours. Feeding inside the window is always safe.

Never fed — 0.01x
Streak broken — 0.10x
On a streak — 1.00x per level
Maxed at 10 — 10.00x

Bars are on a square-root scale, not a linear one: on a linear axis the intern rung would be half a pixel tall and indistinguishable from the broken-streak rung ten times above it. The two ends really are 1,000x apart. The window is settable behind the timelock; the ladder is not — every value on it is a compiled constant.

Every rung, with the weight the contract actually uses

RUNG	WEIGHT	MULTIPLIER	WHAT IT MEANS
NEVER FED	100	0.01x	An intern. Has never eaten and does not know it.
STREAK BROKEN	1,000	0.10x	Has eaten before. Missed enough windows to fall all the way off.
DAY 1 OF 10	10,000	1.00x	One feed in. The ladder starts here.
DAY 2 OF 10	20,000	2.00x	Two days running.
DAY 3 OF 10	30,000	3.00x	Three days running.
DAY 4 OF 10	40,000	4.00x	Four days running.
DAY 5 OF 10	50,000	5.00x	Halfway up.
DAY 6 OF 10	60,000	6.00x	Six days running.
DAY 7 OF 10	70,000	7.00x	Seven days running.
DAY 8 OF 10	80,000	8.00x	Eight days running.
DAY 9 OF 10	90,000	9.00x	One short of the top.
DAY 10 OF 10	100,000	10.00x	Maxed. 1,000x the weight of an intern.

Every figure is read from the same table the roster card and the mock use, so nothing here can drift from what a monster is actually paid. One feed inside the 24h window moves you up one rung; one whole missed window past the first moves you down one. Rung 0 and the intern rung are DIFFERENT: a broken streak has eaten before and sits at 0.10x, an intern never started and sits at 0.01x.

One monster on a streak of 6, then ignored

WINDOWS ELAPSED	LEVELS OWED	EFFECTIVE STREAK	WEIGHT	MULTIPLIER
just fed	0	6	60,000	6.00x
1 window	0	6	60,000	6.00x
2 windows	1	5	50,000	5.00x
3 windows	2	4	40,000	4.00x
5 windows	4	2	20,000	2.00x
8 windows	7	0	1,000	0.10x

Note row two: a whole window has passed and NOTHING is owed. That is the grace, and it is why a daily feeder never loses a level to a few hours of drift. Computed at page render with the same arithmetic levelsOwed and weightOf use, at the launch window (24h).

NOTHING IS TAKEN AT CLAIM TIME

Earlier versions of this game cut your payout when you claimed late. That is gone. The streak already moves weight and weight already lives in the denominator, so a monster that stops eating loses share automatically — a second mechanism doing the same job was redundant and carried four separate ways to get it wrong. What pending() shows is what claim() pays.

BROKEN IS NOT THE SAME AS NEVER

A monster that fed once and then fell all the way off sits at 0.10x. A monster that has NEVER eaten sits at 0.01x — ten times lower. Those are two different rungs for two different histories, and the first feed of an intern is a hundredfold promotion.

CLAIM, THEN FEED

The one-transaction convenience runs in that order deliberately: what you are paid is banked at the streak the monster ACTUALLY held, before the feed raises it. Feeding first would pay a monster that had drifted to 0.10x its whole accrual at 10.00x, which makes lapsing free and collapses the mechanic.

SECTOR 03B

POKE — ANYBODY CAN SETTLE ANYBODY

1% BOUNTY

Here is the one honest complication in the model. totalWeight is the sum of every monster's stored streak, and a stored streak only falls when somebody touches the token. The clock cannot write to storage on its own. So between touches, a monster that lapsed a week ago is still being counted at the weight it had a week ago.

That is safe in exactly one direction, and the direction matters: an over-counted denominator pays out less per unit of weight than it could, never more. Nothing is lost — the remainder stays in the contract — but it does not reach anybody until the stale monster is settled.

poke(uint256[]) is the settle, and anybody may call it on anybody's monster. The caller is paid 1% of exactly what their call released, out of that released amount. The rest goes back to everyone still on a streak.

IT CANNOT STEAL

A poke can only realise decay the clock has ALREADY earned — the same decay the monster's own next feed or claim would realise. It never lowers a streak below what the clock says, never moves an NFT, never touches anybody's balance except the bounty out of what it just freed, and on a monster that owes nothing it changes no state at all.

IT SORTS ITSELF

The bounty is proportional to what the settle actually frees, so the stalest, highest-streak monsters are the most profitable to poke. Nobody has to schedule the queue — the money is already pointing at the right end of it. Bots will run this, and that is the design working.

IT IS A NO-OP, NOT A REVERT

Poking a monster that owes nothing returns before writing a single slot. That is deliberate: a bot batching a hundred ids must not have the whole batch fail because one of them was fed a minute ago.

The list of monsters currently worth poking, what each owes and what it pays, is on the shift board. The bounty rate is governed and bounded 0%–5%; at zero nobody clears the backlog, which is why it is a number worth watching rather than an implementation detail.

SECTOR 04

WHAT THE TEAM CAN CHANGE

24H TIMELOCK

The honest version of a launch is that the numbers will be wrong at first. The prior project this one is built from died with its parameters frozen and no way to fix them. So Ponstro is adjustable — and the whole design problem was making it adjustable without making it a rug.

Every parameter with an economic number in it goes through the same ceremony: propose, wait, execute. There is no emergency path around the clock, for any parameter, ever.

01
PROPOSED IN PUBLIC
The exact new value is written on-chain with an event. Out-of-bounds values revert here, at propose time — they never even become a pending change.
02
24 HOURS PASS
TIMELOCK_DELAY is a compiled constant. It cannot be shortened, and re-proposing a value restarts the full delay.
03
EXECUTED AS ANNOUNCED
Execute must be handed the same value that was proposed, and the bounds are checked again. A swapped-in number reverts.
04
OR IT EXPIRES
A proposal dies 7 days after it matures. A stale one cannot be executed — no dusting off a change nobody is watching for any more.

Every timelocked number on the NFT, and the bounds it is trapped inside

PARAMETER	AT LAUNCH	CAN ONLY EVER BE	WHAT IT DOES
feedCost	250 $PONSTRO	100 – 100,000	Burned per monster, per feed.
mintPriceWei	0.004 ETH (~$10)	0.0001 ETH – 0.02 ETH	Paid in ETH per monster hired. IMMEDIATE, not timelocked — but at most 20% per step and at most once every 12h.
feedWindow	24h	6h – 7d	THE ONE CLOCK. Feed inside it and the streak is safe.
pokeBountyBps	1%	0% – 5%	Paid to whoever settles a lapsed monster, out of what the settle frees.
walletLimit	10	1 – 100	Mints per wallet. A fairness signal, not a security control.

The bounds themselves are constants in the bytecode. They are not settings, they are not behind a longer timelock, and there is no function anywhere that widens one. There is no relational invariant left to enforce between them: v1 needed freshWindow < staleWindow because it had two clocks, and v2 has one.

And the same for the fee router

PARAMETER	AT LAUNCH	CAN ONLY EVER BE	WHAT IT DOES
rewardLegBps	3,334 (33.34%)	2,000 – 5,000 (20% – 50%)	How much of each harvest buys $PONS for the monsters. Three equal legs at launch — the other two buy $PONSTRO and burn it, and mint liquidity for the overtime crew. There is no fourth destination and no owner cut.
maxEthPerHarvest	2 ETH	0.01 – 10 ETH	Ceiling on one cycle, so a single harvest cannot move the pool too far.
maxSlippageBps	150 (1.5%)	10 – 500	How far below the oracle price a swap may settle.
maxEthAgeSec	12h	1h – 2d	How stale the ETH price feed may be before a harvest reverts.
maxRewardAgeSec	96h	1h – 7d	The same staleness limit for the reward asset's price feed.

Note what the 20%–80% bound on the split means in practice: “the owner re-points the entire fee at one leg” is not a move that exists. At either extreme the other leg still receives a fifth of every harvest.

What is not timelocked, and why

mintOpen
Opens and closes hiring. A boolean — there is no number in it, and no setting of it moves a token or a reward.
baseURI
Where the art metadata is served from. A constructor argument with no setter at all — stronger than a freeze, because there is no call to make.
ponstroToken
Set ONCE and then permanently rejected. Stronger than a timelock: after the first call there is no second one.
keeper
Priority inside the 6h harvest window, never authority. Harvesting stays permissionless whatever this is set to.

Nothing in that list has a number in it that touches the money. Anything that does is on the clock.

THE ONE-WAY SWITCH

sunsetSetters()

A single call that permanently ends the owner's ability to change any number in this suite. After it, every propose and every execute reverts, forever. Calling it twice reverts, so the event is emitted exactly once in the contract's life. There is no un-sunset function and no upgrade path that could add one.

What it does not do, because conflating the two would be a lie: ownership survives it. The owner keeps the non-economic switches above — mintOpen, the keeper slot, baseURI until it is frozen, and stray-token rescue. Sunset is about numbers.

NO ADMIN WITHDRAWAL

There is no function anywhere in this suite that lets an owner move user funds. Not behind the timelock, not behind a bound, not under any name. The base governance contract deliberately contains no value-moving function at all, so a future “just add it behind the timelock” argument has nothing to hang on.

rescueToken(address) exists for strays and reverts for $PONS and for $PONSTRO. Stated rather than hidden: it is ERC-20 only, so a stray NFT sent to the contract cannot be recovered — deliberately, because an NFT rescue would be an owner power over every NFT the contract holds.

NO RENOUNCING EITHER

renounceOwnership() reverts. That is deliberate and it is not the weaker choice: an ownerless Ponstro could never re-tune a parameter, never re-open a mint, never rescue a stray token, and never call sunsetSetters(). The credible end state is the sunset, not an abandoned contract.

NO ETH IN THE VAULT

The NFT contract rejects plain ETH transfers outright rather than letting them arrive and sit unreachable. Mints and feeds are paid in $PONSTRO and burned; rewards are an ERC-20. There is no ETH balance for anybody to argue about.

One limit worth saying out loud, because it is the honest shape of the guarantee: Solidity gives a base contract no way to forbid a child from declaring its own storage and its own second setter. What closes it here is that the governed numbers live in storage the base contract owns privately, reachable only through one hook that is itself unreachable outside the ceremony. “Did somebody add a second setter?” is answerable by reading one file for one function name.

SECTOR 05

THE ONLY CONTRACTS THAT ARE OURS

Read off the published deployment manifest, not typed into this page. Anything that is not deployed yet renders an em-dash rather than a plausible-looking address, because a placeholder somebody can paste into a wallet is the one mistake here that costs a stranger money.

Contract addresses

Only ever interact with the addresses shown here. We will never DM you a different one, and we will never ask you to sign anything from a link somebody sent you.

LOADING DOCK

ON-CHAIN ADDRESSES · CHAIN 4663

READING…

PONSTROS · ERC-721NOT DEPLOYED
—
The 1,000. Holds the reward vault, the streak ledger and the mint.
$PONSTRO · ERC-20NOT DEPLOYED
—
What a feed burns. Set once on the NFT and never swappable afterwards.
$PONS · REWARD TOKENCONSTANT
0x39dbed3a2bd333467115de45665cc57f813c4571
What a monster earns. Immutable, ownerless and fixed supply — nine standard ERC-20 entry points and nothing else. View on the explorer
WETH / PONS POOLCONSTANT
0xed50bdeea8adc232f159486192a4157281d722ff
Uniswap V3, 0.30% tier. Where leg 1 buys $PONS. Its fee is swap friction on that one leg — 0.10% of the whole fee — paid to the pool's own liquidity providers, and it is not a leg of the split. View on the explorer
FEE ROUTERNOT DEPLOYED
—
Collects the swap fee and divides it into 3 equal legs — reward, burn, liquidity. It has no owner destination and no fourth leg of any kind.
BURNERNOT DEPLOYED
—
Leg 2. Buys $PONSTRO in its own pool and destroys it. Swept mint ETH lands here too.
OVERTIME FARM · LEG 3NOT DEPLOYED
—
Where leg 3 mints $PONSTRO/ETH positions and where Work Overtime locks yours. Falls back to the router when a manifest does not name it separately, because leg 3 may live inside the router.
HARVEST RELAYNOT DEPLOYED
—
Makes harvesting permissionless. Anyone can turn the crank.
BURN ADDRESSCONSTANT
0x000000000000000000000000000000000000dEaD
Where fed $PONSTRO — and everything leg 2 buys back — goes to die. Validated in the constructor: a constant, not a setting, so it cannot be pointed at a wallet. View on the explorer