/ how $BURN burns

Lock-as-burn, per TTT

Why balanceOf(0xdEaD) shows 0 and where the real burn pile lives.

The mechanism

$BURN is built on the Ten Thousand Tokens (TTT) protocol. Burns happen through TTT's native, protocol-level supply removal mechanism. Not via the conventional "transfer to dead address" pattern.

In a vanilla TTT launch, every token starts with a 99% buy tax that decays by 1% per block, reaching the 1% resting fee at block 98. Everything above that 1% resting fee, the entire decay surplus, is routed to a buyback reservoir at the token contract. Anyone can then call $BURN.buyback() permissionlessly to:

Use the reservoir's ETH to purchase $BURN from Uniswap V4
Lock the purchased tokens permanently in the $BURN contract

After block 98, the buy tax is the same 1% resting fee as sells. All of it flows to TTT's FeeSplitter; nothing tops up the reservoir from swaps anymore. In a vanilla token, the reservoir drains whatever was captured during the decay window and then stays empty.

BurnToken keeps the reservoir running. Our strategy contract uses its 50% FeeSplitter share to buy TTT NFTs on the secondary market and relist them at +20%. When an NFT sells, ETH proceeds are routed directly into the $BURN contract's buyback reservoir. That ETH becomes the fuel for the next round of $BURN.buyback(), just like the decay-surplus ETH did during the launch window. Locking tokens in the contract is TokenWorks' chosen burn pattern during the decay phase of the fair-launch mechanic; we reuse it for ongoing flywheel burns instead of layering a separate 0xdEaD send on top.

From the TTT whitepaper, §8

"The purchased TTT is held on the contract permanently. It is never distributed, never staked, never released. It is structurally inert."

"The supply of TTT in circulation is monotonically decreasing in cumulative swap volume."

Read the full TTT whitepaper ↗

Verify the burn pile yourself

Tokens accumulate at the $BURN contract address itself rather than a 0xdEaD vanity address. To see the live balance:

Open the $BURN token page on Etherscan
Filter the holders panel by the $BURN contract's OWN address
The balance there is the burn pile. It only grows.

Or just click below. The link is pre-filtered to the burn-pile address.

VIEW BURN PILE ON ETHERSCAN ↗

The contract address ( 0x886fab7097311af73C74DD608001a0d267AbF351 ) holds its own ERC-20 balance. That balance is the burn pile.

How BurnToken (the strategy) feeds the pile

We are the launcher of $BURN: we burned TTT NFT #9099 to activate the token
We receive 50% of every $BURN swap fee, in ETH, perpetually
We use those fees to buy TTT NFTs on the secondary market, list them at +20%
When NFTs sell, proceeds queue for the next round of $BURN buyback

Every cycle adds to the structurally-inert pile. The protocol's deflation is direct, continuous, and on-protocol. Not a marketing convention layered on top.

Common questions

Why doesn't totalSupply() go down?

TTT's buyback locks tokens at the contract address rather than calling _burn. Economically, the tokens are gone (the contract has no function to move them out). On a totalSupply() chart, the number is unchanged. Both are accurate; they describe the same event at different layers. The TTT whitepaper §8 makes this design explicit.

Why not just send to 0xdEaD like other tokens?

The conventional 0xdEaD pattern is from older strategy tokens. TTT (released after those) chose a different mechanism: lock at the contract address. It works for the same reason: the tokens become permanently unreachable. The dead-address pattern is more visible to some screeners; the TTT pattern is verifiable on the $BURN contract's holders panel. Both achieve permanent supply removal.

Can the locked tokens ever leave the contract?

No. The $BURN contract is immutable (not upgradeable). It has no withdraw, transfer-from-self, or release function. ERC-20 permit doesn't work because the contract isn't an EOA and doesn't implement ERC-1271. The TTT factory has no extraction function either. The locked balance is structurally inert per the whitepaper.

How fast does the burn pile grow?

Proportional to BurnToken's flywheel velocity. Post-launch, $BURN swap fees route to TTT's FeeSplitter, not the reservoir. Our strategy contract receives 50% of that fee stream and uses it to buy TTT NFTs, relist them at +20%, and forward the ETH proceeds back into the $BURN buyback reservoir. So burn-pile growth is gated on three things: $BURN swap volume (drives our deployer share), TTT NFT sale velocity (drives reservoir top-ups), and how often anyone fires $BURN.buyback() (drains the reservoir into the lock pile). View live: Etherscan token holders panel ↗.

What stops someone from sweeping the locked $BURN?

The contract's own code. Read the source: search for any function that calls transfer() from the contract's balance. There isn't one. Even the TTT team can't extract these tokens.