How a Pallet pack works

Most fee-sharing tokens promise a buyback. Pallet makes the buyback the product: the tax on every trade buys a basket of Base coins, and the basket is distributed to the people holding the pack token.

The launched token is an ordinary ERC-20 with a trading tax, created through the o1 Launchpad Tax suite. Its creator-funds allocation is paid in the pool's paired asset — ETH on an ETH pair — and credited to a vault instead of a person.

o1's Tax product is the only piece of infrastructure that gives a coin a native, on-chain ETH revenue stream with a recipient you can set at launch. That is exactly the primitive a pack needs.

• Creator funds in ETH. The allocation is denominated in the paired asset, so the vault never has to sell the pack token to get its budget.
• Permanent liquidity. The full 1B supply opens into a Uniswap v4 position owned by the launch hook. There is no LP token the creator can withdraw.
• Predictable protocol take. o1 keeps 10% of the selected tax, clamped to 0.5–1% of trade value. The rest follows the creator's allocation split.
• Base economics. Cheap gas makes a 15-minute keeper loop realistic, and Base has the deepest set of memecoins to put in a basket.

Note: Pallet deliberately uses creator funds, not o1's holder dividends allocation. Dividends pay eligible holders in ETH automatically — great, but it cannot pay a basket. The two can be combined: a pack can route 80% to creator funds and 20% to dividends.

Tax is set per side at launch. Each side is the total tax in the launch pool, including the protocol share. Protocol takes 10% of the tax, with a floor of 0.5% and a ceiling of 1% of trade value; the remainder is split across the creator's allocations.

In plain English: 78% of what's left after o1's cut goes to buying the basket. The rest pays for the burn, the creator, the platform, and the keeper.

The remainder is then divided by the pack's allocation, fixed at launch:

cargo (to basket)   78%   swapped across slices on every sweep
buy & burn $PACK    10%   bought from the pool, sent to $Pallet (0x269b…3901)
treasury (creator)  9.5%  creator's claimable slice
platform fee        0.5%  Pallet treasury (buy & burn $Pallet)
gas                 2%    keeper reimbursement

A 6% tax at $10,000 of daily volume produces $600 of tax, $60 of protocol fee and $540 of cargo. Pallet takes ~$2.70/day in platform fees (0.5%) — enough to buy back & burn $Pallet. At 100 active packs, that's $270/day of platform revenue.

Pallet is a launchpad and router, not a custodian. Every fee is on-chain, immutable, and visible. Here is exactly where the money goes:

Admin transparency: all revenue flows through on-chain vaults. The Pallet treasury (launch fees + 10% treasury slice from every pack) is visible on-chain. There is no hidden fee, no proxy, no admin override on the vault. The only mutable surface is this documentation and the frontend — the contracts are immutable.

Revenue model: launch fees are one-time. The real revenue is the 10% treasury slice from every pack's trading tax, compounding across all live packs for as long as they trade. A pack doing $10k/day at 6% tax generates ~$60/day in protocol fees, of which $6 goes to the Pallet treasury slice. At 100 active packs, that's $600/day.

PackVault is deployed before the launch and its address is passed as the creatorFeeRecipient. It is not upgradeable and has no owner. Everything it can do is fixed in the constructor:

struct Slice { address token; uint16 weightBps; }

constructor(
  address basketRegistry,   // o1 launch factory, used to verify the token
  Slice[] memory slices,    // immutable, must sum to 10_000
  uint16 packShareBps,      // 7800
  uint16 burnShareBps,      // 1000
  uint16 treasuryBps,       // 1000
  uint16 gasBps,            // 200
  address treasury,
  address swapper           // routing adapter, allowlisted
)

Before the first sweep the creator calls bind(token). The vault verifies through the o1 factory that the token exists, that the caller is its creator, and that the vault is the recorded creator-fee recipient. The token address can be set exactly once — that is the only mutable slot in the contract.

• No admin. No function can change a slice, change the split, or move the basket out.
• Swap adapter is fixed. The router allowlist is set at construction, so a compromised keeper cannot route funds through an arbitrary contract.
• Accounting is per epoch. Cargo is priced into an epoch before it is claimable.

Every 15 minutes the keeper runs one transaction that does five things, or none:

