Skip to content

Documentation

The rule.

Everything below is what the contracts do, not what we intend. Where the site says “anyone can”, it means the function has no access control.

One rule, fixed at launch

A launch through Lockpad is one transaction that deploys two contracts and then launches on Pons V2 with both wired in. The fee lock is registered on Pons as the token's creator-fee recipient. The vesting contract is the recipient of the developer buy. Neither has an owner. The router can name their token and curve exactly once, in that same transaction, and never again.

The creator chooses two numbers: how long the developer buy vests (7365 days) and how long the curve has to graduate (390 days). Everything else — the 30-day fee vest, the 10% pad share, the burial mechanics — is a constant in the code.

Developer vesting

Pons' launch forwarder can buy the developer allocation in the launch transaction and deliver it to any address. Lockpad makes that address a fresh DevVesting contract. The tokens unlock linearly from the launch timestamp over the chosen duration; anyone can call release() and it always pays the beneficiary. There is no cliff, no clawback and no acceleration.

The forwarder exempts its buy recipient from Pons' snipe tax, so the vesting contract buys at the clean price. The creator's wallet is not on the exempt list — the router passes an empty one — so a second wallet buying at launch pays the same tax as everybody else.

The beneficiary can hand the role to another address in two steps (proposeBeneficiary, then acceptBeneficiary from the new address). That changes who is paid, never when.

Fee lock

Pons collects a 1% fee on every curve trade (plus the optional creator tax) and sweeps the creator's share to its fee escrow on its own schedule; graduation triggers a sweep. The lock pulls its escrow balance whenever anyone calls it. From there:

  1. Before graduation, nothing leaves. release() reverts.
  2. Graduation is recorded the first time the lock sees curve.graduated() true — through checkpoint() or any release. Anyone can call it; the token page offers the button.
  3. From that moment, everything the lock has received and will receive unlocks linearly over 30 days. Each release() pays the unlocked amount: 90% to the creator, 10% to the pad treasury. After the vest, releases pass everything through.
  4. If the deadline passes without graduation, the lock can be buried (below). A buried lock never releases again — not to the creator, not to the pad — and everything that arrives later is buried too.

Graduation and burial are exclusive: a lock that recorded graduation cannot be buried, and a buried lock ignores a later graduation. The creator role has the same two-step hand-over as the vesting.

Burials, and why they are sliced

bury() spends the lock's ETH buying the token back on its own curve and sends the tokens to 0x…dEaD. It is an open call on a public curve, so it has to survive being front-run. Instead of a slippage parameter — which a hostile caller would set to zero — the size of each burial is bounded: at most 2% of the curve's quote reserve (virtual liquidity included) per call, and calls at least 1 hour apart.

The bound is what makes it safe. Moving the price by some fraction p takes roughly p × reserves of capital and costs the 1% fee twice (in and out), about 2% × p × reserves. The most a sandwich can extract is p × slice. With the slice under 2% of reserves, the fee exceeds the gain at every p, so the attack loses money. The hourly spacing stops an attacker from recombining the slices into one large buy under a single pump.

A burial is itself a trade, so 1% of it comes back as a creator fee — into the same lock, to be buried an hour later. The series converges; the token page shows the running total.

Trading

Every token page has a buy/sell panel. It is a direct call to the token's Pons curve — the pad is not in the path and takes nothing from a trade. Quotes are computed from the curve's reserves (an exact constant product with 1.68 ETH of phantom liquidity, fee off the input on a buy and off the output on a sell), and the minimum you accept is that quote less your slippage setting. Selling needs a one-time token approval first.

Pons charges 1% per trade, 70% of which is the creator fee — the part that lands in this token's fee lock. Buys in the first minutes after launch also pay Pons' snipe tax unless the buyer is exempt; the panel shows the current rate for your address. After graduation the market moves to a pool and the panel points to Pons.

The numbers

