Skip to main content

pons — the closest thing to what we are building

Robinhood Chain (id 4663), EVM, graduates into Uniswap v4 behind a singleton hook. v2 is almost exactly our architecture, which makes it the most useful of the three. Source: docs.ponsfamily.com and its llms.txt. Public launching is currently closed — read canLaunch(address) on the factory.

v1, for context

No curve at all. The factory mints a fixed 1e9 supply and opens a Uniswap v3 pool at 1% fee in the same transaction, liquidity locked immediately. "Graduation" at 4.2 ETH is a label on the same pool, not a migration. Launch fee 0.0005 ETH. Creator/protocol fee split snapshotted at launch and never changed (currently 70/30, legacy 90/10). Anti-snipe is a two-block window: block 0 is the creator's buy only, blocks 1–2 cap each wallet at 5% held / 5.5% bought.

v2 replaced it with a curve. The v1 shape is a reasonable fallback to keep in mind — it is strictly simpler and it works.

v2 architecture — eleven contracts

contractscoperole
Launch FactorysingletonEntry point, launch config and phase state, graduation control
Launch DeployersingletonDeploys curve + token at CREATE2 addresses from a salt
Bonding Curveper launchConstant product, prices and settles pre-graduation trades
Launch Tokenper launchFixed supply, minted entirely to its curve at creation
Graduation GuardsingletonValidates the reserves can seed a valid pool
Graduation ExecutorsingletonMints the full-range v4 position straight into the locker
Launch LockersingletonHolds every graduated position and excess supply. No unlock function
Meme HooksingletonOne v4 hook for every pons pool. Accrues and splits post-graduation fees
Fee EscrowsingletonClaimable protocol and creator balances, ETH and ERC-20
Buyback VaultsingletonLocks bought-back tokens, linear release over 5 years
Launch and Buy RoutersingletonOptional atomic launch + first buy

Two contracts per launch, nine shared. That is the answer to "a factory is not a launcher" — they did not fit a stack into one initcode, they split deployment out into a deployer and kept everything else singleton.

One hook for every pool. beforeInitialize verifies the pool was registered by the pons factory and rejects everything else. Since the hook is part of the PoolKey and can never change, a singleton hook means every pons pool shares one immutable fee mechanism — and one blast radius. Worth arguing about against our isolation law.

Curve

amountOut = (inAmount * reserveOut) / (reserveIn + inAmount)
amountIn = (outAmount * reserveIn ) / (reserveOut - outAmount) + 1

Same family again. Their vocabulary: quoteReserve (pricing, includes the phantom), realQuoteReserve (actually collected, net of fees), tokenReserve, and a phantom reserve = our virtual reserve.

Reserved-for-pool allocation is derived, not configured:

reserved = supply * phantomQuote / (phantomQuote + threshold)

which is the same forced relation written the other way round — given V and T, the pool allocation is determined. The curve refuses to sell past it and refunds the overshoot in the same transaction, exactly like RHUB's _previewBuy headroom clamp.

The curve has no quote() function. Integrators reconstruct price from getReserves(), feeBps, creatorTaxBps and sellableTokens(). That is a mistake to not repeat — RHUB's quoteBuy/quoteSell exist for a reason.

Fees — three layers

layeronto
Base fee feeBpsbuy input / sell outputsplit protocol / buyback / creator
Creator tax creatorTaxBpsbuy input / sell outputcreator, entirely. Fixed at launch, protocol-capped
Snipe taxbuys only, first 5 secondsback into the launch, with the base fee

Distribution, in order: protocol share off the top, then buyback share if enabled, remainder plus the whole creator tax to the creator.

Post-graduation the hook charges the same rates through afterSwap, on the unspecified currency — the same v4 constraint we hit. Launch-token-denominated fees are held and converted to quote at sweep, bounded by a maximum price impact, and deferred rather than forced if the conversion would be bad. Fees accrue as a claimable balance; nothing is pushed.

The snipe tax — the idea most worth stealing

  • 5-second window, decaying 99% → ~25% at 1s → ~3% at 2s → 0% at 5s.
  • Buys only, never sells.
  • Capped so the buyer always nets ≥1% of spend.
  • Exemptions fixed at creation: the launching address, the creator fee recipient, and up to 32 immutable team wallets.
  • currentSnipeTaxBps(recipient) is a public read; curve maths alone overstates the fill.

This is a fully on-chain answer to the first-block sniper that needs no keeper and no allowlist maintenance. Compare v1's two-block wallet caps: cruder, but no tax to explain.

Graduation

Four phases, and a two-step graduation with a safety valve:

phase
0 NotGraduatedtrading on the curve
1 Sweptcurve drained, pool not created yet
2 PoolCreatedtrading on v4
3 Rescuedrecovery path was used — permanently visible

Triggered automatically when sellableTokens() hits zero during a buy; if the automatic step fails, anyone can call createGraduatedPool(token). Same "inline, but permissionlessly retryable" shape as RHUB's graduate().

The pool is opened at fee = 0 with a full-range position, and the position is transferred to the Launch Locker: no unlock function, no timelock, no privileged wallet. Excess supply is locked alongside it.

If step two is blocked for 7 days the protocol can return the collected reserves, and the launch is marked Rescued forever. A visible, one-way recovery path — worth copying; it is the honest version of an admin hatch.

"All launches with identical configurations graduate into pools of identical size and price, regardless of purchase distribution."

That sentence is the forced relation stated as a product promise.

Buyback vault

Optional at launch, funded from the creator's own fee share. Bought-back tokens vest linearly over 5 years, with a weighted start so a later buyback does not ride an earlier one's progress. Either beneficiary can call release; it pays both pro rata. If a buyback cannot execute sensibly (thin liquidity, too much impact) it is skipped and the funds go to the creator as normal — "a buyback going wrong cannot hold up anyone else's fees."

Quote assets

Launches can pair against approved ERC-20s instead of ETH. Per-asset economics are stored (phantom reserve, threshold, decimal adjustment). Only pons-approved assets; no permissionless addition. That is the shape our tokenised-stock pairing (O3) will need.

Live addresses (Robinhood Chain, 4663)

v2 Factory0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e
Meme Hook0xE5e702641Ea86F4ae6cC3cDaeD2B886f976Be044
Fee Escrow0xd3AFEB2a57f70eF218Aa82451c51B2fb0416Ac9e
Buyback Vault0x42df2a798f82289E177311362e8f5ccC45c1219c
Launch Locker0x267444D099b10fB5Ed7c3Cc7B7c767AdcA574952
Launch + Buy Router0xe33E9E479dF8802cb0866d5d05258bEc4cF62948
Launch Deployer0x3711ceA4feaDE896C913C68F01Eda97Cb06D1A42
Graduation Executor0xC7819B64A1dAECD7eC19856d026cb14EfBd89046
Graduation Guard0xf5695117b99B6f6401e67d4195BD653628176C6C
v1 Factory / Locker0xA5aAb3F0c6EeadF30Ef1D3Eb997108E976351feB / 0x736D76699C26D0d966744cAe304C000d471f7F35
WETH0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73

They warn against assuming the current stack: a token settles through the hook and escrow it was created against, so resolve a token's stack from its factory. That is a versioning lesson for a launchpad that intends to ship more than once.

Community takeover

Off-chain: a form, reviewed by the team. Moves the creator payout wallet and the social surfaces only; token, pool and locked liquidity untouched. Notable mostly as evidence that abandoned tokens are a real operational problem a launchpad has to answer for.