Fusor Protocol Documentation

The Pairing Model

A conventional launchpad opens one pool against a stablecoin. Fusor opens up to five, each against a different tokenized stock, and lets the creator decide how the supply is divided among them. That single change is where most of the protocol's behaviour comes from, so it is worth being precise about what it does and does not mean.

Allocations are liquidity placement, not backing

When you allocate 60% to one market and 40% to another, you are saying where the project tokens go as single-sided liquidity. You are not creating a basket, a claim, or a redemption right. Nobody can hand back a project token and receive a proportional slice of the stocks. Each pool is an ordinary Uniswap V4 market that happens to be denominated in that stock token, and each one finds its own price.

Weights must total exactly 100%

Allocations are integer basis points and their sum has to equal 10000 exactly. There is no rounding tolerance in the contract — 9,999 reverts. If you are splitting evenly across a count that does not divide cleanly, put the remainder somewhere explicit: three markets are 3334 / 3333 / 3333, never three times 3333.

Which assets can be a quote market

The authority is StockTokenRegistry, and the only question that matters at launch time is what getConfig(token) returns for it. If enabled is false, or the configured price feed is the zero address, the launch reverts — regardless of what any interface displayed.

This site shows a filtered view of the registry rather than all of it, and the difference trips up integrators, so here is the exact layering:

ETH is handled separately

ETH is not a registry entry. It is represented by the zero-address sentinel and priced through the launchpad's own ethPriceFeed(), because every launch needs an ETH price whether or not ETH is one of the chosen markets — the launch fee and the milestone target are both denominated through it.

Currently registered assets

Read live from the registry as you load this page, filtered to what this site offers:

• Symbols are stored on-chain as bytes32, right-padded with zero bytes.
• Decimals come from the registry entry, not from the token contract — the launchpad rejects an entry that reports zero.
• Each entry carries its own price-feed address, and those are swappable by the registry admin without touching the launchpad.

Token Lifecycle

A Fusor token has a much shorter life story than most launchpad tokens, because the phases that usually exist — bonding curve, migration, unlock — are simply absent. There are two states, and the transition between them changes a flag and nothing else.

Phase 1 — creation

One transaction deploys the ERC-20, opens a pool per chosen market, places the allocated supply as single-sided liquidity, hands every position to the locker, and emits MultiPairLaunchCreated. Either all of it happens or none of it does; there is no partial launch to clean up. From the block it lands in, the token is tradeable by anyone.

Phase 2 — open market, indefinitely

Everything after creation is ordinary Uniswap V4 trading in those same pools. Price is whatever the pool state says. Fees accumulate inside each locked position and are periodically collected and split. The creator can claim their share whenever a non-zero balance exists.

The milestone is an event, not a phase

When locked principal reaches the target recorded at launch, anyone may call syncGraduation and the token is flagged as graduated. This is the part most people expect to work differently, so, explicitly:

What never happens

• No migration. There is no second pool that supersedes the first, so no address in your integration goes stale.
• No unlock. The locker has no withdrawal path for launch positions — for the creator, for the protocol, or for anyone else.
• No supply change. No mint, no burn hook, no rebase.
• No trading halt. Nothing in the protocol can pause a launched token's market.

Creating a Token

One call does everything: launchTokenMulti on the launchpad proxy. It takes a single struct and requires the launch fee as msg.value. Everything the token needs to exist and trade is established before the transaction returns.

What the transaction performs

• Deploys a FusorTokenV5 ERC-20 with a fixed supply of 1,000,000,000 units.
• Creates one Uniswap V4 pool per chosen quote market, each with the Fusor hook attached.
• Places the supply across those pools as single-sided concentrated liquidity, in the weights you gave.
• Transfers every resulting position to FusorV4Locker, permanently.
• Records the launch and its milestone target on-chain, and emits MultiPairLaunchCreated.

The parameter struct

Eleven fields, in this order. The overload matters: the contract declares two functions named launchTokenMulti, and only the 11-field one (0x07489e0a) is callable on this deployment. Encoding against the other one produces calldata that reverts for reasons that look unrelated to the mistake.

Developer buy — off in this release

The struct carries the parameters and the adapter is deployed, but this release does not enable the feature. Skip it by setting developerBuyPairIndex to 255, both amounts to 0, and developerBuyRecipient to the creator's address. When it is enabled, it will be a real market purchase at launch price with an exact-output amount and a spend ceiling — not a free allocation.

