How abc.fun works

abc.fun is a Solana token launchpad built around five features. Each one changes a specific rule of a launch, and each one has limits that this page spells out.

ABC AUCTION

A 30 second uniform-price opening auction. Everyone who fills pays the same price.

ABC LOCK

The declared dev allocation and creator fees are held by the program for 24 hours.

ABC PASSPORT

A builder profile that separates verified onchain facts from self-reported claims.

ABC REWARDS

A share of every fee accrues to holders, weighted by time-weighted balance.

ABC FLOW

Scheduled, voluntary limit-order windows on the chart that clear at one price.

Every launch opens with a 30 second auction for 20% of the 1,000,000,000 token supply. Bids are a SOL budget plus a maximum price. When the auction closes, one clearing price is computed and everyone who fills pays it.

Tick grid

Prices live on a grid of 256 ticks, 1.5% apart, starting at the floor. It is computed with integer math so the program and this site agree bit for bit:

p_0     = floor price
p_(k+1) = floor(p_k * 10150 / 10000)      k = 0..254

Prices are stored as priceQ: lamports per token base unit, scaled by 10¹². 28 lamports per whole token is 28_000_000.

Clearing

1. For each tick k from the top down, demand in tokens is D(k) = floor(sum of budgets with max_tick ≥ k / p_k).
2. The clearing tick k* is the highest k with D(k) ≥ Q, where Q is the tranche. If no tick reaches Q, the auction is undersubscribed: it clears at the floor, every bid fills in full, and unsold tokens go to the pool reserve.
3. Everyone pays the same price p_k*.
4. When demand exceeds supply, bids above the marginal tick fill in full (price priority), and bids exactly at the marginal tick share what is left pro rata by budget.
5. Per bid: tokens = floor(…), cost = ceil(tokens × p), refund = budget − cost. Rounding always favors the vault, so it can never be short.

Sequential remainder allocation

Each bid settles in its own transaction, in whatever order crankers choose. To keep the marginal pro rata exact, the program keeps two counters: R_rem (tokens left at the marginal tick) and W_rem (budget weight left). Each settled bid takes its share and both counters shrink:

share = (w == W_rem) ? R_rem : floor(w * R_rem / W_rem)
R_rem = R_rem - share
W_rem = W_rem - w

The last bid takes exactly what remains, so the sum is exact regardless of order. Order can shift an individual fill by at most one base unit.

Settlement and failure

• Budgets are escrowed in the auction vault. Bids are public onchain and can be raised, not withdrawn.
• finalize_auction and settle_bid are permissionless. A keeper runs them; so can anyone.
• If nobody finalizes within 10 min of close, anyone can call abort_auction. Every bidder gets a full refund and the launch is marked failed.
• After settlement the pool opens at exactly the clearing price (see the ABC curve).

A creator may declare a dev allocation from 0 to 10% of supply. It is minted straight into a LockVault program account at launch. claim_dev_allocation checks now ≥ unlock_ts, where unlock_ts is launch plus 24 h. There is no admin or early-release path in the program.

Creator fees accrue to a CreatorFeeVault from the first trade. Withdrawals are rejected until the same unlock time. After that the creator can claim at any time.

What ABC controls, and what it does not

• Locked by ABC: the LockVault and CreatorFeeVault for that launch.
• Not controlled by ABC: every other wallet, including tokens the creator buys in the auction or on the curve from other wallets. Token pages label holders this way.

A lock delays a sale. It does not prevent one after the unlock, and it says nothing about other wallets.

A Passport is the creator's public profile: bio, story, links, a pinned intro, posts, a timeline and every launch from that wallet. Builders sign in with Solana: the wallet signs a one-time message (no transaction, no fee) and the server issues a session.

• Verified items come from onchain data: launches by this wallet, lock status, dev allocation and claim history.
• Self-reported items are what the builder says: bio, links, story. They are labeled as such. Linking an X account with verification is an integration point, not live.
• Edits keep a history. Anyone can report a profile for impersonation or abuse.
• First-time builders get an empty-state profile that says so plainly, rather than looking established.

A Passport helps you judge who you are dealing with. It is not an endorsement by abc.fun. Open your Passport

The holder share of each fee (30% by default) accrues to a HolderRewardVault per token. Each epoch (24 h in production, 10 min in the demo) that accrual is distributed to eligible holders.

Method

1. For every wallet, compute the time-weighted average balance (TWAB) across the epoch: the integral of balance over time divided by the epoch length.
2. Exclude program accounts: the pool, the LOCK vault, auction and FLOW escrows, fee vaults. Exclude wallets whose TWAB is under 100,000 tokens.
3. Each eligible wallet receives floor(vault_accrual × twab / eligible_weight). The remainder stays in the vault.
4. The publisher builds a Merkle tree over all allocations and posts the root with the epoch total. The program rejects a root whose total exceeds what the vault accrued that epoch.
5. Holders call claim_reward(epoch, amount, proof). A claim bitmap blocks double claims.

