A token that pays people to burn it: the fee math behind a burn-dividend deploy

Most "burn" tokens burn on autopilot: a slice of every trade disappears into a dead address, and the chart looks deflationary whether or not anyone participates. The burn-dividend type is the opposite bet. It still burns, but it pays the people who do the burning — so the burn is something your community does to the token, not something that happens to it while they watch.

That single decision changes what every fee column means, so it's worth walking through the way the deploy form presents it rather than the way a whitepaper would.

What the type actually does

The type chip reads Burn token, and the panel under it is unusually direct:

"Buy and sell fees fund token burns and rewards for users who send tokens to the burn address."

Best for is "Projects that want a deflationary narrative and an incentive for users to participate in burns." The two Key benefits are the supply side and the payment side: ongoing burns reduce circulating supply, and "addresses that participate in burns can earn rewards based on their burn weight."

The two Keep in mind lines are the ones that decide whether this token type is right for you, and they're both about money that isn't there yet:

"Rewards depend on real trading volume and user burns. They are not created automatically."
"Tax rates, burn settings, and the marketing wallet require ongoing maintenance."

Read the first one twice. A burn-dividend token with no trading volume is a token with a tax and no rewards. The mechanism doesn't manufacture yield; it routes a share of what traders pay to the addresses that burned. If you can't describe in one sentence who will trade it, you're about to ship a fee with no beneficiary.

The four columns, and the two that look alike

Turn on Buy / sell fee settings and the form opens two mirrored columns, four percentages each. The hints under them are the clearest description of the split:

• Marketing fee — "Automatically sends to the marketing wallet"
• Burn fee — "Sends to the burn address, making the supply deflationary" — this is the one that shrinks supply
• Liquidity fee — "Automatically adds to the liquidity pool"
• The fourth column — "Swap into the reward token and pay holders" — this is the burn-rewards fee: the share that gets converted and distributed by burn weight, which is the whole point of the type

Two of those are burn-related and both happen to be labelled Burn fee on the page, so read the hint under each field rather than the label when you're typing numbers. They are not the same setting: one sends your token itself to the burn address forever, the other buys your reward token and hands it out.

Three rules constrain the numbers, and each of them has a story:

All fees together must stay below 100%. The form blocks a side that reaches 100% before you can sign — the error reads "Base buy tax plus referral rewards must stay below 100%" — because at 100% the contract rejects the trade and a buyer receives nothing. Fees are also truncated to two decimals rather than rounded: "Fees are precise to 0.01% and the contract truncates anything beyond two decimals." A 0.009% setting becomes 0%.

The two reward columns can't both be zero. With fee settings on, "buy and sell reward fees cannot both be zero; otherwise no rewards of that type will be generated." This is the classic misconfiguration: someone sets up a burn-dividend token, zeroes the reward column because "we're not paying rewards yet", and ships a taxed token that burns and markets but never pays a burner.

Whatever can't be distributed goes to the marketing wallet. Same notice, last sentence: "Undistributed or failed-to-convert fees are returned to the marketing wallet." The conversion is a real swap through a real router; if the pair is thin, the swap can fail, and that share lands in the marketing wallet instead of in burners' hands. Not a bug — but it means a thin pool quietly converts your reward budget into marketing budget.

The rest of the switches are shared with the other taxed types: anti-bot window, extra holder addresses per trade, buy limits (max buy, max sell, max holdings), transfer tax, and referral rewards. Two of them matter more on this type than on the others:

Transfer tax applies to wallet-to-wallet moves: "Enter 0 to turn it off. Enter 3 for a 3% transfer tax; the tax goes into the contract and is distributed using the trading-fee allocation." Note what that last clause means on this type: transfers become another source for the same four-way split, reward share included — so a token with a transfer tax has one more way to feed burners, and one more number to explain.

Whitelist addresses bypass launch timing, buy/sell and holding limits, anti-bot checks, fees, and transfer tax. That's an exemption list, not a VIP list. Add the wrong address and it trades your token tax-free forever, which on a fee-funded token means it also stops feeding the rewards.

Where the reward token and the pair come from

The constructor takes five argument groups, and the address group holds more slots than the form shows you. The Pair and reward settings section covers the three that decide behaviour:

• Exchange / router — "Choose a common exchange or enter a router address manually." The fee conversion happens through this router, so it has to exist on the chain you're deploying to.
• Quote token — "Usually WBNB, WETH, or a stablecoin." This is the other half of the trading pair, and it's also the thing your reward fees get swapped through.
• Reward token — "If this matches the quote token, rewards are paid in the quote token." This is the decision that defines what your burners actually receive: more of your own token, or BNB, or a stablecoin, or some third token you believe in.

One slot in that group isn't yours to fill. It's a reward-tracker implementation the platform writes per chain — a fixed value the contract needs in order to know who has burned what. There's nothing to check on your side beyond deploying on a chain where the value is correct, which is one of the reasons a testnet run on a chain you don't usually use is cheap insurance.

Who gets paid, and who doesn't

This is where the type differs from every other rewards token, and it's the part that support tickets are made of.

Eligibility is not holding. The field is called Minimum to earn rewards, and the hint spells out the rule:

"Rewards only come from tokens sent to the burn address: the first transfer must reach this amount, and weight then follows each address's cumulative burns."

So: send tokens to the burn address, and only once your first send clears the threshold do you start earning. After that, weight tracks the cumulative total you've burned, not your current balance. Three consequences people discover late:

