PONSTRO

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 4.00%, of which 3.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%

That is the split at launch. The owner can move the reward and liquidity legs at any time, with immediate effect; the burn leg is whatever is left, so the three always make up the whole harvest. The payroll board reads the split the router is using right now.

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 the owner can change

SETTINGSET WITHHOW IT MOVES
Router legssetRewardLegBps · setLiquidityLegBpsimmediate; the burn leg is what is left, so all 3 always make up 100%
Feed cost ($PONSTRO)setFeedCostimmediate; refuses only zero
Mint price (ETH)setMintPriceWeiimmediate
Feed windowsetFeedWindowimmediate; refuses only zero
Grace on the decay deadlinesetGraceWindowimmediate
Mints per walletsetWalletLimitimmediate
Poke bountysetPokeBountyBpsimmediate; at most 100% of what a settle frees
Marketplace burnnonefixed at 5% — a constant in the market contract
THE OWNER SETS THESE IMMEDIATELY
Each number is a plain owner setter: the new value applies in the transaction that sets it, with no waiting period and no range compiled in. Every change is logged on chain with the old value and the new one, and the payroll board reads the current value of each.
THE SPLIT CANNOT GROW A FOURTH DESTINATION
The owner sets the reward and liquidity legs; the burn leg is whatever is left, and a setting where the two do not fit inside 100% reverts. There is no dev leg, no dev wallet, and no fourth destination for any share of the fee.
SUNSETSETTERS() ENDS THE NUMBERS, PERMANENTLY
One call, one way, no undo. After it, every numeric setter on that contract reverts and the parameters stay where they stand — the legs included. It is optional, and it is the one governance action that cannot be reversed.
THERE IS NO ADMIN WITHDRAWAL FUNCTION
Not for “emergencies”, not under any name. 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, an address the owner sets with setBurner().
SECTOR 02

WHAT FEEDING COSTS

HIRE A MONSTER0.004 ETHETH, about $10 at launch. mint() is the only payable entry point on the contract; every other call carries zero.
FEED A MONSTER10,000$PONSTRO, burned, per monster per feed. Flat — there is no cap and no min(). The owner can change it immediately; the contract refuses zero.
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. The burner itself is the NFT's burner(), which the owner can repoint immediately with setBurner(). 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 — at most once per feed window, and only when the feed is on time — so weight climbs by 10,000 each time until the top rung. And it stamps lastFedAt with the current block time, which restarts the decay deadline.

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. 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 price is a calibration, and the owner sets it. 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. setFeedCost takes effect immediately and refuses only zero. 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 on time and the streak goes up one, to a maximum of 10. Let the feed window and its grace pass without a feed 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 deadline is the window plus the grace. With a 24h feed window and 8h of grace, nothing is owed until both have passed since lastFedAt; after that levelsOwed is (now − lastFedAt − graceWindow) / feedWindow, rounded down. Both are owner settings that take effect immediately.

A late feed buys nothing back. A feed that arrives after the deadline still costs the feed and still burns it, but the monster loses the level it owed and gains nothing — and the next level is a whole feed window after that late feed. It no longer works to feed every couple of days and have each feed win back the level the gap cost: the streak holds only if every feed lands within the window plus the grace.

0.01x—0.10x01.00x12.00x23.00x34.00x45.00x56.00x67.00x78.00x89.00x910.00x10STREAK — CONSECUTIVE FEED WINDOWS KEPT
  • 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 and its grace are owner settings; the ladder is not — every value on it is a compiled constant.

Every rung, with the weight the contract actually uses

RUNGWEIGHTMULTIPLIERWHAT IT MEANS
NEVER FED1000.01xAn intern. Has never eaten and does not know it.
STREAK BROKEN1,0000.10xHas eaten before. Missed enough windows to fall all the way off.
DAY 1 OF 1010,0001.00xOne feed in. The ladder starts here.
DAY 2 OF 1020,0002.00xTwo days running.
DAY 3 OF 1030,0003.00xThree days running.
DAY 4 OF 1040,0004.00xFour days running.
DAY 5 OF 1050,0005.00xHalfway up.
DAY 6 OF 1060,0006.00xSix days running.
DAY 7 OF 1070,0007.00xSeven days running.
DAY 8 OF 1080,0008.00xEight days running.
DAY 9 OF 1090,0009.00xOne short of the top.
DAY 10 OF 10100,00010.00xMaxed. 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. A feed at least one 24h window after the last level gained moves you up one rung; going 32h without a feed (the launch window plus its grace) moves you down one, and the late feed does not win it back. 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