The launch fee is read, not assumed

msg.value must equal launchFeeWei() exactly; anything else reverts with IncorrectLaunchFee. That getter is a deployment parameter, not a protocol constant, so read it in the same session you launch in. The fee is separate from gas, and separate from any quote tokens a developer buy would spend.

Preconditions worth checking first

All of these are enforced on-chain and will revert the launch. Checking them beforehand costs a few read calls and turns an opaque revert into a sentence:

Reading the result correctly

The function returns the new token's address, and a simulation will give you that value before you send anything. But the returned value is the address the token would get at the launchpad's current nonce — if another launch confirms first, the real address differs.

Launch Protection

Fusor tokens carry no transfer tax and no blacklist. Instead, FusorTokenV5 enforces three limits for a brief window — the launch block plus the next five — and then stops enforcing anything, on its own, with no transaction required to lift them.

What is deliberately not restricted

• Selling. There is no limit on disposals at any point, inside the window or outside it.
• Ordinary transfers. The caps apply to acquisition, not to moving tokens you already hold.
• Anything after the window. Block six onwards behaves like any ERC-20.

What this does and does not achieve

The caps make it expensive for one address to take an outsized share of the opening supply, which is the specific failure they target. They do not prevent an actor with many funded addresses from doing the same thing across them, and nothing in the protocol claims otherwise. Treat the window as friction against the naive version of the attack, not as a distribution guarantee.

Separate from the pool fee

The 1% swap fee applies to every trade in a Fusor pool, inside the protection window and forever after. It is a property of the pool, not of the window, and the two are unrelated.

Liquidity & Pricing

There is no bonding curve at any point. The launch does not sell into a formula and then move funds somewhere else when a threshold is crossed — it opens real Uniswap V4 pools immediately and leaves them there. Everything about price after that is ordinary AMM behaviour against locked liquidity.

How the liquidity is placed

• Each chosen market gets its own pool, funded with that market's share of the supply.
• The position is single-sided: only project tokens go in. The quote side fills up as people buy.
• The starting price comes from the oracle at launch time, so the first trade is not arbitrary.
• The range runs from that starting point out to Uniswap's extreme usable tick, so there is no upper bound the price can hit.
• Every position is handed to FusorV4Locker in the same transaction and stays there.

Tick direction depends on token ordering

Uniswap orders a pool's two tokens by address, and that ordering decides which way the range extends. It has no economic meaning, but it changes how you read the numbers:

Why locked liquidity behaves differently

In a pool where liquidity can leave, a falling price and withdrawing providers reinforce each other. Here the launch liquidity cannot be withdrawn by anyone, so depth does not evaporate under selling pressure. This is a real structural difference, and it is worth being equally clear about what it does not do: it does not put a floor under the price, and it does not stop the price from falling as far as the pool allows.

Composing a market cap from several pools

A token paired with three stocks has three prices at once. Turning that into one displayed number takes three steps:

• Read each pool's current sqrtPrice to get the project token's price in that stock token.
• Convert each to USD using that stock's oracle price.
• Combine the USD prices using the token's configured weights, then multiply by the fixed 1,000,000,000 supply.

Legacy single-market tokens

Tokens created before multi-market launches existed have one market and route through V3. They are represented as a single 100% V3_LEGACY allocation, remain viewable and tradeable, and are not migrated into the V4 model. Nothing on this page about multi-pool routing applies to them.

Trading & Routing

Every trade ends up in one or more of the token's launch pools. What differs is how a trade gets there. There are exactly two paths, they use different contracts, and they require different approvals.

Path A — one named market

You choose a market by ticker and trade only that pool, spending or receiving that stock token directly. Execution goes through Permit2 and the Universal Router in a single transaction. This is the simpler path and the right default when you already hold the quote asset, or when you specifically want exposure through one market.

Path B — balanced across markets

FusorV5MultiPoolAggregator takes one exact-input trade and spreads it over up to five of the token's pools, presenting USDG as the single asset you spend or receive. It converts USDG to each pool's stock token as needed, executes the legs, and settles back — all atomically. It is permissionless: it creates nothing, custodies nothing between transactions, and does not replace the pools it trades against.

How it decides:

• Enumerates the canonical pools registered for the token.
• Quotes both legs for each candidate: the USDG ↔ stock conversion and the stock ↔ project-token swap.
• Discards markets it cannot support, and any route whose live price impact exceeds 15%.
• Compares the best single pool against discrete multi-pool splits.
• Takes a split only when the improvement is worth the extra gas it costs.
• Applies a minimum per leg and a minimum on the total, then re-quotes and simulates immediately before signing.

