tare

on the name

a tare is the weight you subtract to get the true weight. put a jar on a scale and the number it gives you is the contents plus the jar. tare is the button that takes the jar off.

the program does one subtraction, on supply. pump.fun pays creator fees to whatever address a coin names as its creator. here that address belongs to a program rather than a person, and the only thing the program can do with what arrives is buy the coin back. a share of each buy is burned, which removes those tokens from supply for good. the rest goes to a treasury address the authority key chooses.

everything below is how that is wired, what is permissionless, what is not, and what the key that runs it can still do.

on the vault

the vault is a pda, seeded by the literal string vault and the coin's own mint. it is the address a coin names as its pump.fun creator, or as a shareholder inside a fee sharing config, from the moment it launches. from then on pump.fun pays creator fees into an address no one holds a private key for. only the program that derived it can move lamports out.

fees arrive without anyone's permission. collect_curve_fees and collect_amm_fees can be called by any wallet and always land in the same place. wrap_sol and unwrap_wsol move value between the vault's two forms, sol and wrapped sol, and never out of the vault itself.

the vault deliberately holds no account data. pump.fun's buy debits the buyer with a plain system transfer, and the system program refuses to debit an account that carries data. a vault that stored its own bookkeeping could receive fees and then be unable to spend them. carrying nothing is what keeps the buy able to happen at all.

the config pda, seeded the same way with the word config, sits next to it and holds everything the vault does not: authority, treasury, cranker, the burn share, the reserve floor and the running totals. the vault only ever holds money and bought tokens. every decision about what happens to them lives one account over.

no coin is registered against this program yet, so neither account has been opened. there is no vault holding anything, no config to read a dial out of, and no totals except zero.

on the dial

the burn share is one field, burn_bps, 0 to 10000, set by the authority through set_burn_bps. it measures a share of each buyback, not a share of supply. at 10000 every token a cycle buys is destroyed. at 0 none of it is, and the whole buy goes to the treasury. anything between splits the same buy two ways.

the field is read at settle time, so the share that applies to a buy is whatever the dial said the moment that buy settled, not whatever it said when the coin launched. the authority can move it between one cycle and the next, and a run can end at a different setting than it started.

the dial is unset here. it takes a value at registration, and nothing has registered, so no buy has settled under it and there is no gap to read backward yet.

on the crank

a cycle is one instruction: claim, buy, settle, signed by the cranker or the authority. cycle_via_dev does the same work through the dev wallet instead of the vault, so the buy attributes to a wallet chart aggregators already track, without changing what leaves the vault or what gets burned.

on the bonding curve the claim and the buy are the same instruction by construction. after graduation, distribute_creator_fees carries enough accounts of its own that it cannot fit in the same transaction as a buy, so the claim becomes its own transaction and the buy and burn follow as a second one. losing atomicity there is safe. a claim that lands and a buy that does not just leaves the sol in the vault for the next tick.

settle and both collect instructions are permissionless. every destination they can pay out to is fixed by the config account, so a caller only ever chooses the moment, never the outcome. the cranker's real job is timing.

there is no instruction that refunds the wallet paying transaction fees. that wallet is topped up by hand, it spends a few thousand lamports a tick, and nothing in this program puts anything back into it. when it empties, cycles stop. nothing burns and nothing is lost: fees sit in the vault until someone funds the wallet again. a reserve floor can also skip a tick outright rather than spend the vault down to nothing.

on what the key can still do

there is no withdraw instruction. the only way sol leaves the vault is by buying the coin it belongs to. that holds regardless of who holds the authority key, and it does not change on its own. it would take a new instruction, written and deployed on purpose, to add one.

the authority key still does a lot. it can pause the program outright. it sets the burn dial, anywhere from 0 to 10000. it sets the reserve floor the vault always keeps back. and it can rotate the treasury, the cranker and the authority itself, including handing the authority to a different key entirely.

the program also keeps its upgrade authority. that has not been set to none. the code at this address is not fixed, and an upgrade could change what cycle, settle or any other instruction actually does. so call none of this audited, immutable, trustless, safe or verified. it is a program an authority key can still change, still pause and still redirect, and everything above describes what the code does today rather than a promise about what will always run here.

on the first run

this program source has already run on mainnet once, under a different name and on a different coin, on 2026-08-29. registration opened its config and vault with the burn dial at 10000, all the way on. 55 buyback cycles followed. about three minutes before the last one the authority turned the dial to zero, so that final cycle bought tokens and burned none of them, sending the whole buy to the treasury. minutes later the same wallet closed the program through the loader that had deployed it.

solana does not let a closed program id be deployed to again, ever. so tare is not that program restarting. it is the same source, built and deployed fresh under its own program id on 2026-09-16, with its own vault and its own mint, carrying no on chain relationship to what closed.

between those two deployments the crank was tested live on mainnet against a disposable coin, and four buys in ten reverted. the buy was quoting the entire spendable balance and then handing that same number in as the ceiling it was allowed to spend, which left it one lamport of headroom. 175 lamports of somebody else's buying landing first was enough to push the real cost over the ceiling and make pump.fun reject it. the fix quotes the slippage discounted amount and keeps the full balance as the ceiling, and the unspent difference is swept back into the vault for the next tick. every cycle after the fix landed, on the curve and then on the amm. that is why this program id is dated 2026-09-16 and not earlier.

none of that is tare's history. tare has claimed nothing, bought nothing and burned nothing. the log above this paragraph is empty because there is nothing in it yet, and the totals are zero because they are really zero.