Docs
How this works, what it costs, and where the money goes — followed by the API, if you would rather build on it than click through it.
What this is
A launchpad for tokens named after real places — a coffee shop, a barber, a bakery, a gym. You pick a business off a map, give the token a name and a picture, and it trades on Solana a few seconds later.
Two things make it different from a generic token launcher:
- Every token points at a real business, and its page says which one.
- Most of the trading fee is set aside for that business — whether or not the business has ever heard of the token. It waits in a ledger until the owner turns up and proves who they are.
The one rule to understand first
Launching a token for a business does not involve that business.
Anyone can launch a token for any business. The business did not create it, did not approve it, does not control it, and usually does not know about it. Several people can launch several different tokens for the same shop, and all of them are equally unofficial.
This is on every token page, in the token’s own on-chain metadata, and in the disclaimer any wallet or explorer reads. It is not a disclaimer we bury — it is the product.
The single exception: if the real owner claims the business, verifies it, and launches a token themselves, that one token carries an Owner badge. Everything else on the page stays exactly as unofficial as it was.
What you need
| A Solana wallet | Phantom, Solflare, Backpack — anything that can sign |
| Some SOL | see "What it costs" below |
| Nothing else | no account, no email, no sign-up |
You sign in by signing a message with your wallet. It costs nothing and is not a transaction — it only proves the wallet is yours. There is no password to forget and no account to recover: your wallet is the account.
If you have never used one
Install Phantom, Solflare or Backpack — always from the official site or your browser’s extension store, never from a link somebody sent you. Setting one up takes about a minute.
It will show you a recovery phrase of twelve or twenty-four words. Write it down on paper and keep it somewhere safe. That phrase is the only way back into the wallet: nobody can reset it for you — not the wallet maker, and not us. Anybody who has it has your money, so never type it into a website and never send it to anyone, including anybody claiming to be support.
Claiming your business costs nothing. Signing in is a signature, not a transaction, and submitting a claim never touches the chain — so you can claim and collect without ever buying SOL. You only need SOL if you want to launch a token yourself.
Launching a token
Five minutes, three screens.
1. Find the business
Search by name, or pan the map and click a pin. You can also paste a Google Maps or OpenStreetMap link, or let the browser use your location.
Search runs on OpenStreetMap, which is free and open but does not know every small shop. If your place is genuinely missing, drop a pin: click the map, name it, launch on it. Those records are labelled "Added by a user" everywhere they appear, because nothing about them has been checked against an outside source.
2. Describe the token
| Field | Rules | Changeable later? |
|---|---|---|
| Name | up to 32 characters | No |
| Symbol | 2–10 characters, A–Z and 0–9 | No |
| Description | up to 1,000 characters | Yes |
| Image | PNG, JPG, WEBP or GIF — square works best | Yes |
| X and Telegram | optional | Yes |
| Your website | optional, shown on the token page | Yes |
The name and symbol are burned into the token when it is created and nobody can ever change them — not you, not us. Read them twice before you sign.
3. Choose what it is priced in
By default, SOL. That is what almost everybody wants and you can skip this entirely.
A token can instead be priced in a tokenised share or commodity — 83 are offered, from tokenised index funds and company shares to gold and oil. A token priced in one of them holds its reserve in that asset and pays its fees in it, which means the business behind it earns shares rather than SOL.
Two things worth knowing if you do:
- Buyers are unaffected. Every trading terminal routes from whatever they hold, so somebody paying in SOL never learns the pool is quoted in something else.
- It costs about 0.006 SOL more, because such a launch needs its own pool configuration.
4. Your opening buy
Optional. If you want to hold some of your own token, type an amount and it is bought inside the same transaction that creates the pool — so nothing can get between the token existing and your buy. No bot can front-run you.
The amount is always in SOL, even when the token is priced in something else. If it is, your SOL is swapped into that asset first, automatically, before the launch. You do not choose this and do not need to think about it: you type an amount of SOL, the way you would anywhere else.
There is a ceiling. An opening buy cannot be so large that it pushes the token past its own starting valuation — the form tells you if you go over.
5. Review and sign
The review screen shows the finished token exactly as it will appear, and what you are about to pay. Your wallet then asks you to approve, once.
Depending on the launch, that single prompt may cover up to three transactions:
| Transaction | When |
|---|---|
| A swap | only with an opening buy on a share-priced token |
| A configuration | only when the token is priced in something other than SOL |
| The launch | always — creates the token, the pool, and your opening buy |
The ordinary case — SOL, with or without an opening buy — is a single transaction.
If anything fails on chain, no money moves. The fee, the buy and the pool creation share one transaction: it either all happens or none of it does.
What a launch costs
| Roughly | |
|---|---|
| Platform launch fee | 0.02 SOL |
| Solana rent and network fees | about 0.03 SOL |
| Extra, share-priced tokens only | about 0.006 SOL |
| Your opening buy | whatever you chose, or nothing |
The rent is not our fee. It is what Solana charges to store the token’s accounts, and it is the same for anybody creating a token by any means — most of it stays locked in those accounts rather than being spent.
The 0.02 SOL is ours, and it is a plain transfer inside the launch transaction. If the launch fails, it was never sent. There is no refund path because there is nothing to refund.
How a token trades
Every token starts on a bonding curve — a formula, not an order book. Nobody has to provide liquidity and there is nothing to match: the price follows how much has been bought.
| Total supply | 1,000,000,000, fixed, all of it in the curve |
| Opens at | 40 SOL of market cap |
| Graduates at | 350 SOL of market cap |
| Trading fee | 1.2% of every buy and sell |
| Token standard | SPL Token, metadata immutable |
As people buy, the price rises along the curve. When the reserve reaches the graduation threshold the curve completes and the token migrates to an ordinary AMM pool, where it trades like any other Solana token.
All the liquidity that moves across is locked permanently. Not for a month — permanently. Nobody can pull it, including us. There is no team allocation, no vesting schedule and no unsold reserve.
Where the trading fees go
Every trade pays 1.2%. Here is all of it:
| Who | Share of the fee | Per $1,000 traded |
|---|---|---|
| The business | 65% | $7.80 |
| Meteora (the protocol) | 20% | $2.40 |
| The platform | 15% | $1.80 |
| Whoever launched it | 0% | $0.00 |
Two of those deserve a sentence.
The business earns whether or not it knows. From the very first trade its share is credited in our ledger. If nobody has claimed the shop the balance simply accumulates and waits — an owner who turns up a year later finds a year of earnings.
The launcher earns nothing. Deliberately, not by oversight. The money is meant for the business the token names, not for whoever reached the launch button first. Launching is open to anyone; it is not a revenue stream.
After graduation
A graduated token has not stopped earning — the trading has moved. Fees keep being credited to the same business, read from the migrated pool instead of the curve. The migrated pool charges 1.2%.
What can never be changed
Worth knowing before you sign, because no support ticket fixes any of these:
- The name and symbol. Burned into the token at creation.
- The total supply. No more can be minted, by anyone.
- The fee, and where it goes. Set on the pool configuration, which cannot be edited once it exists.
- The locked liquidity after graduation.
- The token’s published website, which is always its page here.
What you can change: the description, the image, and your social links. Those live in our database and remain yours to edit.
Buying and selling
You do not have to buy here. Every token is an ordinary Solana token from the moment it exists, and each token page links out to Axiom, Padre and GMGN alongside the Solana explorer. Jupiter and every other aggregator can route to it too.
Nothing about a token is locked to this platform. That is the point of building on a public program rather than a private contract of our own.
If the business is yours
You do not need to launch anything to collect the fees. Those two things are entirely separate.
Claiming it
Open the business page and choose Claim. You will be asked to show the place is yours, in one of six ways:
| Method | What you do | Weight |
|---|---|---|
| Your website | Put a code on your own site — a meta tag, a file, or a DNS record | Strongest |
| Google Business Profile | Post the code as an update from the profile you manage | Strongest |
| Instagram or Facebook | Post the code from the account you run | Strong |
| Business email | Give the address the business uses; a reviewer writes to it | Medium |
| Phone | Give the business number; a reviewer calls it | Medium |
| Anything else | Describe it in your own words | Depends |
A person reads every claim. There is no automatic approval and there will not be one. A machine can confirm a code is published at an address — it cannot confirm that address belongs to the shop on the corner, and that is the part that matters. Where something can be checked automatically it is, and the result is attached to the claim so the reviewer glances instead of investigates.
We do not publish a review time, because it would be a promise about somebody’s afternoon. Nothing changes until a person decides.
What claiming does and does not grant
It does: put a verified badge on the business page, make the accrued fees payable to you, and — where the feature is switched on — let you launch one token carrying the Owner badge.
It does not: give you any control over tokens other people launched, remove or hide them, or make any of them official.
Verifying gates the payout, not the earning. The money was always being counted for you; it was simply not payable to anybody yet.
Getting paid
Once you are verified, an administrator approves the accrued balance and sends it. Payouts always go to the wallet you verified with — that is not something a request can override.
You can record how you would rather be paid: in SOL, or in one of the tokenised shares or commodities. That is a preference, not an instruction — it tells whoever settles it what you want, it does not move money by itself. Automatic execution covers SOL today; anything else is settled by hand.
Badges, and what they actually mean
| Badge | Meaning |
|---|---|
| Owner | The business launched this token itself |
| Owner claimed | The owner is verified and collects the fees — but did not make this token |
| No badge | Nobody has claimed the business yet, or a claim is still being reviewed. The fees accrue and wait either way |
Owner can only ever appear on a token, and on only one token per business — a business is not something anybody launches. There are only these two badges: no badge is the ordinary case and says nothing against the place, since most businesses have simply never heard of us.
Where a token can be in its life
| Status | Meaning |
|---|---|
| Creating | Reserved, waiting for the transaction to confirm |
| Active | Trading on the bonding curve |
| Graduated | The curve completed; trading moved to a locked AMM pool |
| Failed | The transaction never landed. Nothing was charged |
A launch becomes Active only after the server reads the chain and confirms the pool exists, the mint matches and the creator matches. The browser’s word is never taken for it.
Honest limits
True things you would rather read here than discover later:
- Fees appear when the indexer runs, not instantly. It sweeps on a schedule. Nothing is lost by waiting — it compares lifetime totals, so a missed run catches up completely on the next one.
- Nothing has graduated yet, on any network.
- Tokenised shares can be frozen by their issuer. Those mints carry permissions that allow the issuer to pause transfers. None are armed today, but the ability exists, and a business paid in one of them holds something a third party can freeze.
- Weekend prices drift. Tokenised shares and commodities keep trading on chain while the real market is shut, so a token priced then opens slightly off target.
- A dropped pin has been checked by nobody. Where a place was added by a user the label says so. Treat it accordingly.
For developers
Everything below is the same API the site itself uses. There is no separate partner tier and no key to apply for.
The basics
Base URL is this deployment: https://coinit.fun. Every response is JSON. Success is wrapped, so a payload can never be confused for an error:
{ "data": { ... } }{ "error": { "code": "BUSINESS_NOT_FOUND", "message": "We could not find that business." } }A validation failure adds fields, keyed by input name. Error message is always safe to show a user — stack traces, RPC URLs and internal detail never cross the boundary.
Reads need nothing. No key, no header, no account. Writes need a wallet session, described below.
Amounts that are integers on chain are returned as strings, not JSON numbers — lamports do not survive a double.
Public endpoints
/api/businessespublicq, city, category, verified, sort, limit. Owner wallets are never included./api/businesses/{id}public/api/businesses/{id}/launchespublic/api/businesses/mappublic/api/businesses/nearbypublic/api/launchespublicbusinessId, creatorWallet, status, limit./api/launches/{id}public{ launch, pool, graduation, live }. An RPC hiccup degrades to stored data and sets live: false rather than failing./api/launches/{id}/candlespublicresolution defaults to 5m. Returns available: false with a reason where no outside indexer covers the token./api/metadata/{id}public, CORS */api/places/searchpublic/api/places/details and /api/places/resolve-link, which turns a pasted map link into a place.Signing in with a wallet
Three steps. The server never verifies a message the client supplied — it rebuilds the expected text from its own stored nonce, which is what stops a signature harvested elsewhere being replayed here.
/api/auth/noncepublic{ wallet }. Returns { nonce, message, expiresAt }. Sign the message verbatim — it follows Sign-In-With-Solana, and wallets parse it./api/auth/verifypublic{ wallet, nonce, signature }. Sets the session cookie and returns { wallet, isAdmin, csrfToken }./api/auth/sessionpublic/api/auth/logoutsessionAfter that, send the cookie with every request and put the csrfToken in an x-csrf-token header on every mutation. A write without it is rejected. Sessions last seven days; a nonce lasts five minutes and is single-use, and a failed attempt burns it.
Launching a token through the API
Two calls, with a wallet signature between them. The server builds the transaction; it never asks for or holds a private key, and no launch is believed until the chain is read back.
/api/launchessession + CSRF/api/launches/{id}/confirmsession + CSRF{ signature }. The server fetches the transaction, checks it committed, reads the pool account and asserts the mint, creator and config match what it reserved. Only then does the launch become Active./api/launches/{id}/confirmsession + CSRF/api/uploadssession + CSRFimageUrl.The request body:
POST /api/launches
{
"businessId": "uuid", // or "customPlace" for a dropped pin
"tokenName": "Corner Coffee Coin",
"tokenSymbol": "KOFFEE", // 2-10 chars, A-Z 0-9, PERMANENT
"description": "optional",
"imageUrl": "optional",
"quoteAsset": "sol", // omit for SOL
"devBuyAmount": "0.5", // ALWAYS SOL, as a string
"links": { "website": "", "twitter": "", "telegram": "" },
"idempotencyKey": "16-128 chars, stable across retries"
}The response:
{ "data": {
"launchId": "uuid",
"businessId": "uuid",
"transactionBase64": "...", // the launch itself — send LAST
"setupTransactionBase64": "...", // optional: a config, send FIRST
"swapTransactionBase64": "...", // optional: a Jupiter swap, send BEFORE that
"swapSummary": { "minimumOut": "...", "priceImpact": 0.0, "hops": 1 },
"tokenMint": "...", "poolAddress": "...", "configAddress": "...",
"metadataUri": "...",
"reused": false
} }Order matters where more than one comes back. Send and confirm the swap, then the config, then the launch: the buy needs the swapped tokens and the pool needs its config to exist. Sign them together so the user is prompted once.
transactionBase64 arrives partially signed by an ephemeral mint key the server generates, uses and discards. Add the user’s signature; do not strip the existing one.
Reuse the idempotency key when you retry. The same key returns the same launch with reused: true instead of creating a second one.
Token metadata
/api/metadata/{id} is the URI baked into the mint at creation. Because it is immutable on chain, that address has to answer for the life of the token. It sends CORS * and is safe to read from a browser.
It is the standard shape wallets and explorers expect — name, symbol, description, image, extensions, attributes, properties — plus one namespaced block of our own:
"irl_launchpad": {
"business_id": "uuid",
"business_name": "Corner Coffee",
"business_verified": false,
"business_page": "https://.../business/uuid",
"creator_wallet": "...",
"disclaimer": "This is a community-created token. It is not issued,
endorsed or controlled by the business unless explicitly
stated on the business page."
}If you render these tokens anywhere, read that block. business_verified is the only honest answer to "is this official?", and it is false for almost every token.
Reading it straight off the chain
None of this needs us. Tokens are created by Meteora’s public Dynamic Bonding Curve program and, after graduation, live in DAMM v2 pools. There is no custom contract in this project — not a line of it — so anything the site shows, you can read yourself with Meteora’s SDK or by decoding the accounts.
GET /api/launches/{id} hands you tokenMint, poolAddress and configAddress to start from. Pool state — reserves, curve progress, lifetime fee counters, and whether it has migrated — is on the pool account and is the same source this site reads.
Fee counters on the curve are cumulative and monotonic, which is why our indexer diffs them rather than replaying transactions. They freeze at migration; after that the equivalent totals live on the migrated pool’s positions.
Rate limits and error codes
Limits are per wallet where you are signed in, and per client otherwise. Exceeding one returns 429 with RATE_LIMITED and a Retry-After header.
| What | Limit |
|---|---|
| Creating launches | 5 per minute |
| Directory search | 30 per minute |
| Sign-in challenges | 20 per minute |
| Uploads | 10 per minute |
| Submitting a claim | 3 per hour |
| Everything else | 120 per minute |
The codes worth handling by name:
| Code | Status | What it means |
|---|---|---|
UNAUTHENTICATED | 401 | No session, or a missing CSRF header on a write |
NONCE_EXPIRED | 401 | Five minutes passed. Ask for another |
IDEMPOTENCY_CONFLICT | 409 | That key already produced a launch |
TRANSACTION_NOT_CONFIRMED | 409 | The signature has not landed yet. Retry, do not resend |
TRANSACTION_MISMATCH | 409 | That transaction is not the launch it was submitted for |
METEORA_NOT_CONFIGURED | 503 | This deployment cannot launch anything |
VALIDATION_ERROR | 400 | Check fields |
There are no webhooks. Poll /api/launches, or read the pool accounts directly — they are the source this site polls too.
Something here wrong, missing, or out of date? Launch a token and see for yourself — the numbers on this page are read from the same configuration the transaction is built from.