Guarantees the aggregator enforces

• At most five distinct pool legs per trade.
• Every supplied pool key is rebuilt and checked against the launchpad's registered pool — you cannot point it at a pool of your own.
• Unsupported conversion assets, zero recipients, expired deadlines, and deadlines more than a day out are all rejected.
• The aggregate minimum is checked against the recipient's actual balance change, not against an internal accounting number.
• Its own token balances are restored to their opening values, so a trade cannot leave funds sitting in it.

Choosing between them

Approvals differ by path

Existing allowances are checked before anything is requested, so an approval prompt appearing means one is genuinely missing.

There is no quote API

Fusor is not the only venue

These pools are public Uniswap V4 markets. Any interface can trade them, and an external router may add its own fee or route through unrelated pools with different fee tiers. A fee charged by someone else's router is not part of the Fusor fee schedule and does not reach the creator or the treasury. Inspect the whole route before signing.

Price Oracles

A launch needs a price for ETH and for every stock token it pairs against — that is what sets the opening pool price and what the milestone target is denominated through. Prices come from the feed address recorded on each registry entry, and those feeds fall into two classes that behave differently enough that mixing them up will waste your afternoon.

Two classes of feed

Both answer the same no-argument latestRoundData() call and both report 8 decimals, which is the point of the wrapper — the launchpad cannot tell them apart and does not need to. You can, by looking at the deployed code size: a Fusor feed is a few hundred bytes, a Chainlink aggregator is thousands.

Staleness is enforced twice, at very different limits

This is the single most useful thing to know about Fusor pricing, and it is not obvious from either contract on its own:

Because the inner check reverts before the outer one can run, the tighter limit always wins. The practical result:

• Chainlink-backed assets are governed by maxOracleAge(), which on this deployment is generous enough that a price well over a day old is still accepted.
• Self-priced assets are effectively governed by a 2-hour window. If the keeper has not pushed within that window, the feed reverts and no launch against that asset can proceed — regardless of what maxOracleAge() says.

FusorPriceOracle

An owner-controlled registry storing one price per asset at 8 decimals, Chainlink's convention — $200.00 is 20000000000. Two reads:

• latestRoundData(address asset) — enforces the 2-hour guard and reverts past it. This is the safety-critical path; the per-asset feeds proxy to it.
• priceOf(address asset) — the raw stored value with no staleness check. Suitable for display, never for deciding whether an action will succeed.

FusorOracleFeed

One instance per self-priced asset. It holds the oracle address and the asset address as immutables and does nothing but forward. Two consequences worth knowing:

• A feed's asset binding is immutable. Pointing an asset at a different feed means deploying a new feed and updating the registry entry — the registry admin can do that without touching the launchpad.
• Because it is a pure pass-through, its staleness behaviour is the oracle's, not its own.

The keeper

An off-chain service fetches quotes and batches them into updatePriceBatch(). Its sourcing is deliberately conservative, because a wrong price written on-chain sets the opening price of a new pool and cannot be taken back:

Three behaviours follow from that, and all three are visible from outside:

• Only self-priced assets get pushed. Chainlink-backed ones are skipped on purpose — pushing to them would achieve nothing and would consume quota.
• A price is cross-checked before it is written. Each quote is compared against an independent on-chain reference read by token address, so a symbol mix-up cannot slip through. If the two disagree by more than the configured tolerance, the keeper refuses to push rather than picking one. Disagreement means at least one of them is wrong, and an unrefreshed price merely blocks launches — a wrong one mis-prices a pool permanently.
• No value is ever invented. An asset with no usable quote is skipped and keeps whatever it had. It never receives a zero, a guess, or a stale-but-plausible substitute.

Checking freshness the way the contract does

The mistake worth avoiding: reading FusorPriceOracle directly for every asset and comparing against one hard-coded limit. That is not the code path the launchpad takes. To match it, resolve each asset's own feed — launchpad.ethPriceFeed() for ETH, and registry.getConfig(token).priceFeed for each stock token — call latestRoundData() on that feed, and compare against the live maxOracleAge(). Anything else can pass your check and then revert on-chain, which is the hardest class of bug to diagnose because both sides look correct in isolation.

Fees & Revenue

