Fee & Burn Mechanics · SnowballBNB Docs

How the 0.5% fee turns into a burn, a buyback, or auto-liquidity, and why those are different operations.

The fee only applies on swaps

SnowballToken charges its fee only when a transfer touches a registered AMM pair (isPair[from] || isPair[to]): a buy or a sell. Wallet-to-wallet transfers are free. The fee itself is capped in code:

50 bps (0.5%)

Default fee

500 bps (5%)

Hard cap (MAX_FEE_BPS)

FeeRouter, same tx

Fee destination

Burn vs. buyback: these are different operations

The marketing copy says “automatic buybacks.” What actually happens depends on whether the fee token is the thing being burned:

SnowballToken's own fee: it's already collected in $SNOWBALL, so FeeRouter just burns it directly (token == burnTarget). Routing it through a swap first would burn gas and slippage for no reason. There's nothing to “buy back.”
Any other registered token's fee: its fee is swapped token → BNB → $SNOWBALL, then burned. That is a genuine buyback: $SNOWBALL demand funded by another token's volume. This is the “ecosystem-wide buy-and-burn” the roadmap describes.

Copy accuracy note

“Automatic buybacks” is precisely accurate for other ecosystem tokens routed through the engine, and a slight simplification for $SNOWBALL's own fee, which is a direct burn. Worth a small copy tweak someday; doesn't change behavior.

Burn / auto-liquidity split

Each registered token has a configurable split between the amount burned outright and the amount paired into liquidity. The default the deploy script uses for $SNOWBALL itself:

70%

30%

Burned

Auto-LP

The LP portion is split in half again: half swapped for BNB, then paired with the remaining half via addLiquidityETH. The resulting LP tokens go to a configurable lpSink, which defaults to the burn address (0x...dEaD) for a trustless, permanent lock; the owner can point it at a real locker contract instead.

Who can trigger a burn

swapAndBurn(token) is permissionless by design (it's never dependent on one keeper going offline), but is gated behind onlyKeeperOrOwner until the owner calls setPermissionlessSwaps(true). See Security Model for why that gate exists.

Why the registry doesn't force fee routing

SnowballRegistry.register() is permissionless precisely because it can't compel an already-deployed, externally-owned ERC-20 to send it fees. Registering a token is a discovery/listing action; actually routing a token's fees through FeeRouter requires the platform owner to explicitly call configureToken(...) for it. Registry listing and fee routing are independent on purpose.