Skip to main content
The current Base Tax deployment is base-mainnet-tax-token-v2, with inclusive tax encoding, fee-accrual Dividend accounting and holder-authorized claims. Resolve existing tokens by their chain and originating factory, then use that deployment’s ABI and capabilities. A chain ID alone does not distinguish Base B20 launches from Tax ERC-20 launches. Use the suite registry for contract identities and the Base Tax configuration for dated settings. Read current policy, quote registration and creation availability before preparing a launch.

​
Read and prepare a launch

Read taxPolicy(), configVersion(), launchSupply(), quoteConfig(quote), quoteRevision(quote), nativeLaunchFee() and launchCreationEnabled() at one recent block. Also resolve the current adapter for an atomic buy. Tax does not expose the Standard suite’s fee-component arrays or baseFeeBps(). TaxPolicy contains: The Tax LaunchParams tuple retains the identity, metadata, salt, quote, expected version and deadline fields, and adds: Use the complete Tax ABI when encoding; Standard launch tuples are incompatible. previewTaxConfiguration(configuration) returns configVersion, buyRates, sellRates, dividendsEnabled and minimumDividendHoldingRequirement. It validates the economic configuration, not every recipient, payment or route requirement of a complete launch. Predict the ERC-20 with launchTokenInitCodeHash(launchParams) and the bound token deployer’s creation formula, including finalized metadata and tax inputs. Mine the required 01 suffix. Do not reuse a Standard B20 prediction or the Standard ERC-20 launchTokenBytecodeHash method. createLaunch requires exactly the native launch fee. For native-funded createLaunchAndBuy, include the launch fee plus the buy input. ERC-20-funded direct integrations approve the bound adapter for the buy input and send the native launch fee separately. Simulate the complete route and payment. An atomic buy pays ordinary buy tax; only its surcharge is exempt. A failed buy rolls back the launch.

​
Exact percentage units

Rates and allocation shares use checked uint32 inputs. Token amounts use their currency’s base units. With 18 launched-token decimals, 10,000 tokens is 10000000000000000000000. Parse decimal strings exactly and reject more than six percentage decimals. Do not pass BPS into these fields. Derived rates returned by the Hook use RATE_SCALE = 10^24, not the input scale or token decimals. API slippage_bps still uses BPS and is a separate unit. For positive total T, protocol share s, floor m, ceiling M, allocation shares wC/wB/wD/wI, and D = 100000000:
Widen before multiplication. Keep this intermediate precision rather than rounding protocol to an input step first. The quote rate is protocol, creator, dividend and integrator rates plus any surcharge; burn is a separate launched-token rate. Use full-precision integer math with the contract’s rounding when reproducing amounts. Do not add quote-token and launched-token raw amounts.

​
Zero and boundary rules

  • The current 1% minimum rejects zero. A future policy can permit exactly zero on either or both sides; zero returns zero ordinary fees before the protocol clamp.
  • Every positive total must cover the protocol floor. With a 0.5% floor, 0.3% rejects; a permitted 0% to 10% range admits zero or 0.5% through 10%.
  • Each allocation may be zero. If either side has a remainder, the four shares must sum to 100%.
  • If neither side has a remainder, all four shares and the selected minimum holding must be zero, and no Dividend clone is created.
  • With dividends enabled, the selected minimum must meet the current factory floor and not exceed supply. With dividends disabled, use zero for the selected minimum.
  • A zero protocol share still applies a positive floor. A zero protocol maximum requires a zero minimum and means zero protocol, not an unlimited maximum.
  • Duration zero is valid factory configuration; creator opt-out works and opt-in rejects. For positive duration, opening must cover the permitted maximum taxes on both sides.
  • The configured ordinary 10% maximum is not an immutable cap. The fixed combined ceiling is 99%. Zero ordinary taxes do not independently disable an enabled surcharge or the separate launch fee.
The owner uses setTaxPolicy, or the focused setTaxFeeBounds, setProtocolFeeConfiguration, setAntiSnipeConfiguration and setMinimumDividendHoldingRequirement. All validate the proposed complete state. Coordinated changes can be applied atomically; identical valid policy settings emit no update and do not advance the version. Launches still enforce their actual expectedConfigVersion onchain. Ordinary payout validation excludes this suite’s known non-paying dependencies, including the current adapter and its router/swap caller. An unset adapter skips those endpoint checks and still permits a plain launch; an initial buy requires a configured adapter. Compatible smart wallets and splitters remain supported. Validate through the complete preview/simulation path; adapter changes do not reroute historical credits.

​
Trading and routing