Two fees exist, and they behave nothing alike. One is a flat charge paid once by the creator. The other is a percentage of every trade that accrues inside locked liquidity and is later split between the creator and the protocol.

Swap fees do not go straight to anyone

The 1% accrues inside each locked Uniswap V4 position. Getting it into a claimable balance takes three distinct steps, and it is worth knowing which of them you need to do yourself:

The split

• 70% to the creator's fee recipient — the address given as creatorFeeRecipient at launch.
• 30% to the protocol treasury.

The split is applied separately to each asset. A trade against the AAPL market accrues both project tokens and AAPL, so both get split, and both end up as separate claimable balances.

Project-token fees stay project tokens

Fees collected in the project token are not swapped into anything on your behalf. You claim them as the project token and decide what to do with them. This is deliberate: an automatic swap would sell into the token's own pool, which is both a price impact you did not ask for and a decision the protocol has no business making for you.

Claiming

• Claims are per asset, so a multi-market token produces several independent balances.
• There is no minimum. A small position keeps accruing and becomes claimable as soon as collection credits anything non-zero.
• Nothing expires and nothing is swept away. An unclaimed balance simply stays unclaimed.

Fees charged elsewhere are not these fees

Fusor pools are public. An external router or aggregator can add a fee of its own and can route through unrelated Uniswap pools with their own fee tiers. None of that reaches the Fusor creator or treasury, and none of it appears in the table above. When comparing costs across interfaces, compare the whole route.

Graduation Milestone

The on-chain function is called syncGraduation, and the word invites a wrong assumption worth clearing up immediately: on most launchpads “graduation” means liquidity migrates from an internal curve to a public market. Here there is no internal curve and no migration. Graduation sets a boolean and changes nothing else about how the token works.

The target

At launch the contract records a USD target derived from a fixed 4.2 ETH, converted at the ETH/USD price in that block and stored with 8 decimals. It is fixed per token at creation — a later move in ETH does not re-price an existing token's target, and two tokens launched at different times will have different USD targets.

Progress

Progress compares the principal held in the token's canonical locked positions against that recorded target:

progress = locked principal ÷ recorded target

Principal only. Accrued fees, liquidity anyone added outside the launch positions, and cumulative trading volume are all excluded — none of them count toward the milestone.

Anyone can trigger it

syncGraduation(address projectToken) has no access control. Once a token qualifies, any account may submit the transaction and pay its gas. Our keeper attempts it for qualifying tokens as a convenience, but the contract does not call itself and nothing about the milestone depends on us being online.

What an interface can honestly display

Progress is computed from observations that can be stale, so there is a real difference between “qualifies” and “is flagged”. Four states, and conflating the middle two is the usual mistake:

What it is not

• Not a price ceiling. The price can be anywhere above or below the target, before or after.
• Not a maximum market cap. The target is denominated in locked principal, which is a different quantity entirely.
• Not a liquidity event. Nothing unlocks, nothing is released, nothing is distributed.
• Not a quality signal. It measures deposited principal, which anyone can supply for any reason.

SDK Quickstart

Two SDKs are supported — TypeScript and Python — built from one shared spec so they encode identical calldata and produce identical metadata hashes. Pick whichever matches your stack; everything on this page applies to both.

npm install @fusor/sdk   # Node 22+
pip install fusor        # Python 3.11+

Before you start

• A funded key. Enough ETH for the launch fee plus gas. The fee is read from the chain at call time, not a constant you can hard-code.
• A metadata URI, or an API base URL so the SDK can upload one for you.
• Nothing else. No API key, no registration, no allowlist, and no launchpad address — the SDK carries the deployment record.

Launch a token

This is the whole thing. One call signs and sends one transaction, waits for the receipt, and returns the token address read out of the event — so when it returns, the token exists on chain.

import { FusorClient } from '@fusor/sdk';

// No launchpad address, no API key, no registration — the deployment
// comes from the SDK's own spec, keyed by chain ID.
const privateKey = process.env.PRIVATE_KEY as `0x${string}`;
const fusor = new FusorClient({ privateKey });

const launch = await fusor.launchToken({
  name: 'My Token',
  symbol: 'MTK',
  markets: [
    { market: 'AAPL', weightBps: 6000 },
    { market: 'NVDA', weightBps: 4000 },
  ],
  metadataURI: 'https://example.com/metadata.json',
});

// One transaction, already mined by the time this line runs.
console.log(launch.txHash);
console.log(launch.explorerUrl);