1. Holding the token earns nothing. The holder-rewards type pays balances; this one pays burns. If most of your community is accumulating and not burning, they will earn zero and they will be surprised.
2. Your own marketing wallet isn't a burner either — unless you send tokens to the burn address from it, in which case it earns weight like anyone else. If that's your plan, say so. A team wallet quietly collecting burn rewards is the kind of thing that gets noticed in a dashboard and never forgiven in a Telegram group.
3. The threshold is editable later. In the token console, Reward controls lets the owner change "Minimum burned", exclude addresses from payouts (Reward blacklist), and set the Reward interval — the gap between automatic payouts, which the contract accepts only between 3,600 and 86,400 seconds (one hour to one day).

Payouts are pushed automatically on trades at that interval, and Claim rewards exists for the manual top-up: "Claims the rewards this wallet has earned so far." Note the scope — it settles the wallet you're connected with, not every wallet on the token. There's no button anywhere that distributes to everyone at once.

What deployment costs

Two numbers, and only one of them is the one people budget for.

The deploy fee for this type on BNB Chain is 0.01 BNB — cheaper than the standard and marketing types, which sit at 0.05 BNB — and the page shows the exact figure for whatever chain you picked before you sign. Gas is separate and paid from the same wallet.

The second number is the one that's easy to forget: this type also carries a 0.25% platform fee on transaction value, shown right under the deploy price as + 0.25% platform fee on transaction value. That's not a deploy cost, it's a running cost, and it's on top of whatever tax you set. If you're modelling whether the tax can fund a marketing budget, subtract it before you're surprised.

Before any of that is charged, the call is simulated with your actual arguments. The FAQ on the creator page answers the obvious question — "Do I pay if the deployment fails?" — with "No. Invalid settings are shown before your wallet asks you to sign, and no transaction is sent."

Launch ships switched off

This surprised me the first time, and it changes how you plan the launch.

The Launch settings switch defaults to off, and the copy explains what that means: "Turn this on to launch immediately or schedule a time. Leave it off to keep trading closed after deployment and open it later from the token console." If you deploy with it off, the confirmation says "The token is deployed with trading still closed. You can launch it from the token console whenever you are ready."

The two on modes are not symmetric:

• Launch immediately — "Trading opens as soon as deployment is confirmed. Once liquidity is added, users can trade right away. This cannot be reversed."
• Schedule a time — "Pick a future time. Trading opens automatically then. It cannot be closed after launch, and the launch time can only be moved earlier, never later."

Two traps hide in that pair.

If you're using the anti-bot window, the countdown starts at the launch time — or, with an immediate launch, at deployment. The warning is explicit: "If liquidity is added after that window ends, the protection will no longer stop snipers after the pool opens." A 60-second window with a pool you add twenty minutes later protects nothing. Schedule the launch for the moment you actually add liquidity.

And if you leave launch off and later renounce ownership, the console warns before you do it: "The launch time has not been set. After renouncing ownership, trading could never be opened." That's a token that can never trade, permanently, with a verified contract and a happy-looking chart of a supply nobody can buy.

Once it's open, there is no switch to close it. The FAQ says so: "There is no separate switch. To stop trading, set all three values under 'Enable buy limits' — max buy, max sell and max holdings per address — to 0." That's a blunt instrument: it stops everyone, including the addresses you wanted to keep trading.

The parts that will bite you in month two

None of these are bugs. They're the shape of the mechanism, and each one has a support thread somewhere:

• A thin pool eats your reward budget. Failed conversions go to the marketing wallet. If rewards mysteriously stop while fees keep accruing, look at the pair's depth before you look at the contract.
• Nobody burns, nobody earns. Burn weight only exists after a send clears the threshold. A community that holds and doesn't burn is a community earning nothing — the panel says the rewards depend on user burns, and it means it.
• Taxes are a transfer from traders. A 5% buy tax with a 2% reward share doesn't create 2%; it moves it. Anyone telling their community this is "passive income from the project" is describing a transfer with extra steps.
• Farming your own rewards doesn't close the loop. Wash trades between your own wallets do generate burn weight and rewards — and also pay the marketing, liquidity and burn shares plus the platform's 0.25%. You end up down the tax minus the reward share you got back, plus gas.
• Raising the threshold retroactively drops small burners. "Burns below this amount earn no rewards" is the console's own wording, and the value is editable at any time. Change it after launch and the people who burned a little quietly stop qualifying — which is a community decision wearing a settings field's clothes.

Try it where mistakes are cheap

Every type costs 0.000001 of the test coin on BNB Chain Testnet, which is the right place to learn what this type feels like: deploy with launch off, open it from the console, add a little liquidity, make a trade, send tokens to the burn address, and watch the weight appear in Reward controls before any of it involves real money.

Switch networks from the dropdown at the top of the page, not inside your wallet — the page decides where the contract lands, and the wallet popup is a separate switch that people mismatch at exactly the wrong moment.

The creator is at gtokentool.com/en/tokenfactory, the field-by-field guide for all seven types at /en/guide/create-token, the console you'll live in afterwards at /en/managetokens, and the liquidity step at /en/createLiquidityAndBuy. Fees and prices above are BNB Chain's at the time of writing; the same form runs on the other chains the site lists, and the number on the page is the one that applies to the chain you selected.