Introducing Castellum

Most token launches treat the sale as the finish line. Supply is distributed, a pool is seeded, and from that moment the token is a claim on nothing but attention. The project may go on to earn real money — trading fees, partner airdrops, subscription revenue — but none of it has a defined path back to the people holding the token. What usually fills that gap is a transfer tax, a rebase, or a treasury that promises to be generous later.

Castellum starts from the opposite assumption: the interesting part begins after the sale. A castellum was the distribution tank at the end of a Roman aqueduct — one inflow, several measured outflows, each one auditable. The protocol does the same thing with a project's revenue.

One transaction deploys everything a project needs. The Launchpad writes a registry entry, mints the token at a deterministic address, and clones three templates — a sale, a staking vault, and a router — already wired to each other. Nothing is upgradeable, and no contract in the set can move funds you have not deposited.

The clones are EIP-1167 minimal proxies, so a launch costs a fraction of a full deployment and every clone runs the same bytecode as the template you can read on the explorer.

A sale runs a merkle-gated private round followed by an open public round. Both are fixed price: the first contributor and the last pay identically, which removes the incentive to fight for block position on a chain that sequences transactions first-come-first-served.

tokens = contribution × tokensForSale / hardCap

Each round enforces a per-wallet minimum and maximum. A contribution that would cross the hard cap is accepted up to the cap and the remainder is refunded inside the same transaction, so a race at the close costs you nothing. If the combined raise ends below the soft cap, the sale flips to refund mode and no one — including the creator — can override it. Rounds can vest, with a cliff and a linear unlock after it.

Contributions are collected in native ETH or an ERC-20; the app offers the Paxos USDG by default, because several impostor tokens share the symbol on the explorer.

Every launch gets a router with one public entry point. Anyone — a fee hook, a partner project running an airdrop, the creator settling off-chain revenue — can pay into that address, in any asset. The router splits each deposit between the vault, the creator, and the protocol treasury, and the vault credits stakers pro rata.

Accounting is pull-based: the vault keeps a per-token accumulator, so a deposit costs the same gas whether one wallet is staking or ten thousand are, and nobody needs a keeper to distribute anything. A vault tracks up to 32 reward assets at once, and rewards that arrive while nothing is staked are queued instead of lost.

Protocol fee on a raise

2%

Protocol cut of routed rewards

5%

Creator cut of routed rewards

Set by the creator at launch

Reward assets per vault

32

The chain settles in ETH with fees low enough that a full launch costs well under a cent, and it already has the pieces this design leans on: Uniswap v4 for the liquidity work still ahead, Permit2, Safe, and transient storage for cheap reentrancy guards. Just as usefully, its audience is financial rather than speculative, which is the audience a mechanism like this is for.

The Launchpad is live at 0x4429d348f66e30eA7F43e36e59678de9eED087b8 with verified source, and the app reads it directly — there is no indexer, no backend, and no account to create.

The liquidity desk is the next piece: a Uniswap v4 pool bootstrapped at the sale price with a fee hook that pays swap fees into the vault instead of a treasury wallet, which closes the loop between trading the token and holding it. After that, hosted merkle proof serving for private rounds, and an optional index vault that stakes a basket.

The contracts are deployed and reviewed internally, with a full unit and mainnet-fork test suite, but they have not been through an external audit. Read the risks before committing anything you cannot lose.