// Read out of the MultiPairLaunchCreated event in the receipt — the real
// address, not the prediction a dry run gives you.
console.log(launch.tokenAddress);

// What the launch actually cost, read from the chain rather than assumed.
console.log(launch.launchFeeWei);

// Which implementation the proxy pointed at. Log it — it changes.
console.log(launch.implementation);

import os
from fusor import FusorClient

# No launchpad address, no API key, no registration — the deployment
# comes from the SDK's own spec, keyed by chain ID.
fusor = FusorClient(private_key=os.environ["PRIVATE_KEY"])

launch = fusor.launch_token(
    name="My Token",
    symbol="MTK",
    markets=[("AAPL", 6000), ("NVDA", 4000)],
    metadata_uri="https://example.com/metadata.json",
)

# One transaction, already mined by the time this line runs.
print(launch.tx_hash)
print(launch.explorer_url)

# Read out of the MultiPairLaunchCreated event in the receipt — the real
# address, not the prediction a dry run gives you.
print(launch.token_address)

# What the launch actually cost, read from the chain rather than assumed.
print(launch.launch_fee_wei)

# Which implementation the proxy pointed at. Log it — it changes.
print(launch.implementation)

When it fails

Which of the three error types you get tells you whether anything was spent and whether retrying can possibly help. This distinction is the whole reason they are separate types — a single catch-and-retry is how you burn gas on a call that will never succeed.

import {
  FusorConfigError, FusorPreflightError, FusorLaunchError,
} from '@fusor/sdk';

try {
  const launch = await fusor.launchToken({ /* … */ });
  return launch.tokenAddress;
} catch (e) {
  // Your input. Nothing was sent, nothing was spent, and the identical call
  // will fail identically forever. Never retry this one.
  if (e instanceof FusorConfigError) throw e;

  // A chain precondition failed during preflight — the transaction was never
  // built. Nothing was spent. Retrying later can work; retrying now will not.
  if (e instanceof FusorPreflightError) return scheduleRetry(e);

  // The contract rejected it. Branch on errorName, never on the message text.
  if (e instanceof FusorLaunchError) {
    switch (e.errorName) {
      case 'IncorrectLaunchFee':  // the fee changed under you
      case 'DeadlineExpired':     // sat in the mempool past the deadline
        return retryNow();        // launchToken re-reads every input
      case 'StaleOracle':         // a feed went stale mid-flight
      case 'StockTokenDisabled':  // the market was turned off
        return scheduleRetry(e);  // may clear on its own
      default:
        throw e;
    }
  }
  throw e;
}

from fusor import FusorConfigError, FusorPreflightError, FusorLaunchError

try:
    launch = fusor.launch_token(...)
except FusorConfigError:
    # Your input. Nothing was sent, nothing was spent, and the identical call
    # will fail identically forever. Never retry this one.
    raise
except FusorPreflightError as e:
    # A chain precondition failed during preflight — the transaction was never
    # built — nothing was spent. Retrying later can work; now will not.
    schedule_retry(e)
except FusorLaunchError as e:
    # Contract rejected it. Branch on error_name, never the message text.
    if e.error_name in ("IncorrectLaunchFee", "DeadlineExpired"):
        retry_now()              # launch_token re-reads every input
    elif e.error_name in ("StaleOracle", "StockTokenDisabled"):
        schedule_retry(e)        # may clear on its own
    else:
        raise

• Nothing spent, never retry. FusorConfigError — bad input, caught before any request.
• Nothing spent, retry later. FusorPreflightError — a chain precondition, usually oracle freshness.
• Gas possibly spent, depends on the name. FusorLaunchError — the contract reverted; all 32 custom errors are decoded to a name.

What one call actually does

launchToken is not a thin wrapper around eth_sendTransaction. It runs seven steps, and every one of them reads live chain state rather than trusting a cached or hard-coded value:

Steps 1 through 6 are also exported individually, so the signing step can live in a KMS, a hardware wallet or a multisig instead of in your process — see SDK Recipes.

Check before you send

Adding dryRun stops after step 6. It sends no transaction and spends nothing, but it does exercise the real contract against real state — so it is worth running once in staging, or before a launch you cannot repeat. It is not a required step: the same simulation runs inside every real launch.

const preview = await fusor.launchToken({
  name: 'My Token',
  symbol: 'MTK',
  markets: [
    { market: 'AAPL', weightBps: 6000 },
    { market: 'NVDA', weightBps: 4000 },
  ],
  metadataURI: 'https://example.com/metadata.json',
  dryRun: true,
});

