BURNABLERead the fire.
One billion at birth. Less after every trade.
The mechanics behind a market that burns its own supply.
Born with a limit.
Every launch starts with 1,000,000,000 tokens, with 18 decimals. There is no mint function. Burns permanently reduce the remaining supply.
Buyers trade against a USDC bonding curve. Buys move up the curve; sells move back down. The curve completes at a 10,000 USDC net reserve. That target is a reserve, not a market cap.
The initial full-supply valuation is approximately 4,444.44 USDC, at 0.0000044444 USDC per token before fees and rounding. Circulating supply starts at zero before the first buy.
Add a logo from your computer or use an HTTPS image URL. Uploads accept PNG, JPEG, WebP and GIF, up to 2 MiB and 16 megapixels. The image is fitted into a 512 × 512 WebP; animated uploads use their first frame. The chosen logo URL and social links become part of the token’s immutable launch metadata.
Trade. Burn. Repeat.
Every successful buy and sell through the Burnable curve or its canonical Uniswap v4 hook pool funds a token burn in the same transaction.
The default trade fee is 2%. A 1% USDC budget buys the launched token and burns it. The other 1% is split: 0.7% to the creator and 0.3% to the platform.
A creator can add 0–8% at launch. All of that extra goes to the creator, and it is fixed after launch. For example, 1% extra makes a 3% total fee: 1% burn budget, 1.7% creator and 0.3% platform.
The launched token is burned, not USDC. A 1% burn budget does not mean 1% of total supply disappears per trade. Normal token transfers and unrelated pools are outside this mechanism. Lower supply does not guarantee a higher price; demand and liquidity still decide the market.
The curve ends. The burn doesn’t.
The buy that completes the reserve target also opens the canonical Uniswap v4 pool and permanently locks its initial liquidity. It all happens in one transaction. If migration fails, that completing buy reverts too.
No separate creator action, admin trigger or scheduled keeper is needed. The pool retains the same burn and revenue rules through the Burnable hook.
The 250M liquidity allocation joins the reserve. Rounding dust stays locked; unsold curve dust is burned separately from trade burns.
Create a token. Earn USDC.
Creator and platform revenue is accounted in the market’s USDC pair and automatically swept to the recipient. Creators do not receive fee payments in their launched token.
Open Profile to see the tokens your connected wallet launched, lifetime earnings and pending USDC. Claim applies only to pending credits, such as an automatic payout that could not complete. Already paid earnings cannot be claimed again.
Arc’s native gas balance uses 18 decimals. Its canonical USDC ERC20 interface uses 6. They represent the same underlying balance, so never add them together. Leave enough USDC for gas.
Arc network reference ↗Open the source.
All eight Burnable contracts below have exact-match source verification on the official Arc explorer, including the BTEST smoke-test token. Checked on 17 September 2026.
0xa877292d1e0e033b96Eb64c4372B61Ca60Fc869cFee vaultExact match ↗0x3dc7848195524E57532D0Eb292BaC84919cd0c04Burn hookExact match ↗0x5a1227806a543C50A087f93a265004FA01a560CCTrade routerExact match ↗0x85E1C82139af3f92c646d97f010103e86aC090fbTrade quoterExact match ↗0x939702a9E341B4E1263B885A8761a5f019BA59CBUSDC pricingExact match ↗0xf4D48742fd3cE18396fF06d41546A2898143d56aHook deployerExact match ↗0x1D5733780247b4d0beB34bC9b1357F32886B496eBTEST sample tokenExact match ↗0x6367d4a17Dc40f57569f9cc6CCA59F380CdAE574The external Uniswap PoolManager ↗ has an existing partial-match source verification. It is a separate deployment.
The separate A/X Explorer also confirms 7 of the 8 Burnable sources as runtime matches, including BTEST ↗. Only the CREATE2 hook awaits contract indexing by that explorer. Its live bytecode matches the verified deployment. The official Arc verification above is complete.
Source verification proves that published source corresponds to deployed bytecode under the explorer’s matching rules. It is not an independent security audit.
Build with Burnable.
Use the public integration bundle for Arc chain ID 5042, deployed addresses, runtime hashes, exact ABI entries and verification links. Bundle version 1; index from deployment block 21217916.
GET /api/chain/stateChart, holders & full historyGET /api/chain/archiveGlobal 24h market activityGET /api/chain/archiveRecent canonical tradesGET /api/chain/activityGET /api/chain/quoteGET /api/chain/launch-quotePass network=arc. Trade quotes require token, account, side=buy|sell and a positive integer amount: 6 decimals for USDC buys, 18 for token sells. slippageBps accepts 10–500 and defaults to 100. Quotes expire after 45 seconds; use their minimum output, deadline and verified chain identity.
These chain endpoints read or simulate; they do not sign or send trades. The older activity endpoint covers at most the latest 10,000 blocks and 40 trades. Use the persistent archive for full indexed history.
Charts, holders and archive coverage
The archive replays canonical logs from deployment and keeps a verified block checkpoint. Pass token for one market, or omit it for global market activity. hours=1|6|24|all controls candles and selected-window totals; the default is 24.
Use holdersOffset for pages of 25 holders, and tradesOffset or burnsOffset for pages of 40 records. Offsets start at zero; a null next offset ends that snapshot’s history. Trade and burn pages cover history from launch, independently of the chart range.
index.status is ready or syncing. Check indexedBlock, indexedTimestamp and the window’s completeness before using a 24h total. The block timestamp, not the response time, proves freshness. Initial responses may have archive: null. Holder balances and supply are shown at the committed block.
Candlestick charts use actual open, high, low and close execution prices, including fees. Empty intervals have no candles. Volume is gross USDC: buy input, or sell output plus its fee. Trending ranks positive 24h volume across all indexed Burnable markets.
Holder balances replay token transfers from the initial mint. Curve inventory and pool contracts are labeled separately. Burn history distinguishes trade burns, graduation dust and voluntary burns. A canonical block-hash change rolls back affected history before it is rebuilt.
Ready responses may be cached for 10 seconds in the browser and 30 seconds at the edge; syncing responses are not cached. The app checks syncing history every 10 seconds and ready history every 60 seconds.
Indexing events and pool identity
Discover tokens through LaunchCreated from the launchpad. Read curve trades from its Trade event. Canonical pool activity uses the Uniswap v4 manager’s Swap event and the Burnable hook’s fee and burn logs; PoolTrade identifies users of the Burnable router. Scope every event to its contract address, pool ID, token and canonical transaction.
Match each user swap to its own hook fee and burn interval. Exclude the hook’s internal buyback swaps from user volume. A transaction may contain multiple trades, so do not assign whole-transaction totals to each row. External routers using the canonical pool are covered, but an unproven end-user identity remains trader: null. Unrelated pools are outside this archive.
The pool ID is a bytes32 value from getMarket(token).poolId, poolIdOf(token) or Graduated. The hook address is not the pool ID.
The quoter’s quoteExactInput is nonpayable in its ABI but must be simulated with eth_call. No transaction is required to obtain a quote.
On GMGN, with a clear boundary.
BTEST is discoverable on GMGN ↗. Token metadata, its holder and burn transfers are visible. Burnable is currently labeled “Unknown”; canonical curve trades and price are not confirmed as indexed.
Token discovery is not a completed launchpad integration. GMGN showed conflicting source-verification labels. BTEST is now verified on both explorers; a refresh of GMGN’s labels has not been confirmed.
Your wallet. Your public footprint.
Your address, trades and launch metadata are public onchain. Launch descriptions, social links and image URLs become part of permanent transaction history.
Wallet connection providers may use local storage to preserve their session. Burnable also stores pending transaction hashes locally so a reload can recover a submitted transaction. Connecting or trading does not require sharing a private key or recovery phrase with Burnable.
The website host, RPC and wallet providers receive the technical information needed to handle requests. Burnable stores canonical public market events to serve charts, activity and holder balances.
Uploaded logos are decoded and re-encoded as a static WebP with embedded EXIF/XMP metadata stripped. Only the normalized image is stored; its SHA-256 content hash forms a publicly accessible URL. The original filename is not used. The image URL becomes part of permanent launch metadata when you create the token.
You can still use an external HTTPS image URL. Your browser loads it with no-referrer, and that image host receives the request. An external URL does not upload its image to Burnable.