SINCE LAST FEEDLEVELS OWEDEFFECTIVE STREAKWEIGHTMULTIPLIER
just fed0660,0006.00x
24h0660,0006.00x
32h0660,0006.00x
33h1550,0005.00x
48h1550,0005.00x
81h3330,0003.00x
8d701,0000.10x

Note the 32h row: the window and the grace have both passed and still NOTHING is owed — the deadline is inclusive. An hour later one level is owed, and a feed at that point pays, loses that level and gains nothing back. Computed at page render with the same arithmetic levelsOwed and weightOf use, at the launch window (24h) and grace (8h).

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

A 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 a share, set by the owner, 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 an owner setting that takes effect immediately; 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

IMMEDIATE SETTERS

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 it says exactly how.

Every number with an economic effect is a plain owner setter. The owner calls it and the new value applies in that same transaction — there is no waiting period and no range compiled in. The current value of every one of them is on the payroll board, read from the contracts.

  1. 01

    SET BY THE OWNER

    One onlyOwner call per number. It takes effect in the transaction that makes it.

  2. 02

    LOGGED ON CHAIN

    Every numeric setter emits the old value and the new one, so the full history of every number is readable from the logs.

  3. 03

    ONLY BREAKAGE IS REFUSED

    A setter reverts only on values the contract's own arithmetic cannot survive: a zero feed cost or feed window, a bps figure above 100%, router legs that do not fit, a zero TWAP window.

  4. 04

    OR ENDED FOR GOOD

    sunsetSetters() is optional and one-way. After it, the numeric setters on that contract revert forever.

Every settable number on the NFT, and what it reads now

PARAMETERAT LAUNCHNOW, ON CHAINWHAT IT DOES
feedCostsetFeedCost()10,000 $PONSTRO—Burned per monster, per feed. The contract refuses only zero.
mintPriceWeisetMintPriceWei()0.004 ETH (~$10)—Paid in ETH per monster hired.
feedWindowsetFeedWindow()24h—A feed gains at most one level per window; decay is counted in windows. The contract refuses only zero.
graceWindowsetGraceWindow()8h—Slack on the decay deadline. The streak holds while fed within feedWindow + graceWindow.
pokeBountyBpssetPokeBountyBps()5%—Paid to whoever settles a lapsed monster, out of what the settle frees. At most 100%.
walletLimitsetWalletLimit()10—Mints per wallet. A fairness signal, not a security control.

The owner can set any of these at any moment, with immediate effect. There are no bounds in the bytecode to quote: the only values refused are the ones named above, because the contract itself would break on them.

And the same for the fee router

PARAMETERAT LAUNCHWHAT IT DOES
rewardLegBpssetRewardLegBps()3,334 (33.34%)How much of each harvest buys $PONS for the monsters. With the liquidity leg it must fit inside 100%; the burn leg is the remainder. There is no fourth destination and no owner cut.
liquidityLegBpssetLiquidityLegBps()3,333 (33.33%)How much of each harvest mints liquidity for the overtime crew.
maxEthPerHarvestsetMaxEthPerHarvest()2 ETHCeiling on the fresh ETH one harvest splits, so a single cycle cannot move a pool too far.
maxSlippageBpssetMaxSlippageBps()200 (2%)How far below the reference price the reward leg's swap may settle. At most 100%.
ponsPoolFeesetPonsPoolFee()3,000 (0.30%)The Uniswap V3 fee tier the reward leg buys $PONS in.
refPoolFeesetRefPoolFee()10,000 (1%)The fee tier of the pool the reward leg's price floor is read from.
twapWindowsetTwapWindow()15mThe averaging window the price band is measured against. The contract refuses only zero.
maxTickDeviationsetMaxTickDeviation()1,000 ticksHow far the reference pool's spot may sit from its TWAP before a harvest refuses.