console.log(preview.launchFeeWei);   // what it will cost, read from the chain
console.log(preview.estimatedGas);
console.log(preview.prices);         // every feed the launch depends on
console.log(preview.tokenAddress);   // predicted only — see the warning below

preview = fusor.launch_token(
    name="My Token",
    symbol="MTK",
    markets=[("AAPL", 6000), ("NVDA", 4000)],
    metadata_uri="https://example.com/metadata.json",
    dry_run=True,
)

print(preview.launch_fee_wei)   # what it will cost, read from the chain
print(preview.estimated_gas)
print(preview.prices)           # every feed the launch depends on
print(preview.token_address)    # predicted only — see the warning below

SDK Concepts

Six decisions shape how these SDKs behave. Each one exists because the obvious alternative fails in a specific way, so they are worth reading before you build around them.

1. Bring your own signer

The default is a raw private key, because the primary use case is an unattended process. But the core only needs something that can sign a transaction, so a KMS, a hardware signer, or a multisig flow all drop in. No signer at all is also valid — every read path works without one.

// 1) A raw key — bots, backends, CI
new FusorClient({ privateKey: process.env.PRIVATE_KEY as `0x${string}` });

// 2) Any viem Account — KMS, hardware, multisig, a custom signer
new FusorClient({ account: myKmsAccount });

// 3) No signer at all — read-only calls still work
const readonly = new FusorClient();
await readonly.preflight();
readonly.listQuoteMarkets();

# 1) A raw key
FusorClient(private_key=os.environ["PRIVATE_KEY"])

# 2) Any eth-account LocalAccount
FusorClient(account=my_local_account)

# 3) No signer at all — read-only calls still work
readonly = FusorClient()
readonly.preflight()
readonly.list_quote_markets()

2. Nothing about the deployment is hard-coded

The launchpad is an upgradeable proxy, and several of its numbers are deployment parameters rather than protocol constants. The SDK reads all of them on every launch:

3. The predicted address is not the real address

Simulation returns the address the token would receive at the launchpad's current nonce. Another launch landing first changes it. After sending, the SDK reads the address from the MultiPairLaunchCreated event in the receipt and only accepts the event if the launchpad proxy emitted it — anyone can emit an event with the same signature.

4. Errors are typed and named

Three classes tell you whose problem it is, and a decoded errorName tells you which contract condition failed. All 32 of the launchpad's custom errors are decodable, which is the difference between “execution reverted” and WeightsNotOneHundredPercent.

import { FusorError, FusorConfigError, FusorPreflightError, FusorLaunchError } from '@fusor/sdk';

try {
  await fusor.launchToken({ /* … */ });
} catch (e) {
  if (e instanceof FusorConfigError)    { /* your input — fix and retry immediately */ }
  if (e instanceof FusorPreflightError) { /* chain state — retry later may work      */ }
  if (e instanceof FusorLaunchError)    { /* the contract rejected it                */ }

  // Branch on errorName, never on the message text.
  if (e instanceof FusorError && e.errorName === 'StaleOracle') {
    await waitForKeeper();
  }
}

from fusor import FusorError, FusorConfigError, FusorPreflightError, FusorLaunchError

try:
    fusor.launch_token(...)
except FusorConfigError:
    ...     # your input — fix and retry immediately
except FusorPreflightError as e:
    if e.error_name == "StaleOracle":
        wait_for_keeper()
except FusorLaunchError as e:
    ...     # the contract rejected it; e.error_name is set when decodable

5. Metadata has a zero-network path

Pass metadataURI and the SDK makes no HTTP request at all — it needs nothing but an RPC endpoint, which is what lets a launch bot be fully self-hosted. Pass a metadata object plus an API base URL instead and the SDK uploads for you.

• The hash is computed over the bytes we send, not taken from the upload response. If a server reordered fields or added defaults, its hash would not describe what the URI serves — and the on-chain commitment is permanent.
• Field order in the canonical JSON is fixed. The hash is over exact bytes, so both SDKs emit the same key order, the same separators, and no HTML escaping. Golden vectors enforce this across languages.
• Neither is not an option. Omitting both raises rather than silently launching a token with no name, image, or links anywhere off-chain.

6. The SDKs cannot drift apart

