Launch a token on X1, or read what has been launched. Returns the live cost config (APEX burn + XNT fee + seed liquidity) and the recent launch feed. The build endpoints return unsigned transactions you sign yourself.
ConnectorNo auth
734,550 tools. Updated 2026-11-02 06:19
"Launchpad" matching MCP tools:
- OpenFinance Launchpad — Solana token launchpad on a dynamic bonding curve. Launch a new SPL token in a single tx, trade it on a bonding curve, and graduate to a DAMM v2 AMM once the curve fills. Single-tool dispatch on `action`. ROUTING: • To LAUNCH a new token: use action='launch_token'. • To TRADE a DBC token PRE-graduation (still on the bonding curve): use action='buy' / 'sell' here. • To TRADE a DBC token POST-graduation: it's a DAMM v2 pool now — route through Jupiter (`onchain_jupiter_order` + `onchain_jupiter_execute`). Calling 'buy'/'sell' here on a graduated pool returns `alreadyGraduated: true`. • The PoolConfig PDA (env METEORA_DBC_CONFIG) controls total supply, decimals, fee tier, curve shape, and graduation threshold — these are NOT per-launch params. ACTIONS: launch_token — { name, symbol, image (base64), description?, website?, twitter?, telegram?, configAddress?, initialBuySol? }: pins image + Metaplex JSON metadata to IPFS via Pinata, generates a fresh mint keypair, calls DBC createPool. Set `initialBuySol` to also buy the new token in the SAME tx (creator "dev buy" — atomic, no snipe risk; creator needs ~0.035 SOL launch cost + the buy amount). Returns { mintAddress, poolAddress, metadataUri, imageUri, signature, initialBuySol?, initialBuyTokens? }. **DESTRUCTIVE — creates a permanent SPL mint on mainnet.** Always confirm with the user before calling. **WEBSITE NUDGE — `website` is optional but recommended: tokens that ship with a website tend to bond/graduate at a higher rate (more credible to traders). Before launching, if the user hasn't given a `website`, suggest adding one — e.g. "Want to add a website? Tokens with one tend to graduate more often. It's optional — I can launch without it." Launch fine without it if they decline; never block the launch on it.** list_tokens — { limit?, offset?, sort?, creator? } (PUBLIC — no auth): paginated explore feed of every token launched under the partner config. sort 'newest' (default, by on-chain activation time) or 'mcap' (market cap desc). limit ≤100 (default 30). Pass `creator` (a Solana wallet) to filter to one launcher's tokens — use this for "show me my launched tokens" / "what has wallet X launched". Returns { tokens: [{ pool, mint, name, symbol, image, description, website, twitter, telegram, externalUrl, metadataUri, creator, createdAt, curveProgress (0-1 bonding fill), graduated, priceSol, marketCapSol, marketCapUsd }], total, limit, offset, solUsd }. `website`/`twitter`/`telegram` fall back to Codex's own indexed data when our own launch record doesn't have them (e.g. older launches) — our stored value always wins when present. get_pool_state — { poolAddress }: returns { baseMint, quoteMint, graduated, quoteTokenCurveProgress (0-1), baseTokenCurveProgress (0-1), migrationQuoteThreshold }. Call before any buy/sell to check graduation status and mcap progress. quote_buy — { poolAddress, quoteAmount, slippageBps? }: returns { amountIn, amountOut, minimumAmountOut, priceImpactBps, alreadyGraduated }. `quoteAmount` is in the quote token's smallest unit (lamports for wSOL, atomic for USDC). quote_sell — { poolAddress, baseAmount, slippageBps? }: mirror. `baseAmount` is in the new token's smallest unit. buy — { poolAddress, quoteAmount, slippageBps? }: signs + broadcasts a buy. Returns { signature, amountIn, minimumAmountOut, amountOutQuoted }. sell — { poolAddress, baseAmount, slippageBps? }: mirror. migrate — { poolAddress }: anyone can call once `quoteTokenCurveProgress >= 1`. Migrates remaining reserves into a DAMM v2 pool, mints two LP-position NFTs. Returns { signature, firstPositionNft, secondPositionNft }. get_pool_fees — { poolAddress }: read-only claimed/unclaimed/total fee breakdown for a pool, split into creator and partner. Use to show a launcher how much they can withdraw. get_creator_fees — {}: the caller's accumulated creator fees across EVERY token they launched. Returns { creator, pools: [{ pool, creatorBaseFee, creatorQuoteFee, hasUnclaimedCreatorFees }] }. claim_creator_fees — { poolAddress }: withdraw the caller's creator trading-fee share from one of their pools to their own Privy wallet. Returns { pool, signature, receiver }. Show the unclaimed amount (from get_creator_fees / get_pool_fees) and confirm before calling. **⚠️ SAFETY — launch_token is irreversible.** Before calling, show the user: name, symbol, image preview link (the IPFS gateway URL after upload), the PoolConfig PDA being used, total cost in SOL (~0.035 SOL), and require explicit confirmation. Solana wallet must be delegated to the app (412 on first call otherwise). **⚠️ SAFETY — buy/sell are real swaps.** Always show the quote (input/output, slippage, price impact) before submitting and require user confirmation, same shape as Jupiter execute.ConnectorOAuth
- OpenFinance launchpad (the "wrapper") — launch a token on Robinhood Chain (EVM, chain id 4663) with a FEE MODULE that decides, permanently, where its trading fees go. This is the "launch a token that burns its fees / splits them / runs a raffle / pays its holders" tool. **THIS IS THE DEFAULT LAUNCH TOOL FOR THE PONS CURVE ON ROBINHOOD CHAIN** — a plain launch with nothing said about fees uses module='keep', which sends the fees to the creator's own wallet and is the only module that can be repointed later. Do NOT use openfinance-pons-launch for a new launch; this tool launches on the same Pons curve, with the fee router added, so it is a superset. **It is not the only launch venue on this chain.** openfinance-launchpad-v4 is a separate product: a launch there IS a real Uniswap V4 position, paired against an approved quote token such as USDG, with a snipe tax and no fee modules. Route to it when the user names Uniswap or V4, names a pair asset like USDG, or wants the token tradable through the Uniswap router. If the user says only "launch a token on Robinhood Chain" with nothing about fee modules or Uniswap, ASK which venue — the pools are not interchangeable and the choice is permanent. HOW IT RELATES TO openfinance-pons-launch: • Same chain, same Pons curve underneath, same Privy EVM wallet. The token still trades on Pons. • This adds a fee router, so fees can be kept, sent to one wallet, split, burned, raffled, or airdropped to holders. • openfinance-pons-launch remains only for READING Pons state (quote assets, launch terms) and for the fee-claim actions on tokens launched through it BEFORE the wrapper existed. Its launch action is legacy — do not route a new launch to it. • **Module choices are FROZEN AT LAUNCH**, with one exception: `keep` may be repointed later (`FeeRouter.repointWallet`). A burn, split, raffle or holders module cannot be changed afterwards — no admin key, no migration. Treat those like deploying an immutable contract. • Every launch keeps 5% of its fee bucket (500 bps) for the keeper's gas. This is not optional and not a platform fee: without it the launch could never have its fees moved, and the keeper refuses to service it. The module gets the other 95%. MODULES (pick one, frozen): keep — fees to the creator's own wallet. wallet — fees to one named wallet (`recipient`). split — fees divided between 2-16 wallets (`split`), bps totalling exactly 10000. burn — fees buy the launched token back and burn it. raffle — fees fund a periodic prize draw among holders (`raffle`, required). holders — fees airdropped pro-rata to holders (`airdrop`, optional; defaults are sensible). ROUTING: • A bare "launch a token" with no fee preference → this tool, module='keep'. Do not ask the user to choose a module they did not raise; `keep` is the plain behaviour and is repointable. • Call action='get_readiness' first for a raffle launch — it reports whether the keeper and randomness contracts are live, and lists the stock assets a stock-prize raffle may use. A raffle launched without a live keeper would never draw. • Call action='simulate_launch' before action='launch' for anything non-trivial. It builds and validates the exact transaction without sending it, so a bad split or an impossible raffle fails for free. • action='list_launches' is the public feed of every launch from this factory, newest first — the "what has been launched" question. ACTIONS: launch — { module, name, symbol, description?, logo?, creatorTaxBps, pairToken?, developerBuy?, recipient?, split?, raffle?, airdrop? }: `module` — one of keep|wallet|split|burn|raffle|holders. Frozen. `creatorTaxBps` — the TOTAL trading tax in basis points, capped by Pons's live limit. The wrapper's own protocol surcharge is included in this number, not added to it. `pairToken` — optional; the asset the token trades against (a symbol or address — use openfinance-pons-launch's list_quote_assets to enumerate them, including Robinhood's tokenized stocks). Defaults to ETH. `recipient` — required for module='wallet'. `split` — required for module='split': [{ recipient, bps }], 2-16 entries, bps summing to EXACTLY 10000. They do not sum if each share is rounded independently — three equal shares floor to 9999 — so floor each and give the remainder to one recipient. `raffle` — required for module='raffle'. Frozen terms: cadence, prize pool share, winners per round, ticket size, prize bounds. **DESTRUCTIVE AND IRREVERSIBLE — launches a real token on mainnet, commits real funds for the launch fee, and freezes the fee module forever.** Show the user: module, resolved pair asset, creatorTaxBps, the 5% keeper slice, and every recipient/share. Require explicit confirmation. simulate_launch — same arguments as launch: builds and validates the transaction WITHOUT sending it. Returns the resolved allocations, the launch fee and the would-be addresses. Free and safe — prefer it before any launch. list_launches — { limit?, offset? } (PUBLIC — no auth): every launch from this factory, newest first. Returns { total, tokens: [{ token, curve, creator, name, symbol, router, adapter, raffle, pairToken, launchedAt, feesOwedWei, marketCapUsd }] }. `launchedAt` is a unix second from the launch's own block — a launch carries no timestamp on chain, so this comes from its `Deployed` event. `feesOwedWei` is what its buckets hold but have not yet delivered. `marketCapUsd` is null until a market-cap provider indexes the token, which is normal for a launch still on its bonding curve with no DEX pair. get_launch — { token } (0x… address): one launch's fee module and routing, read from the contracts. Returns its module, buckets, allocations, router, adapter and raffle. get_funding — { token } (0x… address): why a launch's fees have or have not moved. Returns { paidWei, spentWei, fundingWei, ledger }. `paid` is on chain (what the router has sent the keeper hub); `spent` comes from the keeper's own ledger. The keeper cranks a launch only when the fee covers the gas, so `fundingWei` is the number that explains a launch whose fees appear stuck. `ledger: null` means the keeper has never worked this launch, so spend is zero. list_creator_launches — { creator } (0x… address) (PUBLIC — no auth): every launch by one creator, with the same enrichment as list_launches. get_raffle — { raffle } (0x… address): a raffle's live state — current round, cadence, prize terms, and whether a round is drawable. get_raffle_claims — { raffle, wallet, round? }: a holder's claimable prizes with their Merkle proofs. The proofs come from the keeper's database; whether a slot is already PAID comes from the contract, which is authoritative. list_raffle_stocks — {} (PUBLIC — no auth): the tokenized-stock assets a stock-prize raffle may pay out in. get_readiness — {} (PUBLIC — no auth): whether a raffle can be launched at all in this environment — keeper hub, randomness contract, and whether the hub owner has paused launches. Call before offering a raffle launch. get_keeper_status — {} (PUBLIC — no auth): a deployment check, not launch data. Reports whether this host can reach the keeper's database and whether the keeper is alive. An unreachable database is a SUPPORTED state — proofs fall back to a slower rebuild from transfer history — so `configured: true` with `reachable: false` means proofs still work but the indexed path is not in use. **⚠️ SAFETY** — launch is irreversible, commits real funds, and freezes the fee module permanently. Always simulate_launch first, show the resolved allocations including the 5% keeper slice, and get explicit confirmation.ConnectorOAuth
- OpenFinance launchpad on **Uniswap V4** (Robinhood Chain, EVM chain id 4663) — launch a token whose bonding curve IS a real Uniswap V4 position, trade it through the Universal Router, and graduate it into locked full-range liquidity. **WHICH LAUNCH TOOL TO USE ON ROBINHOOD CHAIN.** There are three, and they are different venues — not alternative spellings of one: • `openfinance-launchpad-v4` (this tool) — Uniswap V4 pools, paired against an APPROVED QUOTE TOKEN (e.g. USDG), with a snipe tax and a creator tax. Use when the user names Uniswap/V4, names a quote asset such as USDG, or wants the token tradable through the Uniswap router. • `openfinance-launchpad-wrapper` — the Pons curve plus a permanent FEE MODULE (burn / split / raffle / holders). Use when the ask is about where the fees go. • `openfinance-pons-launch` — legacy Pons reads only. If the user just says "launch a token on Robinhood Chain" with nothing about fee modules or Uniswap, ASK which venue rather than guessing: the choice is permanent and the pools are not interchangeable. For SOLANA launches use `openfinance-launchpad` (Meteora DBC) — a different chain entirely. **HOW A LAUNCH WORKS HERE** 1. `launch` deploys the token and opens a V4 pool against `pairToken` (an approved quote asset — call `list_quote_assets` first; passing anything else is rejected on chain). 2. The curve is a V4 position, so the token is tradable through the Universal Router immediately. `buy` / `sell` go through `get_quote` → router. 3. When the curve fills, the launch **graduates**: reserves become locked full-range liquidity. `buy` may graduate as a side effect when the buy consumes the rest of the curve — the response says `side: 'graduate'` when that happened. **AMOUNTS ARE BASE UNITS.** `amount` on buy/sell/quote is a raw integer string in the token's smallest unit, never a decimal. The pair asset's decimals are NOT always 18 — USDG is 6, so 1 USDG is "1000000". Read `decimals` from `list_quote_assets` and convert; a 10^12 error here spends a million times the intended amount. **TAXES, AND WHY A QUOTE IS CALLER-SPECIFIC** • A **snipe tax** of 99% applies for the first 3 seconds after launch, decaying to 0. It depends on WHO is swapping, so `get_quote` simulates from the trader's own address. A quote taken for someone else misprices that window and the swap then fails its minimum output. • A **creator tax** (0-10%, `creatorTaxBps`) is fixed at launch and cannot be changed afterwards. • The hook takes 1% of each swap; 30% of that is the protocol's share. **DEV BUY.** `devBuy` is an amount of the PAIR token (a decimal string here, e.g. "1" for 1 USDG — the server converts using that asset's decimals) bought for the creator in the same transaction. It needs that balance in the user's server wallet; the server sends the ERC20 approval itself. **IRREVERSIBLE.** A launch deploys a contract and opens a real pool with real liquidity. Name, symbol, pair token, and creator tax are frozen at launch. Confirm the parameters with the user before calling `launch`, and never launch to "test" the tool. ACTIONS: Reads (no key needed): get_readiness, list_quote_assets, get_pair_terms, list_launches, get_pool, get_market, get_candles Reads (key): get_quote, get_fees Writes (key, real money): launch, buy, sell, graduate, claim_fees Prerequisite: `openfin-setup` — the user needs a server-authorized Privy EVM wallet (POST /agent/auth/authorize-server), funded with the pair token for a buy or a dev buy.ConnectorOAuth
- The main Moby token leaderboard: the tokens with the most notable activity right now, ranked best-first by Moby's composite 24h score. Start here when the user asks what is moving, what is trending, or what they should be looking at, and they have not named a specific token. Page 1 is the top of the board — for 'what is hot right now' the default page is the whole answer. Moby's leaderboards: Main = `get_screener_leaderboard` (composite 24h activity, 'what's moving'); Degen = `get_degen_leaderboard` (newer, smaller, higher risk); Majors = `get_group_leaderboard(group_id="home_majors")`; Stocks = `get_group_leaderboard(group_id="home_stocks")` (tokenized stocks); Pulse = `get_group_leaderboard(group_id="home_pulse")`. The Solana group ids `majors_solana` / `stocks_solana` work too, and the `home_*` ids are listed under `home_tabs` in `get_screener_groups`. The Majors and Stocks boards are THE reference for major and tokenized-stock contract addresses: take `token_address` from the row. Never resolve a major or a stock by ticker search alone, and never keep your own mint list. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. `whale_windows` (any of h1/h4/h8/h24) adds a per-row `whale` block per window: whale_count (distinct tracked wallets that bought OR sold — buyers plus sellers, not buyers alone), whale_buyers_count (distinct buyers only), whale_buys_count, whale_sells_count and whale_net_flow_usd. The row's `whale_count_h24` is the same buyers-plus-sellers count. Null figures mean unknown. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.ConnectorNo auth
- WHO CREATED a Robinhood (robinhood, rh, Robinhood Chain) contract, and what a creator deployed. Answers "who created / deployed this token", "who is behind this contract", "what else did this deployer launch", and "were these tokens made by the same person" (serial deployers, rug and clone farms). NOT who funded a wallet → use robinhood_first_funder. On this chain a token IS a contract, so pass the TOKEN'S CONTRACT ADDRESS in contracts. TWO WAYS TO CALL IT, pick one - setting both is refused, because the two answer different questions and their shared-creator counters would be mixed: contracts="0x..|0x.." - up to 50 contracts, one row each: Creator (the address whose code ran CREATE), Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used and Deploy_Success. Rows whose creator or signer is SHARED come first: Creator_Shared / Signer_Shared count how many of the requested contracts have that same creator / signer, which is what exposes one person behind many tokens. A longer list is not an error: the first 50 distinct addresses are used and the rest ignored - compare Contracts_Requested with Contracts_Used and split a longer list into several calls. creator="0x.." - the contracts THAT address deployed, newest first, inside the window (days, after_time, before_time), at most `limit` rows. Use it on the Creator or Signer a first call returned, to see the rest of that deployer's output. Creator_Shared is empty in this form - every row has the same creator by construction, so the counter would only repeat the row count. Creator_Is_Contract = 1 means the contract was deployed BY OTHER CONTRACT CODE - a token factory, a launchpad or a DEX pair factory - and then Creator is that factory, which is the SAME address for every token it ever made, while Signer is the person who asked for it. On a factory-made token read Signer, not Creator. Deploy_Depth is how deep inside the transaction the deployment happened (0 = the transaction itself) and Call_Index is the deployment's position in that transaction - one transaction can deploy several contracts, and Call_Index is what tells those rows apart when everything else about them looks the same. Status = NOT_FOUND means no deployment is recorded for that address: it is a plain wallet, not a contract, or the deployment is older than the recorded history of this chain. Creations is normally 1; a higher number means the address was created more than once (destroyed and redeployed), and the row describes the EARLIEST creation. THE CREATOR'S STORY IS NOT IN THIS TOOL - build it from the returned addresses: labels_for_addresses (is the creator a known entity, exchange or scammer), robinhood_first_funder (who funded the creator, and whether several creators share one sponsor), robinhood_address_profile and robinhood_transfers_in / robinhood_transfers_out (what that wallet does), robinhood_flows_between (what moved between the creator and the token). The token's own name, symbol, price and market cap come from find_token_by_address; its first buyers from early_buyers. Amounts are the native coin, never USD. COST: a contract lookup has to walk every call that address ever received, so a handful of ordinary tokens answer in a second or two while one exchange-scale contract can take ~20 s on its own. If you already know roughly when the contract appeared, bound it with after_time / before_time - that alone took one busy token from 21 s to 2 s. A row-limit error ("Limit for rows ... exceeded") means the batch is too busy: bound it that way, or split the list.ConnectorOAuth
Matching MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables monitoring token launch liquidity pools, tracking whale wallet activity with USD-based alerts, and analyzing market sentiment across social, news, and on-chain sources.MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP gateway that connects an owner's existing AI assistant to Estonian business back-office work: company profiles and obligation calendars built from public register data, job playbooks, curated connector catalogue, and server-enforced approvals with receipts. It lets a micro-entrepreneur's chat assistant read deadlines, check counterparties and draft filings while blocking any action that lacks an approval bound to the exact recipient, amount and document.7 npmMIT
Matching MCP Connectors
Read-only, sourced and dated facts on AI tools: search, compare, pricing, free alternatives.
Dual-version MCP for pons token launches on Robinhood Chain: v1 trading, v2 curve reads (plan-only).
- DEX VENUES / pools / launchpad breakdown for ONE token (or up to 50) over a time window — which DEX protocols, AMM programs and liquidity pools it trades on, ranked by USD volume or trade count, with buy vs sell trades, buy / sell volume, buyers, sellers and first / last price; group_by=token gives the token's TOTAL trade stats for the window instead. Use for "which DEX / launchpad does <token> trade on", "top pools for <token>", "is <token> on Raydium / LaunchLab / Uniswap / PumpFun", "where is the liquidity", "how many trades / buyers / sellers / volume did <token> have in the last hour". NOT trader wallets (use top_traders_by_token), NOT a price chart (use token_ohlcv), NOT a per-minute series (use token_trade_bars). NOT a token's first trade — First_Trade / First_Price_Usd here are the first inside the window; for the very first trade of one token or a list of up to 50 use token_launch_stats (`addresses`). Covers rare / newly-launched tokens. Aggregates the token's individual swaps. Per row: Trade_Count, Buy_Trades, Sell_Trades, Volume_Usd, Buy_Volume_Usd, Sell_Volume_Usd, Distinct_Pools, Distinct_Traders, Unique_Buyers, Unique_Sellers, Quote_Symbols (up to 20), First_Price_Usd / Last_Price_Usd (first and last priced swap in the window), First_Trade / Last_Trade. A Buy is a swap in which the trader received this token. USD volume values each swap at the lower of its two priced sides, so a broken token price cannot inflate it; prices ignore dust swaps under $0.01. A swap is recorded under ONE of its two tokens. A token that is the pricing (quote) side of its pairs — a stablecoin, for example — is counted only in the pairs where it is the traded side, so its figures here are a lower bound, and a token that is always the quote side (USDT on Solana) returns no rows although it trades: an empty answer for such a token does not mean it has no market. `group_by` picks the granularity: - pool — one row per liquidity pool (default; "list the pools") - protocol — one row per DEX protocol family ("rank the DEXes") - program — one row per AMM program / launchpad address ("rank launchpads") - token — one row per token: its totals for the window WINDOW: `after_time` / `before_time` (UTC — "2026-09-15 08:00:00", a date, or unix seconds) select an absolute period [after_time, before_time). Without after_time the window is the `window_hours` before before_time (or before now); after_time takes precedence. Trade history reaches back about 30 days; an older start is moved up to it. BATCH: several addresses in `address` (up to 50, separated by `|`, `,` or spaces) — rows carry Token_Address and Network, grouped per token in the order given; `limit` applies per token (at most 1000 rows per call). Every row carries Addresses_Requested, Addresses_Invalid and Addresses_Used; the rule is in the `address` parameter; Addresses_Not_Found lists the addresses looked up that have no trade in the window (when nothing is found the result is empty, so no row carries the list). Pass `blockchain` whenever it is known: without it every chain the address trades on is reported separately. An empty `address` with a chain is its native coin as the traded side (on Solana wrapped SOL; Arc has none). Sort with `sort`: volume_usd (default) or trades. Use `find_tokens` / `find_token_by_address` first if you only have a name / symbol. Counts include swaps the indexer recorded twice (about 1% on Solana, near zero elsewhere); pool_recent_trades lists swaps with those copies removed. `Symbol_NonAscii` = 1 flags a `Token_Symbol` that is not plain ASCII. That is normal for CJK / emoji token names, but it is also how a scam token impersonates a major one: Cyrillic or Greek look-alike letters make a fake `USDT` / `SOL` / `BTC` read identically to a human. Never treat such a token as the asset it resembles — say the symbol is a look-alike. Symbols longer than 32 characters are cut and end in `…` (spam tokens carry symbols of up to 32,000 characters).ConnectorOAuth
- OpenFinance Pons v2 launch — launch a token on Robinhood Chain (EVM, chain id 4663) paired against ETH or any Pons-approved asset, INCLUDING Robinhood's own tokenized-stock mirrors (TSLA, AAPL, NVDA, GOOGL, AMZN, MSFT, META, COIN, PLTR, GME, SPY, and more). This is the "launch a token against a Robinhood stock" tool. ROUTING: • **For a NEW launch, use openfinance-launchpad-wrapper instead.** It launches on this same Pons curve and adds a fee module, so it is a superset; a plain launch is module='keep' there. This tool's launch_token is legacy, kept for compatibility — do not route a new launch to it. • This tool remains the right one for reading Pons state (list_quote_assets, get_launch_terms, list_tokens) and for fee actions on tokens launched through it before the wrapper existed (get_claimable_fees, sweep_fees, claim_fees, enable_holder_fee_sharing). • Always call action='list_quote_assets' first if the user hasn't stated an exact pair asset, or wants to see what's available — the approved list is live-checked and can change. • This is a DIFFERENT chain/protocol from the Solana launchpad tools (openfinance-raydium-launchpad, openfinance-raydium-cpmm) — Pons runs on Robinhood Chain, an EVM chain, and the user's Privy EVM wallet is used, not their Solana wallet. • There is no Pons API — everything here is a direct on-chain contract call (confirmed at docs.ponsfamily.com/v2). ACTIONS: launch_token — { name, symbol, image (base64), description?, twitter?, telegram?, website?, quoteAsset, creatorTaxBps?, developerBuyAmount?, snipeTaxExemptions? }: `twitter`/`telegram`/`website` are full URLs (e.g. "https://x.com/handle") — pass them exactly as given, do not construct or prefix a URL from a bare handle. `quoteAsset` — REQUIRED, a symbol (e.g. "TSLA", "ETH", "AAPL") or address from list_quote_assets. `creatorTaxBps` — optional creator trading tax in basis points (0-10000), capped by Pons's live limit. Default 0. `developerBuyAmount` — optional atomic dev buy in the quote asset's own human units (e.g. 0.05 for 0.05 ETH), executed in the SAME transaction as the launch via Pons's launchAndBuy helper. No platform fee — the launching user's own wallet is set as `creatorFeeRecipient` by default, so they keep 100% of Pons's creator-fee bucket. Set `creatorFeeRecipient` to redirect it to a specific wallet instead, OR set `shareFeesWithHolders: true` to redirect it to a Pons holder distributor (pro-rata to token holders) — these two are mutually exclusive; see enable_holder_fee_sharing below for the fuller explanation of the holders path. Returns { token, curve, pairToken, launchConfigId, graduationThreshold, txHash, tokensOut?, holderFeeSharing? }. **DESTRUCTIVE AND IRREVERSIBLE — launches a real token on mainnet with real ETH/asset committed for the launch fee (and dev buy if set).** Show the user: name, symbol, exact quoteAsset resolved, launch fee (from get_launch_terms), creatorTaxBps, and developerBuyAmount. Require explicit confirmation before calling. list_quote_assets — {} (PUBLIC — no auth): returns [{ address, symbol, name, decimals, isNative }] — every asset currently approved as a launch pair, including Robinhood's tokenized-stock mirrors. get_launch_terms — { quoteAsset }: live launch eligibility + fee terms for the caller against one quote asset. Call this before launch_token to show the user the current launch fee and confirm their wallet is eligible (`canLaunch`). Returns { launchFee, launchEnabled, canLaunch, maxCreatorTaxBps, snipeTaxStartBps, snipeTaxSeconds, activeConfig, graduationThreshold, expectedEconomics, protocolFeeShareBps, hookFeeBps, buybackBurnBps }. list_tokens — { limit?, offset?, creator? } (PUBLIC — no auth): paginated list of tokens launched under our platform. Returns { tokens: [{ token, curve, pairToken, name, symbol, logoUri, creatorAddress, twitter, telegram, website, marketCapUsd, marketCapDisplay, ... }], total, limit, offset }. `marketCapUsd` (raw number) + `marketCapDisplay` (compact, e.g. "143K"/"2.5M"/"1.2B") come from Codex via Uniblock — both `null` until Codex indexes the token, expected for very recent launches. `twitter`/`telegram`/`website` fall back to Codex's own indexed data when our own launch record doesn't have them (e.g. older launches) — our stored value always wins when present. enable_holder_fee_sharing — { token } (0x… address): redirects an already-launched token's creator fees to its Pons holder distributor — the retry path if launch_token's own `shareFeesWithHolders` attempt failed, or for opting in after the fact on a token launched without it. Idempotent. Irreversible via Pons's own public creator-controls once done — a durable economic choice, not a UI toggle, so it needs the same explicit-confirmation treatment as launch_token itself. get_claimable_fees — {} (uses the caller's connected wallet): READ-ONLY. Pons fees are never pushed to a wallet as they accrue (docs.ponsfamily.com/v2#claiming) — they build up on a launch's bonding curve and must be swept into a shared fee escrow before they're claimable. Call this FIRST, before sweep_fees or claim_fees, to see both: what's already claimable right now, and which of the caller's own launches still have fees sitting unswept on their curve. Returns { claimable: [{ quoteAssetSymbol, quoteAssetAddress, balance }], unswept: [{ token, quoteAssetSymbol, quoteAssetAddress, graduated, quoteFeeBalance, creatorTaxBalance }] }. `graduated: true` entries can't be swept yet (see sweep_fees). sweep_fees — { token } (0x… address): moves a launch's unswept curve fees into the shared fee escrow, where they become claimable via claim_fees. The caller's connected wallet must be that token's current on-chain creator-fee recipient. Only pre-graduation launches are supported — a graduated token's fees accrue on its pool instead and this action rejects it rather than risk an unverified call. Writes a real transaction (moves the launch's own accrued fees; no user funds are put at risk beyond gas) — mention the amounts from get_claimable_fees before calling, but this doesn't need launch_token-level ceremony since it can't misdirect funds, only move them from curve to escrow. Returns { txHash, quoteFeeSwept, creatorTaxSwept }. claim_fees — { quoteAsset? } (symbol like "ETH"/"TSLA" or address; defaults to native ETH): withdraws the caller's already-swept escrow balance for one quote asset to their own connected wallet. Call get_claimable_fees first to know which quote assets actually have a balance — this errors if the chosen asset's balance is zero. Returns { txHash, quoteAssetSymbol, claimed }. **⚠️ SAFETY** — launch_token is irreversible and commits real funds (the launch fee, plus any dev buy) on mainnet. Always call get_launch_terms first, show the resolved launch fee and quote asset, and get explicit confirmation.ConnectorOAuth
- The high-risk ('degen') leaderboard: newer, smaller, far more volatile tokens than `get_screener_leaderboard`. Tokens here can lose most of their value in minutes and many are short-lived. Say that plainly when you present them. Ranked best-first; page 1 is the top. Moby's leaderboards: Main = `get_screener_leaderboard` (composite 24h activity, 'what's moving'); Degen = `get_degen_leaderboard` (newer, smaller, higher risk); Majors = `get_group_leaderboard(group_id="home_majors")`; Stocks = `get_group_leaderboard(group_id="home_stocks")` (tokenized stocks); Pulse = `get_group_leaderboard(group_id="home_pulse")`. The Solana group ids `majors_solana` / `stocks_solana` work too, and the `home_*` ids are listed under `home_tabs` in `get_screener_groups`. The Majors and Stocks boards are THE reference for major and tokenized-stock contract addresses: take `token_address` from the row. Never resolve a major or a stock by ticker search alone, and never keep your own mint list. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. `whale_windows` (any of h1/h4/h8/h24) adds a per-row `whale` block per window: whale_count (distinct tracked wallets that bought OR sold — buyers plus sellers, not buyers alone), whale_buyers_count (distinct buyers only), whale_buys_count, whale_sells_count and whale_net_flow_usd. The row's `whale_count_h24` is the same buyers-plus-sellers count. Null figures mean unknown. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.ConnectorNo auth
- The ranked tokens inside one group/category. `group_id` must come from `get_screener_groups` — a group's `group_id`, or a `home_tabs` `tab_id` such as `home_majors` / `home_stocks` — do not invent or guess one. Ranked best-first; page 1 is the top. Moby's leaderboards: Main = `get_screener_leaderboard` (composite 24h activity, 'what's moving'); Degen = `get_degen_leaderboard` (newer, smaller, higher risk); Majors = `get_group_leaderboard(group_id="home_majors")`; Stocks = `get_group_leaderboard(group_id="home_stocks")` (tokenized stocks); Pulse = `get_group_leaderboard(group_id="home_pulse")`. The Solana group ids `majors_solana` / `stocks_solana` work too, and the `home_*` ids are listed under `home_tabs` in `get_screener_groups`. The Majors and Stocks boards are THE reference for major and tokenized-stock contract addresses: take `token_address` from the row. Never resolve a major or a stock by ticker search alone, and never keep your own mint list. Results are capped. Raise `limit` or step `page` only if the answer is genuinely not in the first page — a large result costs context that later steps of the same task need. `whale_windows` (any of h1/h4/h8/h24) adds a per-row `whale` block per window: whale_count (distinct tracked wallets that bought OR sold — buyers plus sellers, not buyers alone), whale_buyers_count (distinct buyers only), whale_buys_count, whale_sells_count and whale_net_flow_usd. The row's `whale_count_h24` is the same buyers-plus-sellers count. Null figures mean unknown. `asset_class: tokenized_stock` marks tokenized equities (treat as stock proxies, not memecoins). `safety_tier`: green = verified; grey = usually fine (not scored yet or a young launchpad token, NOT a red flag — do not skip a coin for being grey); red = caution / DYOR, the only tier to treat as a warning (Moby refuses agent buys on red). This is public market data about the whole market — it is NOT about the user's own wallet or holdings. Tools whose names start with `get_my_` are the ones that return the user's own data.ConnectorNo auth
- Launch a memecoin on the aeX402 launchpad on Robinhood Chain (EVM 4663) for a FIXED rising bonding curve (1B supply, starts 0.000008 USDG and climbs ~3.6x, graduates at 10,000 USDG raised, quoted in USDG; the pool then opens just above the last sale price). You supply only identity — name + ticker (+ optional description/image/links). DEFAULT (custodial): the aeX402 backend SIGNS + SUBMITS the createVPool tx for you, so a claude.ai user with NO WALLET can launch in one call; returns {ok,status,txHash,vpId}. Optionally pass `creator` (a 0x address) to record as the coin owner. Pass build:true instead to get an UNSIGNED tx {to,value,data} to submit yourself (non-custodial — that requires `creator` and makes you the on-chain creator). A custodial call SIMULATES first, so a failure burns no gas: status "gated" means createVPool reverts in simulation (cause not determined — likeliest are the ticker still being claimed by a bonding coin or this vpId being taken; see `detail`/`revertData`), and status "unreachable" means the chain could not be reached, which is retryable. The launchpad is NOT chain-gated: createVPool simulates clean from an arbitrary sender (measured 2026-09-25).ConnectorNo auth
- Creates a Zeekeo LinkedIn campaign: sends a connection invite using invite_template_id, and optionally — if followup_template_id is given — waits for the invite to be accepted, then sends a follow-up message using that template. Create templates first with zeekeo_create_template. Provide exactly one of filter_url (a LinkedIn search results URL) or profile_urls (specific profiles) as the target. This starts REAL LinkedIn automation once the campaign has profiles in it — confirm with the user before calling. Requires the user to have connected their own Zeekeo Launchpad account. Direct them to rankparse.com/dashboard/integrations to connect it.ConnectorNo auth
- Liquidity pool analysis for one token: which DEX holds the deepest pool, its depth in USD, and whether the LP tokens are burned, locked or still in someone's hands. lpStatus is the verdict — LP BURNED, LP LOCKED, LP UNLOCKED, PARTIALLY BURNED, LP NOT LOCKABLE, BONDING CURVE (still on a launchpad curve, no pool yet) or NO LP FOUND, with combinations spelled out — and lpBurnPct, lpLockPct and poolLocks carry the evidence. Use it to answer whether liquidity is locked, how deep it is, and whether the position could be pulled: LP UNLOCKED means it can be pulled at any time. Cached for about two minutes. A token with no pool returns empty liquidity data, which is itself a warning on a token that is trading. Not for price or volume (get_token_price), market cap (get_token_scan) or holder concentration (get_holders). Arguments: address and chain — pools live per chain, so a 0x address needs the chain it trades on, and a Base pool is not found under ethereum; one API unit on any chain.ConnectorNo auth
- What the token's creator has done with their supply: the share they still hold, what left through sales versus transfers, and where the transfers went. Read the state carefully: still holding is neutral, a dev who simply sold out is statusColor gray — the standard launch pattern, not a rug — fully exited on a fresh token is a warning, and transferred out to fresh wallets (red) is the single strongest rug signal DeFade tracks. The creator is the wallet that created the mint on Solana and the contract deployer on EVM chains; creatorSource says how it was identified, and creatorInferred true means it may be a launchpad authority rather than a person, so weigh the verdict accordingly. Not for wallets other than the creator (get_whales, get_wallet_links); the creator's earlier launches are already served by get_token_scan's creator block (tokenCreations, recentTokens). Arguments: address and chain — the deployer is read from the contract creation on that chain, so a 0x address needs its chain; one API unit on any chain.ConnectorNo auth
- Lists the pools of one token a ladder can be built in, in the order the site offers them: real markets that pay their liquidity first, then markets whose launchpad hook keeps the whole fee, then small ones. Use before plan_ladder, plan_limit_order or plan_build to choose a pool, or with quote to learn whether a pair exists. Returns: token, pools[] with pool (id), version, pair, quote, swapFeePct, hook, tickSpacing, stepPct, paysLiquidity, usdToMovePrice2Pct, volume24hUsd, fees24hUsd, weeklyFeesOnLiquidityPct, untraded, note; pairsThatExist; with quote, forQuote (its pools, and a verdict: build in it, or plan_build opens one). The first pool is the default. Behavior: read-only; the same token is read at most every 15 seconds; costs 1 unit. Errors: refused when the address is not a token the index knows.ConnectorNo auth
- WHO CREATED an Arbitrum (arb, ARB, Arbitrum One, L2) contract, and what a creator deployed. Answers "who created / deployed this token", "who is behind this contract", "what else did this deployer launch", and "were these tokens made by the same person" (serial deployers, rug and clone farms). NOT who funded a wallet → use arbitrum_first_funder. On this chain a token IS a contract, so pass the TOKEN'S CONTRACT ADDRESS in contracts. TWO WAYS TO CALL IT, pick one - setting both is refused, because the two answer different questions and their shared-creator counters would be mixed: contracts="0x..|0x.." - up to 50 contracts, one row each: Creator (the address whose code ran CREATE), Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used and Deploy_Success. Rows whose creator or signer is SHARED come first: Creator_Shared / Signer_Shared count how many of the requested contracts have that same creator / signer, which is what exposes one person behind many tokens. A longer list is not an error: the first 50 distinct addresses are used and the rest ignored - compare Contracts_Requested with Contracts_Used and split a longer list into several calls. creator="0x.." - the contracts THAT address deployed, newest first, inside the window (days, after_time, before_time), at most `limit` rows. Use it on the Creator or Signer a first call returned, to see the rest of that deployer's output. Creator_Shared is empty in this form - every row has the same creator by construction, so the counter would only repeat the row count. Creator_Is_Contract = 1 means the contract was deployed BY OTHER CONTRACT CODE - a token factory, a launchpad or a DEX pair factory - and then Creator is that factory, which is the SAME address for every token it ever made, while Signer is the person who asked for it. On a factory-made token read Signer, not Creator. Deploy_Depth is how deep inside the transaction the deployment happened (0 = the transaction itself) and Call_Index is the deployment's position in that transaction - one transaction can deploy several contracts, and Call_Index is what tells those rows apart when everything else about them looks the same. Status = NOT_FOUND means no deployment is recorded for that address: it is a plain wallet, not a contract, or the deployment is older than the recorded history of this chain. Creations is normally 1; a higher number means the address was created more than once (destroyed and redeployed), and the row describes the EARLIEST creation. THE CREATOR'S STORY IS NOT IN THIS TOOL - build it from the returned addresses: labels_for_addresses (is the creator a known entity, exchange or scammer), arbitrum_first_funder (who funded the creator, and whether several creators share one sponsor), arbitrum_address_profile and arbitrum_transfers_in / arbitrum_transfers_out (what that wallet does), arbitrum_flows_between (what moved between the creator and the token). The token's own name, symbol, price and market cap come from find_token_by_address; its first buyers from early_buyers. Amounts are the native coin, never USD. COST: a contract lookup has to walk every call that address ever received, so a handful of ordinary tokens answer in a second or two while one exchange-scale contract can take ~20 s on its own. If you already know roughly when the contract appeared, bound it with after_time / before_time - that alone took one busy token from 21 s to 2 s. A row-limit error ("Limit for rows ... exceeded") means the batch is too busy: bound it that way, or split the list.ConnectorOAuth
- WHO CREATED an Arc (arc, ARC, Arc Network, Circle Arc) contract, and what a creator deployed. Answers "who created / deployed this token", "who is behind this contract", "what else did this deployer launch", and "were these tokens made by the same person" (serial deployers, rug and clone farms). NOT who funded a wallet → use arc_first_funder. On this chain a token IS a contract, so pass the TOKEN'S CONTRACT ADDRESS in contracts. TWO WAYS TO CALL IT, pick one - setting both is refused, because the two answer different questions and their shared-creator counters would be mixed: contracts="0x..|0x.." - up to 50 contracts, one row each: Creator (the address whose code ran CREATE), Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used and Deploy_Success. Rows whose creator or signer is SHARED come first: Creator_Shared / Signer_Shared count how many of the requested contracts have that same creator / signer, which is what exposes one person behind many tokens. A longer list is not an error: the first 50 distinct addresses are used and the rest ignored - compare Contracts_Requested with Contracts_Used and split a longer list into several calls. creator="0x.." - the contracts THAT address deployed, newest first, inside the window (days, after_time, before_time), at most `limit` rows. Use it on the Creator or Signer a first call returned, to see the rest of that deployer's output. Creator_Shared is empty in this form - every row has the same creator by construction, so the counter would only repeat the row count. Creator_Is_Contract = 1 means the contract was deployed BY OTHER CONTRACT CODE - a token factory, a launchpad or a DEX pair factory - and then Creator is that factory, which is the SAME address for every token it ever made, while Signer is the person who asked for it. On a factory-made token read Signer, not Creator. Deploy_Depth is how deep inside the transaction the deployment happened (0 = the transaction itself) and Call_Index is the deployment's position in that transaction - one transaction can deploy several contracts, and Call_Index is what tells those rows apart when everything else about them looks the same. LIMIT ON THIS CHAIN, READ IT BEFORE USING THE contracts FORM: the deployment records here do not carry the address a deployment produced, so looking a CONTRACT up cannot succeed - every contract answers Status = NOT_RECORDED, including tokens that certainly exist. That is a gap in the data, NOT evidence that the address is a plain wallet, and it must never be reported as "no creator found". The creator form still works: pass creator="0x.." to list the deployments that address made - times, transactions, signer and gas are real there, while the Contract column reads 0x0000000000000000000000000000000000000000 for the same reason and must not be taken for the address that was deployed. Identify a deployer from find_token_by_address, the token's early transfers and its first funder instead. Creations is normally 1; a higher number means the address was created more than once (destroyed and redeployed), and the row describes the EARLIEST creation. THE CREATOR'S STORY IS NOT IN THIS TOOL - build it from the returned addresses: labels_for_addresses (is the creator a known entity, exchange or scammer), arc_first_funder (who funded the creator, and whether several creators share one sponsor), arc_address_profile and arc_transfers_in / arc_transfers_out (what that wallet does), arc_flows_between (what moved between the creator and the token). The token's own name, symbol, price and market cap come from find_token_by_address; its first buyers from early_buyers. Amounts are the native coin (native USDC, 18 decimals - the same asset as the 6-decimal ERC-20 USDC, through the other interface), never USD. COST: a contract lookup has to walk every call that address ever received, so a handful of ordinary tokens answer in a second or two while one exchange-scale contract can take ~20 s on its own. If you already know roughly when the contract appeared, bound it with after_time / before_time - that alone took one busy token from 21 s to 2 s. A row-limit error ("Limit for rows ... exceeded") means the batch is too busy: bound it that way, or split the list.ConnectorOAuth
- WHO CREATED a Base (base, L2, Coinbase L2) contract, and what a creator deployed. Answers "who created / deployed this token", "who is behind this contract", "what else did this deployer launch", and "were these tokens made by the same person" (serial deployers, rug and clone farms). NOT who funded a wallet → use base_first_funder. On this chain a token IS a contract, so pass the TOKEN'S CONTRACT ADDRESS in contracts. TWO WAYS TO CALL IT, pick one - setting both is refused, because the two answer different questions and their shared-creator counters would be mixed: contracts="0x..|0x.." - up to 50 contracts, one row each: Creator (the address whose code ran CREATE), Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used and Deploy_Success. Rows whose creator or signer is SHARED come first: Creator_Shared / Signer_Shared count how many of the requested contracts have that same creator / signer, which is what exposes one person behind many tokens. A longer list is not an error: the first 50 distinct addresses are used and the rest ignored - compare Contracts_Requested with Contracts_Used and split a longer list into several calls. creator="0x.." - the contracts THAT address deployed, newest first, inside the window (days, after_time, before_time), at most `limit` rows. Use it on the Creator or Signer a first call returned, to see the rest of that deployer's output. Creator_Shared is empty in this form - every row has the same creator by construction, so the counter would only repeat the row count. Creator_Is_Contract = 1 means the contract was deployed BY OTHER CONTRACT CODE - a token factory, a launchpad or a DEX pair factory - and then Creator is that factory, which is the SAME address for every token it ever made, while Signer is the person who asked for it. On a factory-made token read Signer, not Creator. Deploy_Depth is how deep inside the transaction the deployment happened (0 = the transaction itself) and Call_Index is the deployment's position in that transaction - one transaction can deploy several contracts, and Call_Index is what tells those rows apart when everything else about them looks the same. Status = NOT_FOUND means no deployment is recorded for that address: it is a plain wallet, not a contract, or the deployment is older than the recorded history of this chain. Creations is normally 1; a higher number means the address was created more than once (destroyed and redeployed), and the row describes the EARLIEST creation. THE CREATOR'S STORY IS NOT IN THIS TOOL - build it from the returned addresses: labels_for_addresses (is the creator a known entity, exchange or scammer), base_first_funder (who funded the creator, and whether several creators share one sponsor), base_address_profile and base_transfers_in / base_transfers_out (what that wallet does), base_flows_between (what moved between the creator and the token). The token's own name, symbol, price and market cap come from find_token_by_address; its first buyers from early_buyers. Amounts are the native coin, never USD. COST: a contract lookup has to walk every call that address ever received, so a handful of ordinary tokens answer in a second or two while one exchange-scale contract can take ~20 s on its own. If you already know roughly when the contract appeared, bound it with after_time / before_time - that alone took one busy token from 21 s to 2 s. A row-limit error ("Limit for rows ... exceeded") means the batch is too busy: bound it that way, or split the list.ConnectorOAuth
- WHO CREATED a BSC (bsc, BNB, BNB Chain, Binance Smart Chain) contract, and what a creator deployed. Answers "who created / deployed this token", "who is behind this contract", "what else did this deployer launch", and "were these tokens made by the same person" (serial deployers, rug and clone farms). NOT who funded a wallet → use bsc_first_funder. On this chain a token IS a contract, so pass the TOKEN'S CONTRACT ADDRESS in contracts. TWO WAYS TO CALL IT, pick one - setting both is refused, because the two answer different questions and their shared-creator counters would be mixed: contracts="0x..|0x.." - up to 50 contracts, one row each: Creator (the address whose code ran CREATE), Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used and Deploy_Success. Rows whose creator or signer is SHARED come first: Creator_Shared / Signer_Shared count how many of the requested contracts have that same creator / signer, which is what exposes one person behind many tokens. A longer list is not an error: the first 50 distinct addresses are used and the rest ignored - compare Contracts_Requested with Contracts_Used and split a longer list into several calls. creator="0x.." - the contracts THAT address deployed, newest first, inside the window (days, after_time, before_time), at most `limit` rows. Use it on the Creator or Signer a first call returned, to see the rest of that deployer's output. Creator_Shared is empty in this form - every row has the same creator by construction, so the counter would only repeat the row count. Creator_Is_Contract = 1 means the contract was deployed BY OTHER CONTRACT CODE - a token factory, a launchpad or a DEX pair factory - and then Creator is that factory, which is the SAME address for every token it ever made, while Signer is the person who asked for it. On a factory-made token read Signer, not Creator. Deploy_Depth is how deep inside the transaction the deployment happened (0 = the transaction itself) and Call_Index is the deployment's position in that transaction - one transaction can deploy several contracts, and Call_Index is what tells those rows apart when everything else about them looks the same. Status = NOT_FOUND means no deployment is recorded for that address: it is a plain wallet, not a contract, or the deployment is older than the recorded history of this chain. Creations is normally 1; a higher number means the address was created more than once (destroyed and redeployed), and the row describes the EARLIEST creation. THE CREATOR'S STORY IS NOT IN THIS TOOL - build it from the returned addresses: labels_for_addresses (is the creator a known entity, exchange or scammer), bsc_first_funder (who funded the creator, and whether several creators share one sponsor), bsc_address_profile and bsc_transfers_in / bsc_transfers_out (what that wallet does), bsc_flows_between (what moved between the creator and the token). The token's own name, symbol, price and market cap come from find_token_by_address; its first buyers from early_buyers. Amounts are the native coin, never USD. COST: a contract lookup has to walk every call that address ever received, so a handful of ordinary tokens answer in a second or two while one exchange-scale contract can take ~20 s on its own. If you already know roughly when the contract appeared, bound it with after_time / before_time - that alone took one busy token from 21 s to 2 s. A row-limit error ("Limit for rows ... exceeded") means the batch is too busy: bound it that way, or split the list.ConnectorOAuth
- WHO CREATED an Ethereum (eth, ETH, mainnet, L1) contract, and what a creator deployed. Answers "who created / deployed this token", "who is behind this contract", "what else did this deployer launch", and "were these tokens made by the same person" (serial deployers, rug and clone farms). NOT who funded a wallet → use eth_first_funder. On this chain a token IS a contract, so pass the TOKEN'S CONTRACT ADDRESS in contracts. TWO WAYS TO CALL IT, pick one - setting both is refused, because the two answer different questions and their shared-creator counters would be mixed: contracts="0x..|0x.." - up to 50 contracts, one row each: Creator (the address whose code ran CREATE), Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used and Deploy_Success. Rows whose creator or signer is SHARED come first: Creator_Shared / Signer_Shared count how many of the requested contracts have that same creator / signer, which is what exposes one person behind many tokens. A longer list is not an error: the first 50 distinct addresses are used and the rest ignored - compare Contracts_Requested with Contracts_Used and split a longer list into several calls. creator="0x.." - the contracts THAT address deployed, newest first, inside the window (days, after_time, before_time), at most `limit` rows. Use it on the Creator or Signer a first call returned, to see the rest of that deployer's output. Creator_Shared is empty in this form - every row has the same creator by construction, so the counter would only repeat the row count. Creator_Is_Contract = 1 means the contract was deployed BY OTHER CONTRACT CODE - a token factory, a launchpad or a DEX pair factory - and then Creator is that factory, which is the SAME address for every token it ever made, while Signer is the person who asked for it. On a factory-made token read Signer, not Creator. Deploy_Depth is how deep inside the transaction the deployment happened (0 = the transaction itself) and Call_Index is the deployment's position in that transaction - one transaction can deploy several contracts, and Call_Index is what tells those rows apart when everything else about them looks the same. Status = NOT_FOUND means no deployment is recorded for that address: it is a plain wallet, not a contract, or the deployment is older than the recorded history of this chain. Creations is normally 1; a higher number means the address was created more than once (destroyed and redeployed), and the row describes the EARLIEST creation. THE CREATOR'S STORY IS NOT IN THIS TOOL - build it from the returned addresses: labels_for_addresses (is the creator a known entity, exchange or scammer), eth_first_funder (who funded the creator, and whether several creators share one sponsor), eth_address_profile and eth_transfers_in / eth_transfers_out (what that wallet does), eth_flows_between (what moved between the creator and the token). The token's own name, symbol, price and market cap come from find_token_by_address; its first buyers from early_buyers. Amounts are the native coin, never USD. COST: a contract lookup has to walk every call that address ever received, so a handful of ordinary tokens answer in a second or two while one exchange-scale contract can take ~20 s on its own. If you already know roughly when the contract appeared, bound it with after_time / before_time - that alone took one busy token from 21 s to 2 s. A row-limit error ("Limit for rows ... exceeded") means the batch is too busy: bound it that way, or split the list.ConnectorOAuth
- WHO CREATED a Polygon (matic, POL, MATIC, PoS) contract, and what a creator deployed. Answers "who created / deployed this token", "who is behind this contract", "what else did this deployer launch", and "were these tokens made by the same person" (serial deployers, rug and clone farms). NOT who funded a wallet → use matic_first_funder. On this chain a token IS a contract, so pass the TOKEN'S CONTRACT ADDRESS in contracts. TWO WAYS TO CALL IT, pick one - setting both is refused, because the two answer different questions and their shared-creator counters would be mixed: contracts="0x..|0x.." - up to 50 contracts, one row each: Creator (the address whose code ran CREATE), Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used and Deploy_Success. Rows whose creator or signer is SHARED come first: Creator_Shared / Signer_Shared count how many of the requested contracts have that same creator / signer, which is what exposes one person behind many tokens. A longer list is not an error: the first 50 distinct addresses are used and the rest ignored - compare Contracts_Requested with Contracts_Used and split a longer list into several calls. creator="0x.." - the contracts THAT address deployed, newest first, inside the window (days, after_time, before_time), at most `limit` rows. Use it on the Creator or Signer a first call returned, to see the rest of that deployer's output. Creator_Shared is empty in this form - every row has the same creator by construction, so the counter would only repeat the row count. Creator_Is_Contract = 1 means the contract was deployed BY OTHER CONTRACT CODE - a token factory, a launchpad or a DEX pair factory - and then Creator is that factory, which is the SAME address for every token it ever made, while Signer is the person who asked for it. On a factory-made token read Signer, not Creator. Deploy_Depth is how deep inside the transaction the deployment happened (0 = the transaction itself) and Call_Index is the deployment's position in that transaction - one transaction can deploy several contracts, and Call_Index is what tells those rows apart when everything else about them looks the same. Status = NOT_FOUND means no deployment is recorded for that address: it is a plain wallet, not a contract, or the deployment is older than the recorded history of this chain. Creations is normally 1; a higher number means the address was created more than once (destroyed and redeployed), and the row describes the EARLIEST creation. THE CREATOR'S STORY IS NOT IN THIS TOOL - build it from the returned addresses: labels_for_addresses (is the creator a known entity, exchange or scammer), matic_first_funder (who funded the creator, and whether several creators share one sponsor), matic_address_profile and matic_transfers_in / matic_transfers_out (what that wallet does), matic_flows_between (what moved between the creator and the token). The token's own name, symbol, price and market cap come from find_token_by_address; its first buyers from early_buyers. Amounts are the native coin, never USD. COST: a contract lookup has to walk every call that address ever received, so a handful of ordinary tokens answer in a second or two while one exchange-scale contract can take ~20 s on its own. If you already know roughly when the contract appeared, bound it with after_time / before_time - that alone took one busy token from 21 s to 2 s. A row-limit error ("Limit for rows ... exceeded") means the batch is too busy: bound it that way, or split the list.ConnectorOAuth