leaf = sha256(0x00 || epoch u64 LE || mint[32] || wallet[32] || amount u64 LE)
node = sha256(0x01 || min(a, b) || max(a, b))      sorted pair, byte order

• Rewards follow holding, not volume. Wash trading only pays fees.
• Splitting a balance across wallets earns nothing extra, because the share is linear in balance.
• The inputs and the script are published so anyone can recompute every root. The publisher key is a retained authority (see Authorities).
• Rewards depend on trading activity. An epoch with no fees distributes nothing.

See the live fee split and your demo rewards

FLOW is a voluntary, OTC-style limit-order window on each token's chart. It is never a freeze, a queue, or a permission to sell. Spot trading stays available during every window.

SCHEDULED --open_ts--> OPEN --close_ts - 5s--> FINAL 5s --close_ts--> CLOSED
  --clear_window--> CLEARED --settle_order (each)--> SETTLED
  (or --abort_window after grace--> ABORTED: every order refunds in full)

Grid and orders

At open the window fixes 81 ticks centered on the pool's EMA price (roughly ±20%), using the same integer stepping as the auction. Out-of-band limits are clamped in the user's favor: a buy max above the grid becomes the top tick, so the buyer can only pay less; a sell min below the grid becomes the bottom tick, so the seller can only receive more.

• Sell (qty, min_tick) escrows the tokens.
• Buy (qty, max_tick) escrows ceil(qty × p_max) + fee lamports.
• Per-tick totals live in the window account, so placement is O(1) and clearing is O(81).
• Cancels are allowed while open, not in the final seconds. New orders are accepted until close.

Clearing rules

V(t) = min(BuyAtOrAbove(t), SellAtOrBelow(t))
t*   = argmax V(t)
ties: smallest |buy - sell| imbalance, then closest to the reference tick, then the lower tick

• All fills trade at the uniform price p_t*.
• The short side fills in full. The long side fills by price priority, then pro rata at its marginal tick with the same sequential remainder method as the auction.
• Buyers pay ceil(fill × p) plus fee. Sellers receive floor(fill × p) minus fee. Tokens balance exactly. Rounding dust, at most a few lamports, goes to the protocol vault.
• Unfilled quantity and unused escrow return at settlement.

Liveness and what FLOW does not promise

• clear_window and settle_order are permissionless. No offchain matcher holds authority.
• Orders are public onchain. The UI shows anonymized per-tick interest, not identities.
• Not every order fills. A window can close with no cross, and every order is then returned.
• FLOW fills are peer to peer and never touch the pool, so they do not move the spot price on the chart. That is not a claim of zero market impact: large fills still change what people are willing to pay next.

Each token trades against an in-program constant-product pool with a virtual SOL reserve. Only real SOL can ever leave the pool.

x = real_sol + virtual_sol
y = token_reserve
x * y = k
at settlement: virtual_sol = p* * y - real_sol      (opening spot price = auction price)

• Real reserve guard: a sell that would take real_sol below zero is rejected. The UI shows real SOL liquidity separately from the virtual reserve.
• The liquidity share of each fee converts virtual SOL into real SOL. x stays the same, so the price does not move, but real backing grows.
• The pool keeps a time-weighted EMA price (half-life 5 min) that FLOW uses to center its grid.
• Graduation to an external AMM (for example Meteora DAMM v2 or Raydium CPMM) is an integration point: documented, not implemented. SDK names and versions must be verified at integration time.

Every fee is split in basis points, always summing to 10,000:

Each part is rounded down and the remainder goes to protocol, so the parts always add up to the fee:

These keys exist and are disclosed. No private keys or signing credentials are kept in the repository.

• Unaudited. The Anchor program has not been audited. Do not use it with real funds before an independent security and economic review.
• Not deployed. Program IDs are placeholders.
• Demo data. Markets, counterparties, auctions, FLOW windows and rewards on this site are simulated. Simulated transactions say so.
• Bots can still bid. Uniform pricing removes the speed advantage inside the window, not automated participation.
• Orders are public. Auction bids and FLOW orders are visible onchain.
• Sybil limits. Per-wallet caps can be bypassed with more wallets.
• Tokens can go to zero. Launch tokens are speculative. You can lose everything you put in.
• Offchain dependencies. Rewards need the publisher; keepers speed up settlement but anyone can run it.
• No financial advice. Nothing on this site is investment advice.

Trust boundaries: the program holds all funds and enforces every rule above. The frontend, indexer, keeper and publisher hold no custody. If the keeper stops, anyone can call the same instructions.

The demo wallet lets you try everything without a browser extension. It is a throwaway ed25519 keypair generated and kept in this browser's local storage.

• It starts with 25 demo SOL. Demo SOL is not real and cannot be withdrawn.
• It signs messages, so Passport sign-in works. It refuses to sign or send transactions.
• Clearing site data deletes the key. You get a new identity next time.
• Real wallets can connect too. Your address is used to key a separate simulated balance; nothing is ever signed or sent onchain in demo mode.
• Never send real funds to a demo wallet address.

Open your demo portfolio · Read the FAQ