Addresses, ABIs, selectors, constants and the quote-asset table are generated from the compiled contracts into one spec, then distributed into every package. On top of that, three sets of golden vectors are asserted by both test suites:

A separate structural test asserts that the spec copies inside every package are byte-identical to the source. Without it, editing the spec and forgetting to regenerate would leave every SDK using stale addresses while every existing test stayed green — each package is self-consistent even when all of them are wrong.

SDK Recipes

Find out what is launchable right now

Do this before offering a market to a user. Roughly half the registered stock tokens are priced by our own keeper, and those have an effective two-hour freshness window — so “is this asset registered” and “can I launch against it in this block” are genuinely different questions.

import { FusorClient, checkOracleFreshness, FusorPreflightError } from '@fusor/sdk';

const fusor = new FusorClient();                 // no signer needed to read
const pre = await fusor.preflight();

async function launchable(symbol: string) {
  const asset = fusor.listQuoteMarkets().find((a) => a.symbol === symbol);
  if (!asset) return { symbol, ok: false, why: 'unknown symbol' };
  try {
    await checkOracleFreshness(fusor.publicClient, {
      ethPriceFeed: pre.ethPriceFeed,
      stockRegistry: pre.stockRegistry,
      tokens: [{ symbol, token: asset.token }],
      maxAgeSeconds: pre.maxOracleAgeSeconds,
    });
    return { symbol, ok: true };
  } catch (e) {
    return { symbol, ok: false, why: e instanceof FusorPreflightError ? e.message : String(e) };
  }
}

console.log(await Promise.all(['AAPL', 'NVDA', 'AMC'].map(launchable)));

from fusor import FusorClient, check_oracle_freshness, FusorPreflightError, quote_asset_by_symbol

fusor = FusorClient()                            # no signer needed to read
pre = fusor.preflight()

def launchable(symbol: str):
    asset = quote_asset_by_symbol(symbol)
    if asset is None:
        return symbol, False, "unknown symbol"
    try:
        check_oracle_freshness(
            fusor.w3,
            eth_price_feed=pre.eth_price_feed,
            stock_registry=pre.stock_registry,
            tokens=[(symbol, asset.token)],
            max_age_seconds=pre.max_oracle_age_seconds,
        )
        return symbol, True, None
    except FusorPreflightError as e:
        return symbol, False, str(e)

for s in ("AAPL", "NVDA", "AMC"):
    print(launchable(s))

Let the SDK upload your metadata

Configure an API base URL and pass a metadata object instead of a URI. Images go up first as a data URL and only the resulting link is committed on-chain — image bytes never touch the chain.

const fusor = new FusorClient({
  privateKey: process.env.PRIVATE_KEY as `0x${string}`,
  apiBaseUrl: 'https://fusor.fun',
});

const { tokenAddress } = await fusor.launchToken({
  name: 'My Token',
  symbol: 'MTK',
  markets: ['AAPL'],
  metadata: {
    description: 'What this token is for.',
    image: 'data:image/png;base64,iVBORw0KGgo…',   // PNG, JPEG or WebP
    twitter: 'https://x.com/example',
    website: 'https://example.com',
  },
});

fusor = FusorClient(
    private_key=os.environ["PRIVATE_KEY"],
    api_base_url="https://fusor.fun",
)

result = fusor.launch_token(
    name="My Token",
    symbol="MTK",
    markets=["AAPL"],
    metadata={
        "description": "What this token is for.",
        "image": "data:image/png;base64,iVBORw0KGgo…",   # PNG, JPEG or WebP
        "twitter": "https://x.com/example",
        "website": "https://example.com",
    },
)

• PNG, JPEG and WebP are accepted; anything else is rejected before a request is made.
• An https:// image URL is passed through untouched — no upload happens.
• The committed hash is computed over the exact bytes the SDK sent, not over the server's reply.

Use your own RPC

The default endpoint is public and rate-limited. Anything doing volume should point at its own node; some providers also need an auth header or an allowlisted origin.

const fusor = new FusorClient({
  privateKey: process.env.PRIVATE_KEY as `0x${string}`,
  rpcUrl: 'https://my-node.example/rpc',
  // Some providers authenticate by header, or require an allowlisted Origin.
  rpcHeaders: { Authorization: `Bearer ${process.env.RPC_TOKEN}` },
});

Keep the key somewhere else

Every step of the launch is also exported as a standalone function, so you can run the read-and-validate part in your service and hand only the final signing step to whatever custody you use. Nothing is hidden behind the client class.

