How it works

A coin whose fees run an engine

Every coin launched here has a vault: a contract that receives the creator fees and can do exactly four things with them. It cannot send them anywhere else, because there is no function for that.

Flow Split Engine Trustless or not What can go wrong Addresses

Flow

You launch on Pons, the chain's launch factory, through our hub in one transaction. The hub creates the vault first, then launches the coin with the vault as creatorFeeRecipient. Pons's own optional buyback is turned off, so the whole creator share reaches the vault. Nothing is bought inside that transaction: the Pons wrapper that used to do it refuses a zero buy on a stock pair and pulls the asset from the caller on a non-zero one, and the hub pulls nothing from anybody. The first buy is an ordinary trade on the coin's own curve, right after.
The curve is paired with the stock the coin bets on, not with ETH. Both pairs reach USDG in a single swap, so this is not about hop counts: it is that buyers on this chain already hold tokenized stocks, and that a stock fee balance is quoted exactly by our own v4 quoter, while an ETH one has to go through a v3 pool the keeper can only price off spot. ETH remains available as a choice, and the console says what it costs.
Every buy pays the pair's fixed 1%, of which Pons keeps 30%, plus a curve tax the creator picks at launch, which goes to the vault whole. At the default 3% the vault sees 3.70% of every buy; at 0% it sees 0.70%. The buyer pays it, the creator does not, and it can never be changed afterwards — not by the creator and not by us.
Every trade in the coin leaves a fee on the Pons curve, where it sits until someone sweeps it. sweepFees admits two callers: an operator Pons controls, and the curve's own fee recipient. On our coins that recipient is the vault, so the vault sweeps its own fees through sweepCurveFees(), which anyone may call. The engine does not wait on anyone else's schedule. Verified against a live curve on chain: the call succeeds from the fee recipient and reverts with NotFeeSweepOperator from every other address.
Once swept, the creator share sits in the Pons escrow, and anyone can call claim() on the vault. The escrow pays only to the vault, because the vault is the recipient on record.
split() divides what arrived by the shares fixed at creation: margin, burn, creator, treasury. Creator and treasury shares are pushed out immediately to the addresses baked into the vault.
The keeper routes the burn share into VOXEL through the pools the hub has allowed, and the vault sends the VOXEL to the dead address in the same call. The output token is a function of the bucket: the keeper cannot choose it.
The margin share is converted to USDG and deposited into Lighter, the perp venue, to an account that belongs to the vault's own address. The vault then places the order itself: market and side are immutables; the keeper only chooses size and price limit.
The order's size is not a guess. Lighter publishes a read API for this chain at api.rh.lighter.xyz, and an account is found by its L1 address — which is the vault. The keeper reads the collateral, the open size, the entry, the unrealised profit and the liquidation price, and adds only what is missing to reach the leverage fixed at creation.
When unrealised profit passes half the collateral, the keeper trims a quarter of the position, or the venue's minimum if a quarter is smaller than it. The realised amount then leaves in two steps, because Lighter settles through a queue: requestWithdraw moves it to the vault's pending balance on L1, and finalizeWithdrawal pulls it in on a later tick. Lighter can pay only the vault. The returned USDG is registered on arrival: up to the principal goes back to the margin bucket, the rest is profit, of which three quarters buy and burn VOXEL and one quarter goes to the treasury. A position in the red is never closed.

Split

The default preset is the one the copied launchpads use, and it is written into the vault as immutables at creation. A later change to the hub's presets does not touch existing vaults.

Share	Of each claim	Where it goes
Margin	50%	USDG on the vault's Lighter account
Burn	15%	VOXEL bought on allowed pools and sent to `0x…dEaD`
Creator	15%	The launching address, pushed on every split
Treasury	20%	Voxelithic treasury
Profit	75 / 25	Realized profit above the principal: burn / treasury

Engine