1. escrow.claimFor(address(vault), currency)   // pull accrued ETH
2. if balance < minSweep, return                 // don't burn gas on dust
3. swapper.swap(eth → slice[i], weight[i])       // one route per slice
4. take gas + treasury slices                    // keeper + creator
5. distributor.commitEpoch(root, totalSupply)    // snapshot + merkle root

The snapshot is taken from the o1 holder index at the sweep block. Balances are normalised against eligible supply, then written as a Merkle root. A holder claims by presenting (epoch, token, amount, proof) — or by calling claimAll, which loops a bounded batch of assets in one transaction.

Why manual claiming instead of auto-airdrop? Because auto-airdrops would cost more in gas than the yield itself for most holders. Ten ERC-20 transfers to 2,000 holders is ~20,000 transfers per day and turns most payouts into sub-cent dust. Epoch claims move the same value for cents, on the holder's schedule. Your yield never expires — it accumulates until you claim.

Pallet has a native token: $Pallet. It is not a governance toy — it has three concrete utilities that tie it to the platform's revenue.

Supply: 1 billion, hard-capped. No inflation, no minting. The burn mechanism has room to work because the supply is large enough that each buyback is meaningful.

Allocation: 40% liquidity/public launch, 20% staking rewards, 20% treasury (locked), 15% team (vested 1-2 years), 5% initial burn on day one.

Why $Pallet doesn't dilute the packs: It never competes with pack tokens. Packs generate yield; $Pallet captures a cut of the platform fees. You buy packs to earn basket coins, and you hold $Pallet to earn a share of the factory's revenue. They feed each other — the packs drive platform fees, which buy back $Pallet, which makes staking more valuable.

The frontend is app-first in this build; the contract surface below is what it is designed against.

contracts/
  PackVault.sol        claims o1 creator fees, swaps, splits, commits epochs
  PackRegistry.sol     factory: deploy vault + bind to a launched token
  MerkleDistributor.sol per-pack epoch roots, token claims, claimAll
  Swapper.sol          router adapter (o1 swap / Uniswap v4), fixed allowlist
  interfaces/
    IO1FeeEscrow.sol
    IO1LaunchFactory.sol
    IPackVault.sol

keeper/
  index.ts             interval loop, reads packs, simulates, sweeps
  snapshot.ts          holder index → normalised shares → merkle tree
  pin.ts               publishes epoch manifests (root, buys, txs)

app/                   Next.js 16 · React 19 · Tailwind v4

Keeper guarantees

• Simulates each sweep before sending; skips packs below minSweep.
• Never holds funds: the vault does the swapping and the distributor holds the cargo.
• Publishes the epoch manifest so anyone can rebuild the Merkle tree independently.
• Retries with a fee cap; no private key has authority over the basket.

Frontend integration points

• o1 public API for launch preparation, quotes and holder snapshots.
• Wallet writes: launch, bind, sweep, claim. All calldata is prepared server-side and simulated.
• Reads: factory events, hook fee credits, distributor roots, escrow balances.

1. Pick the basket and weights. Under 6 slices keeps sweeps cheap; 10 is the cap.
2. Choose the tax. 6–8% per side is the working range; higher tax suppresses volume.
3. Set the split. 78/10/10/2 is the default cargo/burn/treasury/gas mix.
4. Deploy the vault first, then pass its address as creatorFeeRecipient in the o1 launch params.
5. After launch, call bind(token) and verify the vault shows up as the fee recipient.
6. Run one manual sweep before the keeper is live; confirm the epoch root and a test claim.
7. Publish the basket hash, vault address and keeper address. They never change.

• Basket risk. Memecoins go to zero. A pack is a leveraged bet on its slices, and the tax makes trading out expensive.
• Tax suppresses volume. The fee stream is a function of volume you may not get.
• Snapshot lag. Holder shares are read at the sweep block; indexer lag can delay an epoch, not change it.
• Router risk. Swaps depend on liquidity and the allowlisted adapter. Slippage bounds are enforced per slice.
• o1 dependency. Creator credits, fee escrow and claim semantics are o1's contracts. Policy changes affect future launches, not existing pools.
• Regulatory. A token that pays holders from trading fees may be a security in some jurisdictions. This is not legal advice.

This repository currently ships the product surface: landing, pack discovery, pack detail with sweeps and holder registry, the full launch wizard, terminal, portfolio and claims — all interactive against deterministic demo data.