import {
  preflight, resolveMarkets, checkOracleFreshness,
  resolveMetadata, buildLaunchParams, simulateLaunch,
  sendLaunch, tokenAddressFromReceipt,
} from '@fusor/sdk';

// Every step is exported separately, so the signing step can live anywhere —
// a KMS, a hardware wallet, a multisig proposal, an air-gapped machine.
const pre = await preflight(publicClient, launchpad);
const markets = await resolveMarkets(publicClient, pre.stockRegistry, ['AAPL', 'NVDA']);
await checkOracleFreshness(publicClient, {
  ethPriceFeed: pre.ethPriceFeed,
  stockRegistry: pre.stockRegistry,
  tokens: markets,
  maxAgeSeconds: pre.maxOracleAgeSeconds,
});

const { metadataURI, metadataHash } = await resolveMetadata({
  name: 'My Token', symbol: 'MTK', metadataURI: 'https://example.com/m.json',
});

const params = buildLaunchParams({
  name: 'My Token', symbol: 'MTK', metadataURI, metadataHash, markets,
  creator: signerAddress,
  deadline: BigInt(Math.floor(Date.now() / 1000) + 1800),
});

const simulated = await simulateLaunch(publicClient, {
  launchpad, account: signerAddress, params, launchFeeWei: pre.launchFeeWei,
});

// …hand `simulated.request` to whatever holds the key, then:
const hash = await sendLaunch(walletClient, simulated, account);
const receipt = await publicClient.waitForTransactionReceipt({ hash });
const tokenAddress = tokenAddressFromReceipt(receipt, launchpad);

Things worth getting right

• Re-run preflight per launch. Do not cache it across launches. The proxy can be upgraded and the fee can change between two calls, and a cached preflight is how you sign against parameters that no longer hold.
• Keep deadlines short. The default is 30 minutes. A long deadline lets a transaction sit in the mempool while prices move; the deadline is the guard against exactly that.
• Never trust the predicted address. Read it from the receipt event, and verify the event came from the launchpad proxy.
• Do not retry blindly on failure. A ConfigError will fail identically forever. Only a PreflightError about freshness is worth retrying, and then only after waiting.

REST API

A read-mostly HTTP API over indexed chain data, plus a few helpers for uploads and reference prices. Everything is under /api. Most endpoints need no authentication at all.

Conventions

Write endpoints use single-use challenges

Anything that mutates a profile or a watchlist requires a signature over a challenge issued moments earlier. The pattern is deliberate and has two consequences you have to design around:

• A challenge expires in five minutes, so fetch it immediately before asking the user to sign — not when your form loads.
• Each challenge works exactly once. Retrying a failed request needs a new challenge, not the same one again.

Deployed Addresses

Everything below is on Robinhood Chain (chain ID 4663). One address is the entry point — the launchpad proxy. The rest are here so that a transaction trace or an event log makes sense, not because you need to call them.

Fusor protocol

Uniswap V4 (Robinhood Chain)

Robinhood Universal Router compatibility

Direct swaps execute the V4 action sequence SWAP_EXACT_IN_SINGLE → SETTLE → TAKE(0x060b0e). SETTLE pays the full input-token debt from the connected wallet, and TAKE sends the full output-token credit to that wallet. Integrators should validate calldata against the deployed Robinhood router ABI rather than copying the standard Uniswap struct.

Robinhood Chain

• Chain ID: 4663
• RPC: https://rpc.mainnet.chain.robinhood.com
• Explorer: robinhoodchain.blockscout.com

Constants & Limits

Every number the protocol enforces, in one place. The split below matters more than any individual value: some of these are compiled into the contracts and can be relied on, and some are set at deployment and must be read.

Read these — do not embed them

These are deployment parameters. They are correct only for the deployment you are talking to, and they can change. The table gives you the getter, deliberately not the number.

Protocol constants

These are compiled in. They do not vary by deployment and are safe to rely on.

Launch protection window

Fees

Routing

Chain and encoding

• Chain ID: 4663
• launchTokenMulti selector: 0x07489e0a — the 11-field overload. The contract declares a second function of the same name; only this one is callable here.
• Custom errors: 32, all decodable from the ABI. Branch on the error name, never on message text.
• Liquidity tick bounds: ±887200 — Uniswap's usable extremes, not a Fusor parameter and not a price target.
• ERC-1967 implementation slot: the standard one, keccak256("eip1967.proxy.implementation") - 1.