A creator has no credibility on day one. So the coin carries the promise instead.
Slyng is a token launchpad on Robinhood Chain. Launching is free, the entire supply goes on a bonding curve, and the creator picks a window at launch during which they cannot move their own coins. That window is written into the ERC-20 as an immutable and enforced on every transfer out of their address. Nobody can shorten it afterwards — not them, and not us.
Every figure below is a constant in contracts/src/Launchpad.sol or an immutable in contracts/src/LaunchToken.sol, named where it is used so it can be checked against the source rather than taken on trust. Where this page and the contracts disagree, the contracts are right and this page is wrong.
The problem
Launching a coin is easy everywhere. The hard part is the first hour, when nobody has a reason to believe the person who launched it.
The usual answer to that is a promise: a pinned message, a screenshot of a liquidity lock, someone saying they are in it for the long term. None of it is checkable by the person deciding whether to buy, and on the incumbent launchpad on this chain none of it is enforced by anything.
Slyng's answer is to move the promise into the coin. A creator chooses a time gate at launch. It is stored on the ERC-20 and checked on every transfer out of their address, so it holds against every route out — a DEX, an aggregator, an OTC deal, or a transfer to a fresh wallet. A stranger can read it straight off the token contract without trusting the site, an indexer, or us.
The claim is deliberately narrower than it could be. It is not that coins launched here cannot be rugged. It is that you can tell at a glance which ones have a gate, how long it is, and when it expires — and that no one can change the answer after the fact.
The time gate
Chosen by the creator at launch, enforced inside the ERC-20, and never shortenable.
MIN_LOCKUP. The shortest gate the contract accepts. There is no zero, and no way to launch without one.
RUG_PROTECTED_LOCKUP. The shortest gate that earns a coin the rug protection mark.
DEFAULT_LOCKUP, and deliberately the protected value rather than the floor: a gate nobody chose must not silently be the weakest one available.
MAX_LOCKUP. Longer is always permitted up to this, and is a stronger signal to buyers.
Where it is enforced
Enforced by the contractLaunchToken._checkLock runs on every transfer out of the creator's address. Buying is always allowed; it is moving coins out that is blocked, which covers selling to the curve, selling on a DEX, and moving to an alt wallet to sell from there.
The placement is the point. Blocking sells in the launchpad would be bypassed by selling on a DEX. Blocking them in the front end would be bypassed by calling the contract directly. Only the token itself has no way out. test/Lockup.t.sol is written as an attempt to break that rather than a demonstration of it.
What the mark means
Enforced by the contractA coin carries the rug protection mark when its timeGateSeconds is at least twelve hours. The mark is derived from that number every time it is shown, has no setter anywhere, and cannot be granted, removed, or bought — by us or by anybody. It also cannot be added after launch.
Both timeGateSeconds and creatorUnlockAt are immutable on the token, so a buyer can check the claim on a block explorer instead of believing this page.
It binds one address. It stops the creator moving the coins they bought. It cannot stop somebody else being sent coins, and it cannot stop a determined creator accumulating through a second, unrelated wallet. No address-based rule can, and describing the gate as a limit on a person would be a promise the contract does not keep.
It expires. Twelve hours is twelve hours. After that the creator sells like anyone else. The gate buys time to look at a coin before its creator can act; it is not permanent safety and is not sold as any.
Supply and the curve
One billion coins, all of them for sale on the curve, and no allocation parameter for anyone to set.
TOTAL_SUPPLY. Minted once, in the constructor, to the launchpad. No mint function exists afterwards.
CURVE_SUPPLY, which is TOTAL_SUPPLY. Nothing is withheld: no presale, no team allocation, no free creator bag.
MAX_CREATOR_BUY_BPS, 500 bps of the curve — 50,000,000 coins. Standing, and checked on every creator buy rather than only the opening one.
There is no creation fee and no function that could introduce one. Adding a launch charge would mean deploying a different contract, which anyone can detect.
The curve
A constant product held against virtual reserves. A coin is priced in a quote asset chosen by its creator at launch, and it snapshots that asset's curve seed and graduation target at creation — so nothing anybody does later can change the rules a live coin is trading under.
Native ETH is listed in the launchpad's constructor with a 1.5 ETH seed and a 5 ETH graduation target, frozen from block one like every other asset's. The creator buys on that curve at the same price as everybody else; there is no code path that hands them coins.
The opening surcharge
Enforced by the contractFor the first 30 seconds of a coin's life (SNIPE_WINDOW_SECONDS) a buy pays a flat 50% on top of the trade fee (SNIPE_BPS), and nothing after.
Nobody is paid out of it when it is charged, and none of it ever reaches the creator. It is withheld from the amount that buys coins and added to the coin's own curve reserve, so it raises the price for everyone who buys afterwards. Two honest qualifications: if the coin later graduates, the 5% graduation fee is taken on the whole reserve, so a twentieth of every surcharged wei does reach the protocol that way; and the surcharge brings graduation forward, which is the larger effect. We do not book it as revenue when it is charged, because that would give us a reason to want snipers.
There is no exemption for anyone, including the creator, whose opening buy is priced exactly like a stranger's because it happens inside createToken. There is no exemption list, no per-address override, and no setter for the rate or the window.
It caps what the curve will sell one address. It is not a limit on what that address can hold: nothing on chain can stop someone being sent coins, and a creator with a second, unrelated wallet is not bound by it. test_CapBindsOneAddressOnly_KnownLimit asserts that limit directly, so it is a known property rather than an oversight.
The surcharge is not free for the creator either, and the cost is easiest to see at the cap. The most a creator can ever hold is 5% — 50M coins — and buying that position in the first second costs about 0.161 ETH, against about 0.080 ETH once the window has closed. Same position, roughly twice the price, for being early to their own coin. Waiting thirty seconds is free and available to everyone equally.
Graduation
When a curve fills, one transaction closes it, opens a Uniswap v4 pool at the price the curve closed at, and puts the position somewhere it cannot come back out of.
- 1The graduation fee is taken5% of the quote the curve raised (GRADUATION_FEE_BPS). It is protocol revenue, it is not shared with the creator, and only coins that succeed ever pay it. The constant has no setter, so it can never be raised on anyone.
- 2A Uniswap v4 pool is initialisedQuote asset against the coin, LP fee tier 0.30% (POOL_FEE), tick spacing 60, with the swap hook as part of the pool's identity.
- 3One full-range position is mintedSized so the pool opens at the price the curve closed at: tokenAmount = lpQuote × tokenReserve / (virtualQuote + closingQuote). Sized, not fixed — the arithmetic is derived from the closing price rather than from a reserved tranche.
- 4The position goes straight to LpLockerMinted with the locker as the recipient, so it is never held by the launchpad and never passes through anybody's wallet.
Why the liquidity is unreachable
Enforced by the contractLpLocker has no owner, no proxy and no upgrade path, and exactly one external function that can move value: collectFees(), paying an address fixed at deploy. There is no decreaseLiquidity, no NFT transfer, no approve, and no generic execute.
Uniswap v4 has no dedicated collect action — fees are swept by calling DECREASE_LIQUIDITY with a liquidity delta that is a constant zero. That constant is load-bearing for the entire guarantee, and test/Graduation.t.sol asserts that no call path reduces liquidity. Nine dangerous selectors are tested and all nine fail.
It is atomic with closing the curve on purpose: creating the pool in a later transaction would leave holders unable to sell in the gap.
What is left over
An ETH-quoted coin that graduates on the nose puts roughly 167,000,000 coins into the pool. What the curve never sold and the pool did not need — about 61,000,000, some 6% — stays in the launchpad, which has no code path that can move it.
It is not a burn and is not called one. totalSupply still reads 1,000,000,000 and the coins are visible at the launchpad's address, which is checkable — so claiming destruction we did not perform would be exactly the kind of overstatement this project exists not to make.
The pool is sized from the contract's own accounting and never from balanceOf, because a measured balance can be inflated by anyone sending coins to the launchpad, and the opening price is set from it.
The destination pool's key is fully predictable — the coin's address plus three constants — so anyone can initialise it first at any price they like. Before minting, the launchpad compares the pool's existing price against the one it is about to open at and defers if it is outside half a percent on sqrt price. Minting into a squatted pool would be permanent, because the position can never be withdrawn.
A deferred coin keeps trading on its curve, so nobody is stuck, and graduate() is permissionless and retryable by anyone, forever. A squatter buys a delay, not a cut.
The fees, before and after
1% on the curve and 1% in the pool. They are not the same fee, they are not taken by the same contract, and they are not split the same way — which is the part that is easy to get wrong.
TRADE_FEE_BPS, taken on the quote side, split at the protocol level in the same transaction.
No share is computed by multiplying a remainder. The protocol cut is fee − creatorCut, so the shares sum to exactly the fee taken: no wei is stranded and none is invented. testFuzz_SplitConservesEveryWeiOfTheFee asserts it across randomised trade sizes down to 1 wei.
Creating a coin is free and accrues nothing in any bucket. If the creator sends quote with createToken, that opening buy is the first trade and pays in the same transaction. A coin created with no opening buy earns nothing until somebody trades it.
Every bucket is keyed by quote asset. A creator with coins on two quote assets is owed two different things, and netting them would invent an exchange rate the contract has no business knowing. That keying is also what contains a hostile quote asset to the coins priced against it.
A creator round-tripping their own coin pays the full 1% and is rebated 0.70%, so they lose 0.30% per lap.
Graduation itself, once
5% of the quote raised, taken once, 100% protocol, booked like every other protocol receipt and deliberately not special-cased anywhere in the contract. The creator's 70% is a cut of trading; graduation is the platform building the pool, minting the position and locking it. At the 5 ETH ETH-quoted target that is 0.25 ETH — larger than everything the trade fee collected on the way there.
OPEN: whether this should also split 70 / 30 with the creator. It currently does not. Doing so would hand a creator roughly 0.175 ETH per graduation against the ~0.035 ETH trade fees pay them getting there, which is a far louder launch incentive — and it is a one-line change if the incentive turns out to matter more than the revenue.
The launchpad's trade fee stops dead — buy and sell revert AlreadyGraduated and the launchpad never charges that coin again. Trading moves to the pool, which charges 1% all in: the same rate the incumbent's coins pay forever, except that half of it is the coin's creator's.
- Rate
- 0.50% creator, 0.20% protocol
- Over time
- fixed forever — cannot be diluted
- Paid in
- the pool's quote asset, always
- Swept by
- SwapFeeHook.remit(poolKey)
- Cadence
- automatic, every 30 minutes
- Rate
- a share of the pool's LP fee
- Over time
- dilutes as other providers join
- Paid in
- the quote asset and the coin
- Swept by
- LpLocker.collectFees()
- Cadence
- automatic, every 30 minutes
The creator's share rides on the hook and not on the LP fee, and that placement is the whole point. The 0.30% is Uniswap's, paid pro rata to liquidity share, so its holder's income falls every time anybody else adds liquidity beside the locked position — and anyone may, which is wanted, because a deeper pool is worth more to a coin than our share of a thin one. The hook's 0.70% is charged on the swap regardless of who supplied the liquidity, so it does not move. A creator's post-graduation income cannot be diluted by liquidity share — not by us, and not by anyone who adds depth beside the locked position.
One qualification, because the wider claim is not the one the code keeps: the hook caps its fee at what the pool can fill, judged from the liquidity active at the current price. A large position placed just outside that price is not visible to that estimate, so an order that stops at a price limit can fill against it and be charged on less than it moved. It needs somebody else's depth to happen and it does not touch the locked position, but it is a way the 0.70% can be underpaid, and it is ours to fix rather than a reader's to discover.
The creator's 0.50% is credited to the same creatorFees ledger as their curve fees and claimed by the same permissionless claimCreatorFees, paid to them and nobody else. Nothing about the claim path changes at graduation; only where the money came from. Both sweeps are permissionless and each can only pay its own fixed destination, so nobody — creator or protocol — needs a key of ours to be paid.
And nobody has to make the call either. Every one of these streams is swept automatically, every thirty minutes. A job walks the launchpad and calls remit on any graduated pool holding a balance, then claimCreatorFees for the creators owed, then the two protocol withdrawals, then collectFees on the locked positions — in that order, so a fee earned by a graduated coin reaches its creator in the same pass it was remitted in rather than the next one.
Each pass is budgeted, largest first, and none of them promises to finish in one run. Anyone can list a quote asset, launch a coin and graduate it for the price of gas, so a run that simply took the biggest numbers it could see would spend every slot on worthless coins denominated in their author's own token. Curated assets are served first and the rest get the leftovers. What a run does not reach is first in line thirty minutes later — and stays claimable by its owner, permissionlessly, the whole time.
The reason that is safe to automate is a property of the contracts rather than of the job. Every function it calls is permissionless and pays a destination fixed in the bytecode, so the key that drives it cannot send a single wei of any of it anywhere but where the contract already says it goes. The worst an attacker holding that key could do is pay creators their own money and burn our gas doing it. It keeps pocket change and needs nothing more.
It is also allowed to fail, and that is deliberate. If the job is broken or unfunded for a week, nothing is lost and nothing is stuck: the money stays in the contracts, marked with its owner, and any of it can still be collected by the creator, by us, or by a stranger from a block explorer, forever. Automation here removes the chore, not the guarantee — the guarantee never depended on us running anything.
The two contracts cannot disagree about the rate: setSwapHook refuses any hook whose SWAP_FEE_PIPS is not exactly POOL_FEE_CREATOR_PIPS + POOL_FEE_PROTOCOL_PIPS — 5000 + 2000 = 7000 pips, 0.70%. A hook charging more than the launchpad splits would accrue money belonging to nobody; one charging less would credit money that never arrived.
The reserve is a guarantee
Enforced by the contractThe buyback share is payable to buybackVault and to nothing else. That address is empty at deploy and nameable exactly once, so until a burner contract exists the money accrues where nobody, including us, can reach it — withdrawBuyback simply reverts. invariant_BuybackReserveCannotLeaveBeforeAVaultExists asserts it.
The buyback itself is not
Our policy, not a guaranteeThe rest of the protocol's share, and the LP fees, are paid to wallets fixed at deploy. How the buyback is carried out from there — when, how much, and what is held or added as locked liquidity — is our own conduct, publicly visible on chain after the fact but not a contract guarantee, and it will never be described as one.
Why the creator gets 70%, and why that is a bet
An independent on-chain audit of the incumbent's second generation read 32 days of the chain's own archive and counted 207,893 launches. 98.45% never graduated, 20.42% never recorded a single trade, 91.76% never turned over $10,000, and the median creator earned $15.73 — sixteen creators in all cleared $10,000. Trade fees are the only revenue a coin that never graduates ever produces, so paying 70% of them away costs the platform 70% of the entire long tail — on a coin that does graduate it costs about 12%, because the graduation fee dominates and is not shared.
Source: Bitquery Research, “Pons launchpad growth on Robinhood Chain”, an on-chain audit of 3 August – 3 September 2026, figures verified 4 September 2026. Our own census of the same contracts a day later put graduation at 1.75% rather than 1.55%; the figures above are the auditor's throughout, because one source a reader can check beats a better number they cannot.
The bet is that paying creators 70% buys enough additional launches and volume to beat a 70% cut on the tail. That bet is unproven and it is the main thing to measure after launch.
A rival pool. A v4 pool is keyed on its currencies, fee tier, tick spacing and hook, so anyone may open a different quote/coin pool with no hook and trade at 0.30% instead of 1%. Our pool holds all the liquidity at graduation, so routing elsewhere is worse for price impact at first, but that edge decays if somebody seeds a rival. Nothing prevents this and claiming otherwise would be false. What is new since the creator's share exists is that the person best placed to tell holders which pool is canonical now loses 0.50% of every swap that routes away.
The v4 protocol fee. The PoolManager's protocolFeeController can set a per-pool protocol fee of up to 0.1% of the swap, taken before liquidity providers are paid. OPEN: whether it is switched on for this chain's deployment.
The hook has to be set first. A v4 pool's identity includes its hook, so a coin that graduates while swapHook is unset trades outside the fee forever and cannot be retrofitted — and that is the creator's 0.50% lost as well as ours. The deploy script mines the hook address and sets it in the same run.
LP fees bypass the buyback. They pay the locker's fixed recipient in both the quote asset and the coin, and do not flow through the protocol's split. The hook's cut does.
What nobody can do
The launchpad custodies the quote asset while a coin is on its curve. That is the risk, and everything below is how it is bounded.
The coin
Enforced by the contract- No mint function exists after construction. Supply is fixed, permanently.
- No owner and no admin. There is nobody to compromise.
- No pause, no blacklist, no seize.
- No proxy and no upgrade path. Nothing about a deployed coin can be changed afterwards — including by us, and including to fix it.
The launchpad
Enforced by the contract- Curve shape and every fee are constants, identical for every coin.
- Nothing here can mint, pause, blacklist, or seize.
- There is no setFeeRecipient and no withdrawFees. Every bucket has its own fixed destination and its own permissionless payout, and no function drains more than one.
- No function re-cuts the percentages at all.
The owner role, in full — six things, and this is all of them
List a quote asset, or correct the parameters of one somebody else listed first.
A correction cannot reach a coin that is already trading — every curve snapshots its seed and target at creation. It re-vouches for the asset in the same call, so the change always carries a public statement of responsibility for it.
Vouch for a listed asset, or withdraw that vouch.
Live rather than snapshotted, so a vouch can be pulled the moment an asset turns out to be hostile. It does not touch the rug protection mark, which nobody can grant or revoke.
Stop new launches against a listed asset.
Cannot touch a coin already on its curve. Those keep their snapshotted parameters and keep trading for as long as the asset itself lets them.
Name the contract the SLYNG buyback reserve is paid to. Once, ever.
Unset at deploy. Until it is named the withdrawal reverts and the reserve accumulates where nobody, including us, can reach it. There is no second attempt.
Attach the swap-fee hook that future graduations build their pools on. Once, ever.
Only an address whose low bits are exactly the permitted hook flags, and only a hook whose rate is exactly the sum of the two shares the launchpad splits it into.
Hand the role to another address, in two steps.
The destination has to call acceptOwnership itself, so the role only ever moves to an address that has proved it can transact. There is deliberately no renounceOwnership.
And that is the entire list. The owner cannot touch curve reserves, holder balances, accrued fees, the locked position, a coin already on its curve, or the destination of a single wei of fees.
There is deliberately no renounceOwnership. setBuybackVault is callable once and is still unset, so renouncing would strand the buyback reserve unreachable forever — every future slice accruing into a bucket with no address and no way to name one. An owner who wants out transfers the role somewhere that cannot act instead, and does it knowing that is what they have done.
While a coin is on its curve the launchpad holds the quote asset. No property above eliminates that. What bounds it is a solvency invariant asserting the contract's balance always covers live curve reserves plus every accrued bucket, fuzzed over 128,000 calls, alongside 283 tests and fork suites against the real Uniswap v4 deployment.
The contracts are unaudited and no external audit is planned. The tests were written by the same person who wrote the contracts. And because there is no proxy, a finding after deployment cannot be patched — only abandoned.
Quote assets
A coin can be priced against any ERC-20 on the chain. Listing is permissionless, and the honest part of that is what the contract cannot check.
What the contract can check
- That the address has code — an address with none answers every staticcall with zero, so without this a typo lists a token that does not exist.
- That decimals() answers sanely, read from the token rather than typed by the lister. USDG is 6, not 18.
- That the curve seed is non-zero, at least a thousandth of one unit, and below the point where the curve's own arithmetic would overflow.
- That the graduation target is between 2× and 20× the seed. Their ratio is the shape of the curve, and it is the only part of a stranger's numbers this contract can judge.
Listing is one-way and freezes that asset's seed and target forever. Each coin snapshots both at creation, so nothing done later can change the rules a live coin trades under.
What it cannot check
Behaviour. A quote token can revert on transfers out, rebase, take a fee, be minted without limit, or be upgraded into any of those later. The worst case is a honeypot — accepts buys, reverts on sells — and no on-chain check prevents it, because a token can behave one way when probed and another way afterwards.
What limits the damage is containment, not prevention. Every fee bucket, curve reserve and graduated pool is keyed by asset, so a hostile quote token can only harm coins priced against it. It cannot reach another asset's reserves, books, or pools. That property is what makes permissionless listing survivable at all, and test/PermissionlessQuote.t.sol asserts it directly.
Verified on chain on 2026-09-03: Robinhood's tokenized equities are upgradeable beacon proxies whose implementation exposes pause(), mint(address,uint256) and burn(address,uint256) — and that burn takes an address.
So on an equity-paired pool the locker's promise is narrower. We still cannot withdraw the liquidity and neither can the creator — that part is unchanged and still enforced by the contract. But the issuer can freeze it or destroy it, and a pause stops the curve and graduation for as long as they like. The create flow shows that warning inline when a non-ETH asset is selected.
OPEN: USDG's own pause and upgrade surface has not been read. Only QQQ has.
Listed means the contract accepts the token, and it means nothing else. Verified means we read its code and took a view on its issuer — a separate, revocable signal shown as its own badge, deliberately not folded into the rug protection mark, which is about the creator's time gate and cannot be revoked by anyone.
This chain already carries a USDC named “USDCcomputer by Virtuals” and a USDT named “Tether by Virtuals”, both 18 decimals and neither a stablecoin. They are excluded from the launch form's shortlist, and the form has no address box — but the contract would still reach them, because listing is permissionless.
What is live, and what is not built
Stated plainly, because a whitepaper that describes planned work in the present tense is the thing this project is positioning against.
Mainnet
LiveLive on Robinhood Chain mainnet since September 14, 2026, at the same addresses as on testnet, with every validated pairing open from the first night. Real money is at risk on it now.
SLYNG
LiveThe platform shipped first. SLYNG then fair launched on Slyng at 9:30 PM Eastern on September 14, 2026, under identical rules to every other coin: no allocation, no presale, no team tranche, its creator time gated like anyone else, and its liquidity locked by the same contract when it graduates. It has exactly one committed mechanism — the buyback — and the SLYNG page says so rather than papering over it.
The buyback burner
Built · being namedBuilt, tested, and rehearsed on a fork of mainnet against the live launchpad and SLYNG itself. It has no owner and no withdrawal path: it can only turn what it is sent into SLYNG and send that SLYNG to the dead address. Until buybackVault names it the reserve accumulates unspendable by anyone, and naming it is a one-time, irreversible call — pointing it at a wallet would convert the guarantee into a promise.
A live indexer
Not built yetThe indexer itself is built and running — it fills coins, trades and holder balances — but it runs as a daily job rather than a live listener. So the three figures the site cannot recover from a contract read — holder counts, 24h volume, and the amount raised by an already-graduated coin — can be up to a day out of date. A figure it has not answered renders as an em dash rather than a zero. The chart's short ranges do not depend on it: 1m, 5m and 1h read the chain directly.
Everything here is checkable against the source. If a figure on this page ever stops matching the contracts, the contracts are right.