Lighter authorises createOrder, withdraw and changePubKey by msg.sender alone: the L1 address that owns the account is the account. A contract can therefore own a perp account, deposit into it, place orders and request withdrawals with plain L1 transactions, and the funds have no way back except withdrawPendingBalance to that same address. That is what makes the vault an engine rather than a wallet with a promise attached.

The first deposit registers the account. The vault stores the index and uses it for every order.
Orders are placed with the side fixed by the vault: a long vault can only buy to open and sell to reduce.
Positions are never closed at a loss by policy. The keeper cannot be forced to honour that on chain, but every order is an event on the vault and can be checked against the position.
The vault holds no Lighter API key. Fast withdrawals and transfers, which need one, are impossible by construction.

Trustless or not

Property	Guaranteed by	Trustless
Fees cannot be sent to an arbitrary address	No such function exists on the vault	yes
Split is fixed at creation	Immutables copied from the preset in the constructor	yes
Keeper cannot pick the output token or the destination	Output = f(bucket); pools from the hub's allow list	yes, against the keeper
Margin goes only to the vault's own account and back	deposit to self; Lighter pays withdrawals to the owner only	yes
Market and side of the position	Immutables; the vault is `msg.sender` on every order	yes
Order size, price limit, timing	Keeper policy	no, but auditable per order
Never close at a loss	Keeper policy; it trims only when the venue reports profit above half the collateral	no
Hub owner cannot drain	Can add a pool to the allow list only after a 24 hour delay; can change the keeper	partly
Pons keeps the vault as fee recipient	Only the recipient can reassign itself; the vault cannot. Pons's owner can, through a timelock	no, third-party risk
Fees reach the vault at all	The vault is the curve's fee recipient and sweeps itself; the call is open to anyone	yes
A coin's page points at that coin's real vault	Binding is refused unless Pons's own record names the vault as the coin's `creatorFeeRecipient`, and the curve address is taken from that record rather than from the caller	yes
A graduated coin keeps trading	Between the curve closing and the pool being created it trades nowhere; both steps are permissionless, so anyone can finish them	partly
Position survives	Leverage is leverage; a liquidation restarts the engine from the next claim	no

What can go wrong

Liquidation. A leveraged position on a tokenized stock can be wiped between two keeper ticks. The vault keeps working from the next claim, but the margin is gone.
The venue. Lighter is not ours. Downtime, a paused priority queue or a delisted market freezes the engine until it recovers. Deposits and orders sent from L1 go through a priority queue and land with a delay.
Market hours. Tokenized stocks trade with the stock. Outside them the engine still claims and burns, and orders wait.
The keeper. It can trade badly. It cannot take anything: every call it makes is a function of chain state, and the history on each coin's page is decoded from events, not from our database.
The snipe tax. For the first seconds of a coin's life Pons charges a tax on top of its fee, starting near 99% and fading to nothing. It is inside every quote we show, so the amount you see is what you get, but the first buyers of a fresh coin pay far more than the headline fee. The coin's page says so while the window is open.
The graduation gap. When the curve fills, it closes before the Uniswap v4 pool exists. In that window the coin trades nowhere. Anyone can close it — the coin's page offers the transaction — but until someone does, the market is shut.
Execution after graduation is not ours. A graduated Pons pool carries the Pons hook and is quoted in native ETH; our own router refuses both by design. The page quotes that pool with our quoter and then hands you calldata for Uniswap's UniversalRouter. We price it, Uniswap settles it, and the page says so on the button.
Reading the position is a dependency. Sizing an order and deciding to trim both need Lighter's read API. It is public and needs no key, but it is theirs, not ours. If it stops answering, the engine keeps claiming, splitting, burning and funding margin from chain data alone — it simply stops adjusting the position until the venue answers again.
The order is not the fill. Orders reach Lighter through a priority queue and settle off chain. What the vault emits is what it asked for, not what it got; the position the venue reports is the truth, and the two can disagree for a while.
No audit. The contracts are open and tested, and that is all that can honestly be said today.

Addresses

Read live from /api/v1/launches.