Every token launch repeats the same four chores: airdrop the community, vest the team, pay a batch of contributors, split ongoing revenue. Teams either write these from scratch — risky, audited nowhere — or stitch together abandoned one-off contracts.
Token Tools ships all four as small, OpenZeppelin-based primitives behind factories that take a tiny, hard-capped fee per use. The differentiator is the accounting, not the feature list:
- Fee-on-transfer-safe by construction. Balances are measured, never
assumed — factories fund grants and distributors from a before/after
balanceOfdelta, and vesting reads its allocation from the contract balance. A token that skims on transfer still vests and distributes exactly what arrived. - Funds conserved, nothing over-releases. The payment splitter's conservation and no-over-release properties aren't just claimed — they're pinned by two stateful invariants run over random deposit/release sequences.
- Second-preimage-safe Merkle leaves. Claim leaves are an 84-byte preimage; internal nodes are 64 bytes, so a node can never be forged into a claim.
- No admin path to user funds. Multisend and the splitter never custody user funds; the airdrop owner can only sweep unclaimed balance after expiry; the vesting owner can only revoke grants that opted in, and vested tokens stay with the beneficiary.
The four:
- Merkle airdrops — bitmap claims, sweep-after-expiry, batched
claimMany. - Vesting — linear + cliff + optional revoke, fee-on-transfer safe.
- Multisend — batch ERC20/ETH payouts, no custody, dust refunded.
- Payment splitter — pull-based ETH/ERC20 revenue split.
Fees are bps-of-amount (capped at 1%) or a flat ETH creation fee (capped at 0.05 ETH) — small enough that using the suite is a no-brainer, structural enough that revenue scales with every deployment and every payout. Foundry-tested (61 tests, fuzz + stateful invariants), MIT, unaudited — review before deploying with real funds.