Use the exact registered pool key and poolConfig(poolId) for its frozen configuration. effectiveFeeRates(poolId, isBuy) returns (Rates rate, bool exactOutputRestricted). The Rates tuple contains quoteRate, burnRate, protocolRate, creatorRate, dividendRate, integratorRate, surchargeRate, including the current timestamp-based surcharge. Check the returned restriction flag as well as the amounts; a rounded-zero surcharge can still restrict exact-output swaps. The Hook supports these four settlement cases. F = 10^24, q is the derived quote rate, b the burn rate, G gross specified input and N requested net output. Pool amounts are raw deltas before the final Hook fee adjustment. These formulas do not override signed settlement limits, full-fill requirements, slippage or router capabilities. Tiny amounts may round to zero or be unexecutable. The Public API exposes exact-input only. Exact-output is restricted during an applicable anti-sniping window, including its rounded-zero tail; no surcharge restriction applies when opening equals the side’s ordinary rate. Base’s tax deployment uses its own bound launch-buy adapter and reuses the configured Base SwapX router. Do not reuse the Standard adapter: its immutable Factory and Hook bindings differ. Successful execution with a specific route does not prove that every aggregator supports custom Hooks, every stock quote or every funding path. Ordinary ERC-20 transfers are untaxed. Unrelated pools without this Hook do not pay its fees. The Hook-data comment retains its existing offset after the 20-byte address slot. Inclusive Tax ignores that slot financially and emits a zero financial referrer; integrator attribution comes from launch configuration, never the swap caller’s referral field.

​
Dividends and batching

Resolve the token’s clone with dividendOf(token) and verify its token, factory, Hook, FeeEscrow, PoolManager and fixed helper bindings. A zero clone address means dividends are disabled.

​
Reward assignment

The Hook credits the clone’s quote-currency escrow entry and calls notifyDividendFee(amount) during fee accounting. That notification assigns rewards to the shares recorded at that exact checkpoint. Claiming does not perform another allocation. Newly delivered buy tokens normally participate from subsequent fees; an existing eligible balance may earn from that buy. Seller participation depends on whether input tokens were transferred before or after the Hook’s checkpoint. Use the actual route and callback order, not a universal pre-trade or post-trade snapshot assumption. Transfers settle previously earned rewards before changing the holder’s shares. A new balance cannot collect earlier trading rewards. Small amounts use the contract’s magnified integer accounting and conservative rounding; rounding residue is not reassigned to later buyers or protocol merely because individual claims round to zero. If totalShares() is zero, the Hook credits that trade’s dividend portion directly to the launch’s frozen protocol recipient and emits DividendTaxRedirected. There is no holder allocation or second ledger in this case. The recipient claims it through ordinary Fees, together with its other credits for that currency. The ordinary protocol clamp does not cap this separately attributed dividend portion.

​
Individual and Claim all withdrawals

  • withdrawDividends() claims for the caller and unwraps whenever rewardToken is the wrapped-native token, including a WETH-paired launch.
  • withdrawDividendsFor(holder, unwrapWrappedNative) permits only that holder or the exact fixed helper. Authorization runs even when no amount is payable.
  • Excluded holders and zero entitlements return false without payment. A payout failure reverts the claim.
To keep WETH as WETH, call withdrawDividendsFor(yourWallet, false). The app selects this behavior for WETH pairs and native payment for ETH pairs; the no-argument contract function does not infer that UI preference. For cross-token Claim all, use TaxDividendClaimHelper.claimDividends(Claim[]). Each claim contains token and unwrapWrappedNative. The helper derives the holder from msg.sender, validates the full batch against its registry and clone bindings, rejects duplicates and permits 1 to 64 unique tokens. It returns (paidCount, bool[] paid). One failed withdrawal reverts every payment and funding operation in that helper transaction. A zero-payment entry can succeed without increasing paidCount. Earlier independent transactions are unaffected. Use confirmed DividendPaid events for payment amounts; the helper’s count is a summary, not an amount or a promise that simulation results remain current. Smart wallets must execute as the wallet entitled to the rewards. Recorded receivers remain authoritative. The helper holds no rewards, cannot select arbitrary holders and cannot execute arbitrary calldata. Claims require no token approval, Permit2 or extra signature authorization. Generic Multicall3 is not a trusted claim helper.

​
Automatic claim funding

If the clone already holds enough backing, it pays from that balance. Otherwise, it redeems its entire outstanding quote-currency entry through unchanged FeeEscrow.claimFor, pays only the claimant’s earned amount and retains the rest for other holders. Funding moves previously reserved fees; it neither assigns new rewards nor removes the locked liquidity position. Simulate the exact claim. An aggregate deficit does not necessarily block a smaller claim, and zero deficit does not guarantee successful receiver, token or wrapper transfers. Exceptionally large full-entry escrow redemptions retain the signed settlement limit; partial redemption is not supported.

