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 contract figure below is a constant in contracts/src/Launchpad.sol or an immutable in contracts/src/LaunchToken.sol unless it names another contract, and is named where it is used so it can be checked against the source rather than taken on trust. A few figures are our server's instead — Slyng's cut on other launchpads' coins, the limits on covered gas, the chat and report rules — and each is marked as ours where it appears. 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 was empty at deploy and nameable exactly once, and until it was named the money accrued where nobody, including us, could reach it — withdrawBuyback simply reverted. invariant_BuybackReserveCannotLeaveBeforeAVaultExists asserts it.
It was named on September 14, 2026, to the buyback burner in section 12, and the buyback is running now. Everything accrued before and since is payable there and nowhere else, and withdrawBuyback is permissionless, so moving it needs no key of ours.
The rest of the buyback is not
Our policy, not a guaranteeThe rest of the protocol's share, and the LP fees, are paid to wallets fixed at deploy. What is done with them 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.
So is the timing of the burn. A job of ours moves the reserve to the burner and calls it every ten minutes. Every step is permissionless, so anyone else can do the same, but nothing obliges anyone to.
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.
Boosts are paid placement, not a fee
A boost buys a coin a higher place on Discover for a set time. Anyone can buy one for any coin, on the website, in ETH. It is not charged on anybody's trade, and it never touches the coin: not its contract, its curve, its fees or its time gate. What it changes is where our server ranks the coin, which is section 10.
The payment goes to BoostPayments v2 at 0xBf73711DCeCA1799461820D2e508868cB49cACA2, which forwards every wei to the treasury in the same call — the same treasury() the launchpad pays — and emits a BoostPaid receipt. It has no owner, no upgrade path and no withdraw function, because it never holds a balance. It does not price the boost either: our server checks the amount against the WETH/USDG pool before it credits the slot, so the receipt proves that a payment happened and how much, not that it was enough.
v2 is source-verified, like v1 (0xe914…4f43, no longer used), and its code differs from v1 only in accepting five packs instead of three.
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, and until it was named the withdrawal reverted and the reserve accrued where nobody, including us, could reach it. Called on September 14, 2026, naming the buyback burner. The slot is spent and any further call reverts, so 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. It was left out while setBuybackVault, callable once, was still unset: renouncing then would have stranded the buyback reserve unreachable forever — every future slice accruing into a bucket with no address and no way to name one. The vault has been named since September 14, 2026. 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 292 tests and fork suites against the real Uniswap v4 deployment.
The contracts are public, peer reviewed and third-party audited, including by KyberSwap and 0x. An audit lowers the odds of a defect; it does not rule one out. 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.
Coins from other launchpads
Slyng lists and trades coins it did not launch, starting with PONS. Almost nothing above this section is true of them, and this is where that is said.
What Slyng takes, and where it goes
When you trade a PONS coin on Slyng, the trade is routed through KyberSwap or 0x, whichever pays more, and Slyng takes 0.5% of the ETH or USDG side. That rate is a setting of our server, sent to the router with the request — not a constant in any contract of ours — and it is shown as its own line on the trade panel before you sign.
The router pays it to SlyngFeeSplitter at 0x2E9a2362E9D57C3C57791E3dc920f5947217DCF5: OpenZeppelin 4.7's PaymentSplitter, unmodified, with a constructor that read its two payees from the launchpad at deploy — the buyback burner and the treasury, one share each, fixed for good. release is permissionless and pays each payee only its own half. So half of every such fee becomes SLYNG at the dead address, and half goes to the treasury.
The splitter is source-verified, an exact match to its source on Sourcify, and its payees and shares can be read from the chain directly (payee(0), payee(1), shares).
What is PONS's, not ours
A PONS coin's contracts, its curve, its fees, any creator tax and every rule it trades under are PONS's, and nothing on this page guarantees any of them. The time gate, the 5% creator cap, the opening surcharge, the locked liquidity and the limits on the owner role are properties of Slyng's contracts, so they apply to Slyng coins only.
A PONS coin's page on Slyng says so: it carries no rug protection mark and no time gate, and its creator's tax is listed as theirs. Its trades are read from PONS's contracts and indexed every two minutes, and the page reads the newest blocks live on top of that. Slyng's part is the listing, the route and the 0.5%.
Your wallet
Signing in makes you a wallet that is yours, not ours. What that means, and the limit on it, stated next to each other.
Who holds what
Signing in with Apple, Google, X, Discord, TikTok or an email address creates a wallet on Robinhood Chain through Privy, the wallet provider, and the same sign-in opens the same wallet in the app and on the site. Its key is held as split shares — there is no seed phrase — and it is never given to Slyng, the app or the site. We hold no key and no funds, and we cannot move anything out of your wallet.
Every trade, launch, boost and send is a transaction your wallet signs, executed by public contracts on the chain. On the website you can connect a wallet you already have instead; nothing about the contracts differs between the two.
Gas, and sending
Our policy, not a guaranteeIn the app, when a signed-in wallet has too little ETH for gas, a trade on a Slyng coin's curve can be sent with its gas paid by us: only for coins paired with ETH or USDG, a buy of about a dollar or more or a sell bringing out about a quarter or more, and within a daily limit per wallet and for everyone together. On the website, a signed-in wallet's buy paid in the other asset — USDG into an ETH-paired coin, or ETH into a USDG one — is sent the same way. A wallet that can pay its own gas pays it. Covered gas comes from our budget under our rules, which can change or run out.
A covered transaction is still yours. The first time, your wallet signs a one-time EIP-7702 authorization to Alchemy's Modular Account v2, and every operation after that is signed by your wallet before it is sent. Send, in the app, is an ordinary transfer from your wallet to an address or a @handle, signed by you, with no fee of ours.
There is no way to export the private key, in the app or on the site. Privy's app SDK has no export call, so the only version inside the app would have been Privy's web page shown in a sheet. We decided the key would be shown in the app or not at all, and took export out of both. A wallet made by signing in is reached by signing in, through Privy.
What you can do instead is move everything to a wallet whose key you hold. In the app, Send moves any asset the wallet holds to any address, and Withdraw sends USDG out as USDC to a wallet on Base, Ethereum, Arbitrum, Optimism or Polygon. The website has neither screen, and the app is not on the App Store (section 12).
What our server enforces, not the chain
Some rules on Slyng are ours, run by our server rather than by a contract. They are listed here so none of them is mistaken for a guarantee: we can change any of them, and none has the standing of anything in sections 02 to 07.
Posting or replying in a coin's chat needs a balance of that coin above zero, read from the chain when you post; the coin's creator is exempt. Anyone signed in can like a message. If that chain read fails, the post goes through, because gagging every holder during an outage is the worse mistake. Chat is signed by your wallet and stored by us, not on chain.
Beside each author, what their holding of the coin is worth now, read from the chain for every page of chat. Fudder marks an author who holds none, which with holders-only chat means someone who sold after posting. A read that fails shows no badge, never Fudder.
Boosted coins sit first on the All, Graduating and Boosted tabs, ordered by live boosts: that is paid placement, and a boosted card carries the boost mark. Trending is only for coins that trend on their own — three or more traders and $25 of volume in 24 hours, or five holders chatting — and boosts then multiply that organic score by 1 + boosts ÷ 10. SLYNG, our own coin, is pinned first on every Discover tab as the featured coin.
A chat message is hidden once three different wallets report it, a coin or a profile once ten do. Blocking a wallet hides its chat from you and stops it notifying you. Hiding is ours and only on our pages: a hidden coin still exists on chain and still trades through its contracts.
Solana coins
Since October 12, 2026 Slyng trades pump.fun coins on Solana. As with PONS, almost nothing in sections 02 to 07 is true of them, and the burn reaches SLYNG by a longer road.
What you can do
Any pump.fun coin opens at slyng.tech/sol/<mint>, and pasting a mint or a pump.fun link into Discover's search box goes there. Trades are signed from your own Solana wallet, Phantom or another external wallet, or from a Privy embedded wallet that an Add SOL sheet can fund. Slyng never holds your keys.
Routing is Jupiter, asked by our server. The venue is the pump.fun bonding curve while a coin is on it and PumpSwap after it graduates. There is no Solana list in Discover yet.
What Slyng takes, and where it goes
pump.fun takes its own fee: 1.25% on the curve and 0.30% on PumpSwap. Slyng takes 1% on top, in wrapped SOL, and the trade panel shows both lines before you sign. The 1% is a setting of our server, sent to Jupiter with the request, not a constant in any contract.
It lands in a wrapped-SOL fee account owned by a Privy server wallet whose policy allows only a short list of actions. A job runs twice an hour. Once the balance is above 1 SOL it sends half to the Slyng treasury and bridges the other half through Relay to Robinhood Chain, delivered to the same buyback burner named in section 12, which buys SLYNG and sends it to the dead address.
What it cannot check
- pump.fun's fee, curve and rules are pump.fun's. The time gate, the 5% creator cap, the opening surcharge and locked liquidity are properties of Slyng's contracts and do not apply to these coins.
- The burn is batched, not per trade. Fees wait in the fee account until they pass the threshold, so a trade does not burn SLYNG in the same moment, and a quiet stretch burns nothing.
- The bridge leg depends on Relay. The fee wallet's policy limits what it may sign, but the bridge's destination sits inside Relay's instruction data, which the policy probably cannot pin. What the wallet holds between runs is capped by the threshold, and the job refuses a quote that loses more than 2% against Pyth's SOL/USD price and the chain's ETH price. Our job and the policy are ours to change.
- You pay your own network fee and keep 0.01 SOL back for it and for the new token account. A quote that has moved past your slippage is refused before you sign, with the new numbers shown.
What is live, and what is not
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
LiveNamed by setBuybackVault on September 14, 2026, at 0xD7F7e0731F5812A9C58b039A45fc5543e8b5a720 — once, and it cannot be renamed. It has no owner and no withdrawal path. It turns what it is sent, by the launchpad's buyback reserve or by the fee splitter in section 08, into SLYNG — buying on SLYNG's curve until the coin graduates and in its pool after — and sends that SLYNG to the dead address; an asset with no real market to route through waits in it rather than being sold at any price. Every swap and curve buy it makes is sized to move the price by at most 2% (maxImpactBps, an immutable on the burner), so a large balance is burned over several calls rather than one.
A job of ours calls it every ten minutes and anyone else may call it too. The SLYNG page shows the running total burned, read live from the dead address. The burner pays the trade fee like any buyer, so SLYNG's creator is paid 0.70% of every buyback buy on the curve, exactly as on anyone else's.
Its source is verified, so everything above can be checked against the code, and every burn is visible on chain as a Burned event on it and a transfer to the dead address.
Trading Solana coins
Livepump.fun coins have traded on slyng.tech since October 12, 2026, as described in section 11. Solana coins are not listed in Discover yet; that is next, and until it ships a coin is found by pasting its mint or pump.fun link.
The indexer
LiveSlyng's indexer runs every ten minutes, and the one for PONS coins every two, as scheduled jobs rather than a live listener. What a coin page leads with does not wait for it: market cap and curve progress are contract reads, and holder counts, 24-hour volume and what a graduated coin raised are replayed from the chain in the browser, showing the indexer's figure only until the replay has covered the whole window. The chart's Live, 1m, 5m and 1h ranges read the chain directly.
What still depends on the indexer is depth: the 24h, 7d and All ranges beyond their newest hour, and trade history older than what the page reads live. A figure nothing has answered yet renders as an em dash rather than a zero.
Trading Slyng coins from other apps
Built · not liveNo aggregator routes a Slyng coin on its curve today, so wallets and apps that trade through one cannot quote it. For KyberSwap we wrote the integration — a liquidity source and an execution adapter, tested against the live launchpad — and it sits as two pull requests in Kyber's repositories; merging them is Kyber's call. 0x adds a launchpad only when its own team chooses to, so there it is a request with 0x rather than code of ours.
The iPhone app
Built · not liveBuilt, and version 1.0 has been submitted to Apple's App Store review. It is not on the App Store and cannot be downloaded; a test build runs on TestFlight for an internal group only. Send and Withdraw, in section 09, are in the app.
Card deposits and bank withdrawals
Built · not liveBuilt, and switched off. Apple Pay and debit card deposits run through Coinbase's on-ramp, which waits on Coinbase approving the project; until then, adding money means sending ETH or USDG to the wallet's address on Robinhood Chain. Cashing out to a US bank account goes through Coinbase too and is hidden for the same reason, so the app's Withdraw offers a crypto wallet only.
Checking it against source
These contracts are source-verified on both Sourcify and RobinScan, checked on September 27, 2026. Every Slyng coin is created by the launchpad from the same LaunchToken code, so SLYNG's verified source is the source of every coin.
- Launchpad0xCe0ABC33eC4264377045Ae17F9B887DB33Cc95B4
- SwapFeeHook0x553E6De12c0b9f483aC349983967703F5814C0Cc
- LpLocker0xd1eaec41d8158b94463b32767ce6fd18282897bb
- LaunchpadLens0x43e0d56b9d7e3aaecd0c46b86551699218507def
- LaunchToken (SLYNG)0x066FFa6AAF8B54C6094d1Ed1bE818AFA5e0f290E
- SlyngBurner0xD7F7e0731F5812A9C58b039A45fc5543e8b5a720
- SlyngFeeSplitter0x2E9a2362E9D57C3C57791E3dc920f5947217DCF5
- BoostPayments v20xBf73711DCeCA1799461820D2e508868cB49cACA2
- BoostPayments v1 (no longer used)0xe91478eabbe5e551ebd228c1e56c51c358734f43
Every contract claim here is checkable against verified source. If a figure on this page ever stops matching the contracts, the contracts are right.