The burn leg has no setter of its own: it is whatever the reward and liquidity legs leave, so the split can never point a share of the fee anywhere outside the three legs. The live value of every router number is on the payroll board.

What is not a number

  • mintOpen

    Opens and closes hiring. A boolean — there is no number in it, and no setting of it moves a token or a reward. After sunsetSetters() it can only be closed.

  • baseURI

    Where the art metadata is served from. The owner can move it with setBaseURI() — immediately, to fix a broken directory — until freezeMetadata() is called, which ends it permanently. Whether that has happened is metadataFrozen(), public on the NFT.

  • ponstroToken · overtime

    Set ONCE and then permanently rejected: after the first call there is no second one.

  • burner (NFT)

    Where the mint ETH is swept and where the marketplace sends its burn share. setBurner() on the NFT moves it immediately and checks nothing about the address; sunsetSetters() on the NFT ends it.

  • burner · swap venue · farm (router)

    Where the router sends each leg. Each moves immediately, cannot be pointed at an address with no code, and has its own one-way freeze after which it can never move again.

  • keeper

    Priority inside the 6h harvest window, never authority. Harvesting stays permissionless whatever this is set to.

These are owner switches too, and they are immediate as well.

THE ONE-WAY SWITCH

sunsetSetters()

A single call that permanently ends the owner's ability to change the numbers on that contract. After it, every numeric setter 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. It is optional: nothing calls it and nothing requires it.

What it does not do, because conflating the two would be a lie: ownership survives it. The owner keeps the switches above — closing mintOpen, the keeper slot, baseURIuntil it is frozen, the router's addresses until each 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 an owner switch, not under any name. The base governance contract contains no value-moving function at all.

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: the sunset is permanent only for as long as the bytecode is. No contract in this suite sits behind a proxy or uses delegatecall, so there is no upgrade path that could put a setter back — and anyone can check that by reading the deployed code.
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. Read from the NFT's burner(), which the owner can repoint with setBurner() — so it is read live, never cached.

  • OVERTIME FARM · LEG 3NOT DEPLOYED
    —

    Where leg 3 mints $PONSTRO/ETH positions and where Work Overtime locks yours. Read from the NFT's overtime(), which is set once and never moves.

  • 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

0 of 6 deployment addresses known. The token, the burner and the farm are read from the NFT itself, the rest from the published manifest. Verify anything you are about to sign on the explorer first.

SECTOR 05

WHAT THIS IS NOT

  • It is not a yield product. There is no rate, no APY and no projection anywhere on this site. What a monster receives depends entirely on trading volume in a token nobody controls, and that can be zero for as long as you like.
  • The wallet limit is not a security control. It is trivially bypassed with more wallets. It is a fairness signal at the mint and the contract's own documentation says so.
  • The mint is not refundable. Mint payment is burned, not held. There is no escrow to reverse and nobody holds a balance that could be returned.
  • The weight the vault divides by is deliberately stale. A lapsed monster keeps its old weight in totalWeight until somebody pokes it, so the floor is always paying out slightly less per unit than it has earned. The shortfall is not lost, it is waiting — and clearing it is a job anybody can take, with a bounty on it.
  • A dash is not a zero, anywhere on this site. Every number here comes from a read that can fail, and a failed read prints an em-dash. A zero is a claim; a broken RPC has not earned the right to make one.
  • The reward asset has its own risk, and it is not ours. $PONS is a separate token on this chain with its own liquidity, its own holders and its own price. This project buys it; it does not issue it, back it, or control it. A monster's payout is denominated in it, so its price is your price.
  • Nothing here is financial advice. There is no rate anywhere in this contract. Every percentage on this site is a share of a pot, not a return on a deposit, and the size of the pot is not ours to promise.

Feed your Ponstro, or someone else eats its lunch.

GET A MONSTERBACK TO THE FLOOR