How Laptop works
Laptop creates a token and opens its market in the same transaction. This page is the manual. It says what the contracts do, in the order they do it, including the parts that are not flattering. Every number here is a constant you can read back off the chain yourself.
One launch, step by step
You fill in a name, a symbol, a picture, your links, and six settings: the pairing asset, the starting valuation, the trade fee, the pool fee, the reserve, and how long the reserve vests. Then one transaction does all of this.
- The reserve vesting is created first, if you asked for a reserve. It is created before the token exists, so the reserve can be minted straight into it. It never passes through a wallet, not even yours.
- The token is created. Not deployed as a contract: it is created through the Base token factory, as a native asset with no admin. The supply cap is set to exactly the 1,000,000,000 minted, the pool share is minted to the launcher, the reserve share into the vesting, and the vesting is granted the burn role. All of that happens inside the creation call, which is the only moment anything about the token can be set.
- The pool is opened. A Uniswap V4 pool is created and initialized for your token against the pairing asset, at the price your starting valuation implies, carrying the pool fee you chose and the Laptop fee hook.
- Everything left is seeded and locked. All supply that is not reserve goes into the pool as single sided liquidity, owned by the launcher contract, with no way out. Rounding dust goes to the vesting, or to you when there is no reserve, so no supply is stranded.
All four happen in one call. If any step fails the whole transaction reverts and nothing is created. The launcher takes no launch fee, so a launch costs gas and nothing else.
The token is a Base native asset
A Laptop token is not a Solidity contract someone wrote. It is created through the Base token
factory at 0xB20f000000000000000000000000000000000000, which
makes native assets: a complete token, with the ledger and the transfer rules held by the
chain itself rather than by code an author chose. Because it carries no custom code, there is
no constructor with a surprise in it, no owner variable, and nothing to upgrade.
No admin, at all
It is created with the admin set to the zero address, so there is no admin role for anyone to hold. Mint, pause, freeze, seize, blocklist and rename revert for every address on earth, forever, the launcher and the platform included.
Supply fixed at creation
The supply cap is set to exactly the 1,000,000,000 that is minted, at 18 decimals. A later mint is impossible twice over: there is nobody to call it, and the cap is already reached.
No transfer policy
A native asset can be born with a third party's transfer policy bound to it, which would let that party blocklist holders. Laptop never binds one, and with no admin one can never be added later. Transfers move the exact amount, with no tax anywhere.
One narrow exception
The launch's own vesting contract holds the burn role, and nothing else does. That is what makes the burn option on a reserve claim a real burn: total supply drops. It cannot touch a balance that is not its own.
What that buys a holder is short to say. Nobody can mint more of it, nobody can freeze your wallet, nobody can add a tax or change the token under you, and there is no key that could be stolen and used to do any of it. What it does not buy you is a safe price. The market is still a market, and the section on liquidity below is the part that decides what your exit looks like.
Where the picture and links live
A native asset also has no room for custom code, so it has no metadata, no creator field and no balance history of its own. Everything a launch knows about itself lives in the launcher instead: the picture, the description, the X account, the website and the Telegram, written at launch, editable by that launch's creator until they freeze them, and returned in the same feed row the board reads. The missing balance history is also why paying holders takes its own snapshot, which is further down this page.
The supply split and the reserve
Supply is fixed at 1,000,000,000 tokens. The reserve is
supply x reserve share / 10000, capped at 30%,
and the pool gets the exact remainder. Below is a launch with a
20% reserve.
Set the reserve to zero and the whole supply goes into the pool.
The reserve vests linearly from the moment of launch: nothing at the start, everything once the schedule has run, proportional in between. The launch form offers 1 to 365 days. The contract itself accepts anything from one second up to 1,460 days, so a token launched through another interface may show a schedule outside that range. Only the beneficiary can claim, the beneficiary starts as the wallet that launched, and it can be handed to another wallet but never to the zero address.
The seeded position belongs to the launcher contract. There is no function in the launcher, the token, the hook, or the vesting that can remove, transfer, or migrate it. The single function that touches the position at all moves liquidity by exactly zero: it can realize the fees the position has earned and nothing else. That is true for a test launch as much as for a serious one, so do not launch a token you were planning to unwind later.
What single sided liquidity means for a buyer
This is the part to read twice. A normal pool opens with both sides funded, so there is something to sell into from the first second. A Laptop pool opens with the token and nothing else. The seeded range sits entirely on the token's side of the starting price, and the pool opens at the very edge of that range, so the position is token, every unit of it.
Every unit of the pairing asset a pool holds is money a buyer paid in. Sells draw that same money back out. Until the first buy lands there is none of it, so on a pool that has never traded a sell of any size has nothing to fill against, down to a millionth of one token. After that, the entire sell side of the market is what earlier buyers left behind minus what earlier sellers have already taken out, and it is first come, first served. It can be far smaller than the price implies: a pool can still hold most of the supply and only a few units of the pairing asset.
Nobody is going to add the other side later. No hidden reserve appears, and no contract here can add or remove liquidity after the launch transaction ends.
Buys walk the price up through the seeded range, one tick at a time, and leave their payment behind in the pool. The range spans roughly 992 times the starting price. Push the price past the top of it and the position holds only the pairing asset, with no token left to sell you.
What happens to an order the pool cannot fill
The pool fills what its band can take and no more. An order larger than that is not priced at all by the public Uniswap quoter, which is what the trade panel asks for a number, so an oversized order shows as a size the pool cannot handle rather than as a price. A router that sends one anyway trades the part the pool takes and hands the rest straight back. That is exactly why the trade fee is charged on what a trade delivered rather than on what it offered: it is measured against the part that really executed.
Two consequences worth being plain about. Buying and selling straight back leaves you down by both fee layers plus the price you moved. And if a crowd sells at once, the last sellers find the price at the bottom and very little left on the other side. Size your position for that, not for the chart.
The two fee layers
Both are set by the creator at launch, both can be zero, and they live in separate places. The pool fee is the plain Uniswap fee and comes off what you put in. The trade fee belongs to the Laptop hook, and it is a share of what the trade delivered to you.
| Trade fee | Pool fee | |
|---|---|---|
| Range | 0% to 42%, flat | 0% to 4.2% |
| Charged on | the output of every swap, so always on what was delivered | the full input of every swap |
| Paid in | the launched token when you buy, the pairing asset when you sell | the pairing asset on buys, the token on sells |
| Lives in | the Laptop fee hook | the Uniswap V4 pool itself |
| After launch | can only be lowered, never raised, and only by the pool's fee recipient | never changes, because it is part of the pool's identity |
| Paid out | inside every swap | when anyone calls collect on that token |
Order inside a trade: the pool charges its own fee on your whole input, the swap runs, and then the hook takes its share of what came out. Buying at a 5% trade fee means 95 of every 100 tokens the pool priced for you arrive in your wallet and 5 go to the fee. Selling at the same rate means 95 of every 100 units of the pairing asset arrive and 5 go to the fee.
Because the cut is taken from the output, a partial fill can never be overcharged. The old arrangement charged the input before the swap ran, and an order the pool could only fill in part paid for input that never traded.
Both layers pay 90% to the wallet the launch names as its fee recipient and 10% to the platform wallet. The fee recipient is written once, at launch, and is permanent for that pool.
Swaps against these pools have to be exact input, so a trader says what they are spending rather than what they want to receive. Exact output is refused: on such a swap the delivered side is the one the trader pinned, so a fee taken from it would not be a fee on what they received.
A trade fee of 42% is allowed by the contract. It is also close to unusable in practice. Most launches sit in the low single digits, the figure is on the token page before anyone trades, and it can only ever go down.
Claiming the reserve
A claim takes everything vested and unclaimed at that moment and splits it three ways, in percent of the claimed amount.
- To holders. Paid out pro rata in the same transaction, against a snapshot taken at least 30 minutes earlier.
- Burned. Sent to the token's own burn, so total supply actually drops. This is the one thing the launch vesting has the burn role for.
- To yourself. Whatever is left after the other two.
Any mix is allowed, including all of one. The split you pick applies only to that claim; next time you choose again. Nothing is left over: rounding dust from the holders' share goes to the dead address rather than sitting in the distributor.
Paying holders takes two steps
A native asset keeps no balance history, so nobody can ask it who held what at a past block. The distributor takes its own reading instead, in the open, and the reading and the payout are separate transactions.
Anyone may call it. It records what each listed address holds right now and returns a snapshot id. The addresses and the balances go into the event, so anyone can check what was recorded and who was left out. The list has to be strictly ascending by address, which makes a duplicate impossible, and at most 1,000 entries.
The claim names that snapshot and pays each holder by the smaller of what they held at the commit and what they hold at the payout. Earlier than 30 minutes is refused as too young, and later than 30 days as too old.
The reason for the gap is worth stating. With a single reading taken at payout time, anyone on the list could buy heavily in the block before the claim and take most of the distribution, then sell again. Measured on a fork, one wallet captured 95% of a distribution that way. Two readings half an hour apart, with the smaller one counting, mean a share has to be genuinely held across the window rather than borrowed for a block. Selling in between lowers your share to what you still hold; buying in between adds nothing.
Some addresses are never paid: the pool, the distributor itself, the dead and zero addresses, the caller, and the vesting's own beneficiary. So sending a share to holders can never quietly mean sending it back to the creator. If nobody on the list is eligible the claim is refused rather than paid to nobody, which means a creator with no holders has to pick burn or keep. Before signing, the site can ask the distributor for exactly what it would pay, holder by holder, using the same rule the payout uses.
Pairing assets and the starting price
A launch pairs against native ETH, against USDC, or against one of the tokenized stock assets the operator has listed. ETH and USDC are allowed permanently and cannot be delisted. Beyond those, up to 20 stock assets can be listed at a time, each with a rank that sets the order they appear in on the form. The Coinbase stock tokens are themselves Base native assets, made the same way a Laptop token is.
Listing gates new launches only. A pool that is already open keeps trading exactly as it did, whatever the list says afterwards.
Reading the list.
Your starting valuation sets the pool's opening price. It is divided across the whole 1,000,000,000 supply, reserve included, so the price per token at the first tick is the valuation divided by the full supply. For ETH pools the form takes the figure in dollars and converts it; for the other pairings you enter it in the pairing asset.
What you control, and what nobody does
- Replace the picture, the description and the links, until they freeze them. Freezing is one way and permanent.
- Lower the trade fee, from the fee recipient wallet, as often as they like.
- Claim the vested reserve and choose the split at every claim.
- Hand the vesting beneficiary role to another wallet.
- Mint more supply, pause transfers, freeze a wallet or add a transfer tax.
- Remove, move or migrate the liquidity.
- Raise a trade fee, or change a pool's fee recipient.
- Change the pool fee, the pairing, or the starting price after launch.
- Take a holder's share of a distribution, or edit a committed snapshot.
The launcher has no owner, no pause switch and no upgrade path, and it refuses plain ETH transfers. The fee hook has an owner, whose entire power is the pairing list, binding the launcher once, and handing the role on. That owner cannot touch a pool's fee, its recipient, its liquidity, or trading. The only address that can burn a Laptop token is the launch's own vesting, out of its own balance.
Fees and payouts
The trade fee is pushed during the swap. If the receiving wallet cannot take the payment, a contract that reverts or a token that blocks the address, the amount is credited to that wallet inside the contract. It can be withdrawn by that wallet, and anyone at all can push a credit to the wallet it belongs to, so a recipient that cannot make calls of its own is never stranded. A trade never fails because a fee payout failed.
There is a second case for some pairings, where the router settles the input only after the swap and the pool manager does not physically hold the asset yet. The fee is parked as a claim, and anyone can flush it afterwards to the same two wallets it was always going to.
Pool fees sit in the locked position until someone collects them. Collecting is open to anyone and pays nothing to the caller: the money goes to that launch's fee recipient and the platform wallet, in the pairing asset from buys and in the token from sells. In practice the creator calls it, but a stranger calling it works just as well and costs the creator nothing.
Questions
Contracts
The stack goes on chain before launches open. Addresses appear here once it is live.