​
Reward contributions and backing

Anyone may call depositDividends(amount) to contribute new rewards to holders eligible at execution. It measures the actual received amount, then allocates it. A zero amount or no eligible shares returns false without taking funds. Temporary holdings can participate in a voluntary contribution; there is no holding-duration requirement. replenishBacking(amount) restores assets without assigning new entitlements. It works even with zero current shares; excess replenishment does not create a refund right. A plain donation also does not create new rewards. Use replenishment, rather than a new dividend deposit, to replace backing removed through recovery. Both contribution functions pull the clone’s fixed ERC-20 rewardToken and require an allowance to the clone. Native-quote contributions therefore use wrapped native, not transaction value. Other token transfers do not become rewards for that quote. These contribution allowances are unrelated to approval-free claims.

​
Exclusions and administrative controls

Mandatory exclusions are zero, the dead address, the token, its Dividend clone, factory, Hook, FeeEscrow, PoolManager and fixed claim helper. Additional defaults are copied only into future clones. For an existing launch, the factory owner or creator administrator uses setLaunchDividendExclusions(token, accounts, excluded); mandatory exclusions cannot be removed. Default and per-call address batches are bounded to 64. Verify V2 pair addresses through a trusted factory’s getPair, V3 through getPool for each relevant pair and fee tier, and shared custody through authoritative manager or vault identities. Excluding a factory or router does not exclude its pools. Alternative paired assets need their own checks. Do not trust pool-like getters alone or exclude all contract wallets. The configuration snapshot lists Base’s additional defaults. Unknown pools may still earn until excluded; claim authorization does not remove their shares. Exclusion preserves previous earnings but blocks claims while excluded. Re-inclusion uses the current balance and resumes future eligibility without backfilling excluded periods. The other owner/creator-admin operations are refreshLaunchDividendShares, setLaunchDividendReceiver, emergencyWithdrawDividendAssets, adminSetCreatorFeeRecipient and adminReassignCreatorRights. Receiver changes do not authorize strangers to claim. Recovery may remove unpaid backing without erasing liabilities; these are explicit trusted administrative powers.

​
Burn redemption

Read FeeEscrow.owed(0x000000000000000000000000000000000000dEaD, token) and optionally call claimFor for that same pair. Anyone may call; payment goes to the dead address. The entire recipient/currency ledger entry is redeemed, and other recipients remain untouched. It does not reduce totalSupply. The Hook mints ERC-6909 claims and credits escrow during swaps; it does not physically transfer burn tokens during settlement. A separate failed redemption preserves the completed swap and credit. An uncaught redemption failure composed into the same transaction reverts the whole transaction. Ordinary FeeEscrow claimFor remains permissionless, and claimTo remains caller-owned.

​
Events and accounting

DividendsAllocated records automatic reward assignment from trading fees or voluntary contributions; it does not require a separate distribution action. Match DividendTaxRedirected to its pool, quote currency, frozen recipient and corresponding escrow credit within the same swap interval. Count the dividend portion once, either to the clone or to protocol, including when recipients overlap. Protocol redemptions aggregate categories and cannot prove which source was withdrawn first. Do not count a specialized credit and the corresponding generic escrow credit as two fees. Do not count escrow funding of a Dividend clone as payment to a holder. Burn allocation and dead-address delivery are different records. Zero credits emit no credit event; a successful swap still emits its Trade event. Index by (chainId, transactionHash, logIndex), retain originating suite and clone bindings, and handle replay/reorgs without duplicating balances. Pair Trade with PoolManager deltas and transaction context for direction and trader identity; Trade.executor is not necessarily the user. Do not add raw burn tokens to quote-denominated fee totals. Trading eligibility follows the Hook’s actual checkpoint; voluntary contributions and unknown-pool participation have the boundaries described above.

​
API and compatibility

Use GET /config?chain_id=8453&launch_product=tax&active_only=false. New launch requests set launch_product: "tax" and tax.format: "inclusive"; see the exact example. The API’s dividend prepare endpoint returns independent transaction steps, not the UI helper’s atomic cross-token batch. Use operation: "claim" for fee-accrual tokens. Distribution is not a separate current-suite action. See Dividend API actions. The registry’s contractVersion: "tax-token-v1" is an internal ABI-family identifier, not the deployment version. The current deployment is base-mainnet-tax-token-v2, with taxAbi: "inclusive" and dividendAccounting: "fee-accrual". Use all these fields and the exact contract addresses when selecting interfaces. The historical registry retains earlier identities for event recognition and direct recovery. Index-only deployments are not public launch or transaction-preparation targets. Never route their tokens to the current contracts. Decode each deployment with its own ABI and accounting capability; shared version-family names do not make Dividend behavior interchangeable.