The liquidity lock
Every launch's liquidity is locked at deploy time. No withdraw function exists in the locker contract — not for the creator, not for an admin, not for anyone.
Atomic with the launch
The factory deploys the token, creates the pool, deposits the initial liquidity, and calls lock() in a single transaction. The locker's lock function accepts one call per token, and only from the factory. A launch that fails to lock reverts entirely — there is no window in which a pool exists unlocked.
Why there is no unlock
The usual pattern is a timelock: liquidity is locked until a date, then the creator can take it. That is a delay, not a guarantee. The locker here implements no withdraw, unlock, release, emergency, migrate, or sweep function in any form. Because the code does not exist, no key, multisig, governance vote, or future decision can call it.
The contract also has no owner and no admin role, and it is not deployed behind a proxy — the bytecode at the address is final. There is no selfdestruct.
- + lock(token, amount) — factory only, once
- + collectFees(recipient) — routes fees to escrow and split
- + positionOf(token) — read-only view
- − withdraw / unlock / release
- − owner / admin / setOwner
- − upgradeTo / proxy delegatecall
- − selfdestruct
Fees still flow
The locked position keeps earning trading fees, and collectFees routes them to fixed destinations set at deploy: the runtime escrow, the creator's claim balance, and the protocol share. Collecting fees never touches the principal, and the destinations cannot be edited after launch.