Developer vesting
7–365 days
creator's choice, linear, no cliff
Graduation deadline
3–90 days
creator's choice, from launch
Fee vest
30 days
constant, from the recorded graduation
Pad share
10%
of each release, fixed inside the lock
Burial slice
2% of quote reserve
one call per 1 hour
Pad launch fee
0 ETH
Pons charges 0.0005 ETH
Graduation
4.2 ETH raised
set by Pons
Snipe-tax exemptions
vesting contract only
the creator's wallet is not exempt

What the pad takes

10% of what the creator unlocks, taken by the lock at release time and sent to the router's treasury address in the same call. Nothing at launch, nothing while fees are locked, nothing from a burial. The share is an immutable in each lock; changing the router's constant would only affect locks created afterwards. The router's owner can pause new launches, move the treasury address, and set a launch fee (zero). That is the whole admin surface.

Contracts

LockpadRouter
TBA
Chain
Robinhood Chain · id 4663

Per-launch addresses (token, curve, fee lock, vesting) are on each token page and in the router's infoOf(token). lockStatus(token) returns both locks' state in one read — it is what this site renders. Source: contracts/ in the repository, with the test suite and the fork rehearsal against the live Pons factory.

Questions

Can the creator still rug with another wallet?

Partly, and it is worth being exact. What the locks stop: dumping the developer buy (it is vesting, in public) and taking the creator fees early (they are locked until graduation, and buried if it never comes). What they do not stop: the creator buying from a second wallet like anyone else and selling later. That second wallet gets no exemption from Pons' snipe tax — the only exempt buyer is the vesting contract — so it pays what every other early buyer pays. Lockpad makes a rug expensive and visible, not impossible.

What exactly happens at graduation?

Pons graduates a curve when it has raised 4.2 ETH and moves the market to a pool. The fee lock does not know about that until someone calls checkpoint — anyone can, and the token page does it for you. From the recorded moment, everything the lock has received and everything it receives later unlocks linearly over 30 days. After that, each release pays out whatever has arrived.

Why record graduation instead of reading it live?

Because a vesting schedule needs a start time, and the curve reports a flag, not a timestamp. Recording it on the lock when first observed gives every later calculation one fixed reference that nobody can move. The cost is that a creator who forgets to checkpoint starts their vest late — which is why the site makes it a one-click call that anyone can make.

What does 'buried' mean, precisely?

Once the creator's deadline passes and the curve has not graduated, anyone can call bury. The lock pulls whatever Pons has swept to it, spends at most 2% of the curve's quote reserve buying the token on the curve, and sends the tokens to the dead address. It can be called again an hour later, and again, until the lock is empty. A buried lock never releases to the creator or to the pad — including fees that arrive afterwards.

Why bury in slices instead of all at once?

Because a burial is an open call on a public curve. Moving the price by some fraction costs an attacker about twice the 1% trade fee on the capital it takes to move it, and wins them at most that fraction of the slice. When a slice is under 2% of the reserves the fees exceed the gain, so sandwiching a burial loses money — regardless of any slippage setting, which is why the call has none.

Where are the fees before they reach the lock?

On the curve. Pons collects the trade fee on every buy and sell and sweeps the creator's share to its fee escrow on its own schedule (graduation triggers a sweep too). The token page shows three figures: accruing on the curve, pending in the escrow, and held by the lock. Only the third is subject to the schedule; the first two are still Pons' to move.

Can the router's owner change a lock?

No. The router has an owner for three things: pausing new launches, moving the pad's own treasury address, and setting a pad launch fee (zero). Each lock is a separate contract with no owner at all; its deadline, vest duration and pad share are fixed at deployment. The router can name a lock's token and curve exactly once, in the launch transaction, and never again.

What if the creator loses their wallet?

Both locks let the current creator propose a new address, which must accept — a two-step hand-over, so a typo cannot lose the role. It changes who is paid; it never changes when or how much.

Is Lockpad a Pons product?

No. Lockpad is middleware: the router calls Pons' public factory and forwarder, which accept launches from any address. Pons takes its usual fee and runs the market; Lockpad only decides where the creator fees and the developer buy land. Nothing about the token itself is different — same curve, same graduation, same pool.