Castellum

Token launches usually end where they should begin. A sale distributes supply, liquidity is seeded, and from then on holders own a claim on nothing but sentiment. Castellum makes the claim concrete: each launch ships with a vault that any party can pay into, and a router that splits every payment between stakers, the creator, and the protocol. Trading fees, partner airdrops, and off-chain revenue all arrive through one address, so a token can accrue value without a transfer tax, a rebase, or a discretionary treasury.

Three failure modes recur. First, distribution is decided by gas: on chains with a priority auction, an allocation goes to whoever pays most for ordering, not to the community. Second, overflow is handled by reverting — the tail of a race pays gas for nothing. Third, post-launch value accrual is bolted on with token taxes that break composability, or with a multisig that promises to buy back later.

Robinhood Chain removes the first problem and sharpens the others: the sequencer is first-come-first-served, so priority cannot be bought, which means fairness has to be expressed in contract logic rather than in fee markets.

A launch is one transaction against a single registry. The Launchpad mints the token to a deterministic CREATE2 address and deploys three EIP-1167 minimal clones, wiring their permissions in the same call. Nothing is proxied for upgradeability — a clone is a fixed delegate to immutable template bytecode, and the templates have no admin.

  contribution ──▶ Sale ──finalize──┬──▶ creator
                                    ├──▶ liquidity recipient
                                    └──▶ treasury (protocol fee)

  fees, airdrops ──▶ RewardRouter ──┬──▶ RewardVault ──▶ stakers (pro rata)
                                    ├──▶ creator
                                    └──▶ treasury

A sale has two rounds with independent windows, allocations, caps, and vesting: a merkle-gated private round and an open public round. Price inside a round is fixed by construction, so no participant can be filled at a worse rate than another.

price   = hardCap / tokensForSale
tokens  = contribution × tokensForSale / hardCap
accepted = min(contribution, hardCap − raised, maxContribution − contributed)
refund   = contribution − accepted        // returned in the same call

Refunding the overflow rather than reverting is the important detail: under FCFS sequencing the block that closes a round contains a burst of contributions, and reverting them would make the last honest buyer pay gas to lose. Per-wallet minimums and maximums bound the distribution, and the merkle root can be rotated by the creator until the private round opens.

At finalize, proceeds split into a liquidity reserve, the protocol fee, and the creator's share; unsold tokens are returned. If the combined raise misses the soft cap, or the owner cancels, the sale enters refund mode: contributions are withdrawable and no tokens are claimable. Vesting, where configured, releases linearly after a cliff measured from finalization.

The vault holds one staking asset and pays out an arbitrary set of reward assets. It uses the standard pull-based accumulator, one per reward token, so a deposit is O(1) regardless of how many wallets are staked.

accPerShare[r] += amount × 1e30 / totalStaked
claimable[u][r] += balance[u] × (accPerShare[r] − userAccPaid[u][r]) / 1e30

Two edge cases are handled explicitly. Rewards notified while totalStaked is zero would divide by zero and be lost, so they are queued and folded into the accumulator on the next notification. And because every balance-changing action settles every registered reward token, the registry is capped at 32 assets — an unbounded list would let a griefer make staking unaffordable. Only whitelisted notifiers can register a new asset.

Stakes carry a per-launch lock, reset on each deposit, up to a year. Reward claims are never locked.

The router is the protocol's public inlet. Anyone — a partner project running an airdrop, a fee hook forwarding swap revenue, the creator paying out off-chain income — approves it and calls deposit. The deposit is split by basis points into the vault, the creator, and the treasury, then the vault is notified so the accumulator advances immediately.

Because the inlet is permissionless and asset-agnostic, a creator token becomes a claim on a growing bundle rather than on one revenue line. The token itself stays a plain ERC-20 with no hooks in its transfer path, so it remains usable in any pool, bridge, or wallet.

Protocol fee

2.00% of sale proceeds

Protocol reward cut

5.00% of routed deposits

Creator reward cut

Set per launch

Max reward assets

32

Max lock

365 days

Rounds per sale

2 (private, public)

Quote assets

Native ETH or any ERC-20; USDG by default

Reentrancy

Transient-storage guard (TSTORE)

No external review yet. The contracts have a full unit and mainnet-fork test suite, but test coverage is not a substitute for an audit, and that remains the dominant risk.

Privileged roles. The protocol owner sets fees, can cancel a sale, and can pause staking; the creator controls their own merkle root, finalization, and reward split. The owner role is intended to sit behind a Safe multisig.

Creator risk. Castellum does not vet anyone. A launch can be honest in its mechanics and worthless in its substance, and no contract can fix that.

Nothing here is an offer, solicitation, or investment advice. Participating in a launch can lose you everything you contribute.

Live

Issuance, two-round sale, multi-asset vault, reward router

Next

Uniswap v4 pool bootstrap with a fee hook paying the vault

Then

Hosted merkle proof service, index vault across launches, indexer API

Before scale

Safe multisig handover, external audit