Protocol guide

Protocol

Overview

Origoo is an EVM token-launch protocol. The frontend prepares transactions; the smart contracts mint the token, enforce team locks, run the selected launch mechanism, and route liquidity and trading fees. Assets can sit in protocol contracts while a launch is active, but there is no off-chain Origoo account that users deposit into.

A launch starts by choosing a quote asset and one of three market structures. Bonding Curve opens trading immediately on an on-chain curve. Direct Launch opens the chain's AMM pool immediately. Crowd Launch collects deposits for a fixed window and opens the AMM market only after the sale settles successfully.

Protocol

Protocol rules worth knowing

• One liquidity venue per chain. A deployment has one canonical adapter. Origoo does not silently fall back from one DEX to another if migration fails.
• The quote asset stays the quote asset. A USDC curve graduates into a USDC pool; it is not converted through ETH on the way.
• The fee split is fixed. Trading fees are routed 50% to the creator destination, 30% to Origoo, and 20% to permanent LP inventory.
• Creator-fee strategy is chosen at launch. The creator share can go to a payout address, Buyback & Burn, or Holder Rewards. Strategy modes cannot later be switched into a normal creator withdrawal address.
• Emergency pause only blocks new launches. Existing markets, settlement, refunds, graduation, and fee claims are not converted into an admin-controlled exit path.

Launch modes

Bonding Curve

A curve launch creates a token and a dedicated BondingCurve. Creators choose how much market supply goes through the curve — 60% to 80% — and can tune the opening depth. Buys and sells happen against the curve until its real token reserve reaches zero. The remaining market tokens and the accounted quote reserve then move into permanent liquidity on the same chain's canonical venue.

Direct Launch

Direct Launch skips the curve. The launcher mints the token and initializes its canonical pool in the same transaction. The pool can start one-sided or with optional quote liquidity, and the creator can include an initial buy. There is no graduation step because the market is already on the AMM.

Crowd Launch

Crowd Launch is a subscription sale rather than a first-come auction. Participants deposit during a fixed window. Once the window closes, every participant settles at the same final price and receives tokens in proportion to their share of total deposits.

Hook Market

Coming soon.

How Crowd Launch settles

Crowd Launch always splits market supply 50/50: half is reserved for participants and half for permanent liquidity. Team allocation, if any, is removed before that split. The creator does not receive the amount raised; accepted quote assets seed the permanent pool together with the LP half of market supply.

If the minimum is not reached, the sale finalizes to refunds. If the minimum is reached, migration can be retried against the same canonical venue during the 24-hour migration window. It never switches DEXes to force settlement. If migration is still unresolved when that window expires, the launch can be moved to the full-refund path.

Token claims and quote refunds are deliberately separate. A successful participant can claim launch tokens without making an excess-refund transfer part of the same call. Failed-sale refunds can also be directed to another non-zero recipient address.

Token name and ticker limits

The launch form intentionally limits token names to 40 and ticker symbols to 10 UTF-16 code units, matching the browser input length rules. These are frontend product limits for readable launch cards and tickers, not contract limits. Emoji and other supplementary characters count as two code units each. Leading and trailing whitespace is trimmed before submission; blank names and symbols are rejected.

All three launch modes use this UI policy. The P3 contracts support longer UTF-8 names and symbols through variable-length appended immutable args; direct contract integrations retain that capability. The frontend does not truncate metadata read from existing tokens.

Supply and team lock

All three launch modes use the same supply rules. Total supply can be set from 100,000 to 1,000,000,000 tokens. Up to 40% may be separated as team supply.

A non-zero team allocation stays in token-contract custody for 1, 3, 6, 9, or 12 months; one month is the default. Each lock month is 30 days on-chain. When the lock expires,claimTeamTokens() can be triggered by anyone, but the tokens can only go to the beneficiary fixed at launch.

Team tokens are excluded from market inventory while locked. For Bonding Curve, curve and migration amounts are calculated from the remaining market supply. For Crowd Launch, that market supply is split equally between participants and permanent LP. For Direct Launch, market supply is assigned to the initial pool inventory.

Pairing assets

The launch token is always quoted against a base asset. The chain's native asset is supported directly. An ERC-20 quote asset must be approved by the Origoo factory before it can be used by Bonding Curve, Direct Launch, or Crowd Launch. Pasting a contract address into the interface does not bypass that on-chain rule.

Exact-transfer means the amount debited from the sender and received by the destination must match the amount being accounted for. Fee-on-transfer, rebasing, sender-surcharge, or other unusual transfer behaviour is therefore not accepted for launch quote assets. The Flywheel repeats balance-delta checks while routing ERC-20 protocol revenue and funding rewards. In every mode, the quote asset stays the pair asset when the market moves to permanent liquidity.

Markets

Pricing and settlement

On a Bonding Curve, getAmountOutForBuy and getAmountOutForSellquote trades from the curve's virtual reserves. marketCapQuote is an implied valuation in the selected quote asset; it is not an oracle price.

Direct Launch uses the AMM price immediately. Crowd Launch has no AMM trading during its deposit window: the final clearing price is determined from accepted quote and the fixed participant token supply, then the permanent pool is initialized at the matching price.

Quotes shown by the interface are previews. The executed result can differ because of slippage, transactions landing in a different order, AMM state changes, or integer rounding.

Graduation and migration

Bonding Curve

Creators choose 60%–80% of market supply for the curve, with 80% as the default. Graduation readiness is simple: realTokenReserve == 0. progressBps() reports the sold share of configured curve inventory. There is no USD target and no price oracle in the graduation condition.

The final curve state fixes the migration price. If the canonical venue is temporarily unavailable, migration remains retryable against that same venue; the factory does not pick a different DEX. Permanent-LP surplus is retained for liquidity rather than returned to the creator.

Crowd Launch

Crowd settlement starts after the deposit window. Below the minimum raise, all contributions are refundable. At or above the minimum, accepted quote and the reserved LP token half are migrated at the uniform clearing price. The migration deadline is 24 hours after the sale ends; after that, unresolved launches use the refund path instead of a venue switch.

Direct Launch

There is no graduation. The canonical pool is the launch market from creation.

Trading fees

The launchpad fee split remains 50% creator, 20% permanent LP and 30% protocol. Protocol allocation is 10% Treasury plus 20% reserved for the later, manually funded Flywheel.

On the current canonical venues, creators choose a total trading fee from 1% to 5% in 0.1% steps. The setting is written at launch. Crowd deposits themselves are not trades; the selected fee starts applying after the Crowd market migrates and opens.

In normal payout mode, the creator can update the payout recipient. Buyback & Burn and Holder Rewards are strategy modes fixed at launch and cannot be redirected into a creator withdrawal address. Protocol fees retain the asset earned through FeeEscrow and the Protocol Router. Conversion is a manual operation after wallet routing.

Stewardship

Community Takeover

Community Takeover is a post-launch stewardship process, not a launch mode. For ordinary creator payout launches, the original creator stays visible forever. The current steward can propose a successor, who must explicitly accept. An abandoned project can have a reviewed community request with public evidence. The proposed community wallet must accept the nomination before the Factory deployment wallet can schedule it.

A scheduled request has 72 hours of public notice and a 72-hour execution window. Anyone can execute during that window. The reviewer may cancel the request before execution, but cannot directly pick an arbitrary fee recipient. The current creator cannot cancel an approved request merely by claiming fees, updating metadata, or proposing another successor.

Stewardship transfers atomically push the recipient into the launch contract and its live hook. Trading, graduation and fee sweeps use that local recipient even if the registry becomes unavailable; changing the creator payout address may still fail while it is unavailable.

Native strategy vaults use native currency directly. Explicit ERC20 WETH/WBNB quotes remain supported. Sending wrapped-native tokens directly to a native-quote strategy vault is unsupported and may strand them.

Only future creator fees follow the new steward. Creator fees already accrued before the takeover remain claimable by the previous fee recipient, including fees that have not yet been swept. Origoo's 30% share and the permanent LP's 20% remain unchanged. The original launch mode and canonical pool also remain unchanged.

Community Takeover does not confiscate the original creator's token holdings or team allocation. Existing token locks and permanent liquidity remain unchanged. The Buyback & Burn and Holder Rewards fee destinations are immutable selections and are ineligible for the V1 payout handover.

Three phases, one protocol

Phase 1 deploys the launchpad, FeeEscrow and Protocol Router. It operates without ORIGOO, rewards or Flywheel. Treasury receives 10% of applicable trading fees; the remaining 20% protocol allocation accumulates for the future Flywheel. Creator and permanent-liquidity economics remain unchanged.

Phase 2 launches ORIGOO through the normal launcher. Phase 3 deploys the Robinhood ETH Flywheel, canonical buyback vault, LP rewards and token-lock rewards. After manual consolidation, each authorized ETH batch splits 50% buyback, 30% LP rewards and 20% lock rewards. No ORIGOO emissions are created.

Deterministic routing, manual funding

Anyone can trigger claims of earned protocol revenue from FeeEscrow. The router measures only newly received value, floors Treasury to one-third and routes the remainder. Failed recipient payments become debt owed to the original recipient, who can withdraw to another address even after wallet rotation or a router pause. Tokens must transfer exactly.

Protocol fee allocation and wallet routing are deterministic on-chain. Subsequent conversion, cross-chain consolidation and Flywheel funding are manually operated by Origoo. There is no automatic weekly transfer, minimum funding threshold or wallet pull.

Only the authorized Fee Wallet can call fundAndDistribute() on Robinhood. Each batch distributes exactly its attached ETH; plain ETH transfers are rejected and forced donations are not counted. Any downstream failure reverts the complete batch.

Rewards are booked into the next weekly epoch. Several batches in an epoch add together. Rewards in a completed zero-weight epoch can be swept to Treasury; they do not automatically roll forward. Indivisible pro-rata dust carries into the next future epoch only after all eligible weight has been processed.

Flywheel

Locking ORIGOO

ORIGOO locking is deliberately isolated. Every position deploys its own OpenZeppelinTokenTimelock, with the connected wallet as beneficiary. ORIGOO moves directly from the wallet into that timelock; there is no pooled Origoo staking vault holding user principal.

The selected multiplier applies while the principal is actually timelocked and eligible for completed weekly epochs. At maturity the beneficiary releases principal from the timelock itself; the reward contract does not gain a withdrawal path over that ORIGOO.

Flywheel

Providing canonical liquidity

The canonical Flywheel market is a full-range ORIGOO/native-ETH Uniswap v4 position on Robinhood Chain. Liquidity is minted through the official PositionManager directly to the user's wallet. Origoo does not wrap the position in an LP-share token and does not custody the NFT.

The current canonical market uses a 0.25% Uniswap LP fee plus a 0.05% Origoo hook fee. The 0.05% hook fee is booked during swap settlement and can be withdrawn to the current Treasury wallet; it is separate from the launch-market 50/30/20 trading-fee split above.

The liquidity flow uses amount-bounded approval to the official Permit2, a short-lived PositionManager authorization, and post-mint approval cleanup. Bonding-curve ERC-20 buys use the same defensive principle: zero-first approval where required and an attempt to revoke any residual allowance after the trade completes.

Flywheel

Committing ORIGOO/ETH LP

The Flywheel page follows the actual user journey: 01 Lock ORIGOO, 02 Provide canonical liquidity, 03 Commit ORIGOO/ETH LP, then 04 Canonical market revenue. Users do not need to find or type a Uniswap position token ID.

After liquidity is minted, the new position is picked up from the confirmed transaction. For positions created earlier, Origoo discovers NFTs owned by the connected wallet from the fixed official Robinhood PositionManager, re-checks ownership, and filters candidates for the exact canonical pool, full-range ticks, and non-zero liquidity. One eligible position is selected automatically; multiple positions are shown as explicit choices.

LP commitments use the same 1 / 3 / 6 / 12 month terms and 1.00x / 1.20x / 1.50x / 2.00x multipliers as ORIGOO locks. The Uniswap NFT stays in the user's wallet. Changing liquidity, transferring the NFT, burning it, unsubscribing, or exiting before maturity ends the active reward commitment. An early exit forfeits Flywheel rewards; it does not confiscate LP principal.

Treasury, buyback and administration

Treasury is independent of Flywheel. Its share arrives in the asset earned, with no required swap or bridge. The separate canonical ORIGOO/ETH hook books its 0.05% Treasury fee for permissionless withdrawal directly to Treasury; it never enters the 30% launchpad allocation or Flywheel.

Origoo uses three externally supplied, distinct wallets: Treasury, Fee and Settlement. They may be EOAs or contract-controlled addresses. On recognized live production networks, ORIGOO_PROTOCOL_ADMIN is required and must differ from the deployment signer. Local Hardhat/localhost environments may use the local signer fallback. The admin may equal an economic wallet and can later transfer control using two-step ownership.

On recognized live production networks, the Flywheel admin must be explicitly configured through ORIGOO_FLYWHEEL_ADMIN or ORIGOO_PROTOCOL_ADMIN and must differ from the deployment signer. Only local Hardhat/localhost environments may use the local signer fallback. The later Flywheel has immutable Buyback, LP and Lock destinations and an admin-managed authorized funder. Reward contracts are wired once to Flywheel. Buyback execution remains restricted to the canonical ORIGOO/ETH pool with an explicit amount and minimum net ORIGOO output; purchased ORIGOO is burned.

Cross-chain manual operations

The exact same Treasury, Fee and Settlement addresses are reused on every EVM chain. Balances are chain-specific. Protocol contracts do not contain bridge providers, DEX routes or conversion oracles for fee settlement.

• Robinhood: Settlement converts tokens to ETH and sends ETH to Fee Wallet. No bridge is needed.
• Other ETH-native chains: Settlement converts tokens to native ETH and sends it to Fee Wallet. Origoo manually bridges ETH to the same Fee Wallet address on Robinhood.
• Non-ETH-native chains: Settlement converts tokens to the local native asset and sends it to Fee Wallet. Fee Wallet manually converts native value to ETH, then bridges ETH to Robinhood.
• Arc: native USDC uses the native path and the chain-native 18-decimal balance unit. Its prohibited ERC-20 USDC alias is not supported.

Once ready in Phase 3, Robinhood Fee Wallet calls the payable Flywheel funding function. Sending or bridging funds directly to a reward contract does not create an official batch. Origoo contracts never route non-native Flywheel revenue directly to Fee Wallet; external wallets can still receive unsolicited assets.

Canonical venues

Each factory is bound to one liquidity adapter. BNB Smart Chain uses PancakeSwap Infinity CLAMM. Robinhood Chain, Ethereum, Base, Arbitrum, Arc, and OP Mainnet use Uniswap v4 in the current canonical architecture. Testnets and future chains need an explicit matching deployment rather than inheriting a fallback venue.

Risk notes

• Bonding-curve prices can move sharply when curve depth is small.
• Direct pools can begin with limited quote liquidity and large early price movement.
• Crowd Launch can fail its minimum raise or end in refunds if migration is not completed in time.
• Approved ERC-20 quote assets can still carry issuer, blacklist, upgrade, or later behaviour-change risks; exact-transfer checks reject inexact routing rather than making the asset trustless.
• Two tokens can use the same name, symbol, and image. Verify the contract address.
• RPC endpoints and indexers can lag even when the underlying contracts are operating normally.

Origoo is launch and trading infrastructure. A token appearing in the interface is not an endorsement of the token, its creator, or its market value.

Integrate

Chain registry

Network configuration lives in the shared chain registry: RPC endpoints, explorer URLs, canonical venue, factory address, launchers/coordinators, and the curated asset list used by the interface. An integration should resolve addresses by chain ID instead of assuming that the same address is deployed everywhere.

Deployed contracts

A blank factory address means the network is available in the interface but the Origoo launch contracts are not configured in this build.

Events to index

The factory remains the root for Bonding Curve launches. Direct launchers and the Crowd coordinator emit their own creation events. Index the event source for the mode you support instead of trying to infer launches from token transfers.

Bonding Curve factory

event LaunchCreated(
  address indexed creator,
  address indexed token,
  address indexed curve,
  string name,
  string symbol,
  string metadataURI
);

event LaunchBaseAsset(
  address indexed token,
  address indexed curve,
  address indexed baseAsset
);

Opening FDV means opening token price multiplied by total supply. Net Curve Raise excludes trading fees; Graduation FDV uses the graduation price and total supply. Advanced curve allocation, depth and team settings change these estimates. Zero-seed Direct Launch uses the default curve’s Reference Opening FDV, rounded to the venue’s tick spacing. Seeded Direct Launch uses the actual quote/token liquidity ratio. Uncalibrated or stale ERC-20 quote assets are unavailable for new Curve and Direct launches until governance fixes calibration; existing markets retain their original configuration.

Bonding Curve lifecycle

event Buy(address indexed buyer, uint256 baseIn, uint256 tokensOut, uint256 fee);
event Sell(address indexed seller, uint256 tokensIn, uint256 baseOut, uint256 fee);
event BondingCurveFeeSplit(uint256 fee, uint256 creatorAmount, uint256 protocolAmount, uint256 lpAmount);
event Graduated(uint256 baseAmount, uint256 tokenAmount);
event MigratedV4(bytes32 indexed poolId, address indexed hook, uint256 baseIntoLp, uint256 tokensIntoLp);

Direct Launch

event DirectLaunchCreated(
  address indexed creator,
  address indexed token,
  bytes32 indexed poolId,
  string name,
  string symbol,
  string metadataURI,
  uint256 totalSupply,
  address baseAsset
);

event DirectInitialBuy(
  address indexed creator,
  address indexed token,
  address indexed baseAsset,
  uint256 baseAmount,
  uint256 tokensOut
);

Both Uniswap v4 and Pancake Infinity Direct launches emit a bytes32 pool ID. Venue 2 is retired and cannot be selected.

Crowd Launch coordinator

event CrowdLaunchCreated(
  address indexed creator,
  address indexed token,
  address indexed crowd,
  string name,
  string symbol,
  string metadataURI,
  uint256 totalSupply,
  uint256 saleSupply,
  uint256 lpTokenSupply,
  address baseAsset,
  uint256 minimumRaise,
  uint64 endTime,
  uint16 saleAllocationBps,
  uint16 tradeFeeBps,
  uint8 venue
);

event CrowdLaunchBatchTerms(
  address indexed token,
  uint256 maximumRaise,
  uint256 minContribution,
  uint64 migrationDeadline
);

event CrowdLaunchSettled(
  address indexed token,
  address indexed crowd,
  bool success,
  uint8 venue,
  bytes32 venueId,
  address feeManager,
  address pool
);

Robinhood Flywheel

For Flywheel accounting, index revenue distribution, lock/commitment creation, reward funding, remainder carry-forward, claims, invalidations, and protocol wallet updates. LP discovery in the interface additionally reads Transfer history from the fixed official PositionManager and re-verifies current ownership on-chain.

RevenueRouted(asset, totalProtocolRevenue, treasuryAmount, flywheelAmount, flywheelDestination)
FlywheelFunded(funder, batch, amount)
FlywheelDistributed(batch, buybackAmount, lpAmount, lockAmount)
TokenLocked(account, positionId, lockWallet, amount, weight, startEpoch, endEpoch, unlockAt, term)
LPCommitted(owner, commitmentId, tokenId, liquidity, weight, startEpoch, endEpoch, term)
LPCommitmentEnded(owner, commitmentId, tokenId, effectiveEndEpoch, completed, forfeited, reason)
RewardFunded(asset, epoch, amount)
RewardRemainderCarried(asset, fromEpoch, toEpoch, amount)
RewardClaimed(...)
WalletsUpdated(treasury, fee, settlement)
PaymentDeferred(asset, recipient, amount)
DeferredWithdrawal(asset, recipient, to, amount)
AuthorizedFunderUpdated(previous, next)

Read a Bonding Curve

Trade quotes and graduation progress are readable directly from the curve. An indexer is useful for discovery and history, but it is not required to price the next curve trade.

import { parseAbi, createPublicClient, http } from "viem";

const curveAbi = parseAbi([
  "function baseAsset() view returns (address)",
  "function marketCapQuote() view returns (uint256)",
  "function graduationReady() view returns (bool)",
  "function progressBps() view returns (uint256)",
  "function getAmountOutForBuy(uint256 baseIn) view returns (uint256 tokensOut)",
  "function getAmountOutForSell(uint256 tokensIn) view returns (uint256 baseOut)",
  "function creatorFeeRecipient() view returns (address)",
]);

const client = createPublicClient({ chain: originChain, transport: http(rpcUrl) });

const [baseAsset, marketCap, ready, progressBps] = await Promise.all([
  client.readContract({ address: curve, abi: curveAbi, functionName: "baseAsset" }),
  client.readContract({ address: curve, abi: curveAbi, functionName: "marketCapQuote" }),
  client.readContract({ address: curve, abi: curveAbi, functionName: "graduationReady" }),
  client.readContract({ address: curve, abi: curveAbi, functionName: "progressBps" }),
]);

Discover the curve from LaunchCreated; do not derive the address off-chain and assume the derivation will remain part of the public interface.

Read a Crowd Launch

CrowdLaunchCoordinator.crowdSnapshot(token, account) returns the sale terms, current state, migration deadline, pool identity, and account-specific claim/refund fields in one call.

const crowdCoordinatorAbi = parseAbi([
  "function crowdSnapshot(address token,address account) view returns ((address crowdAddress,uint256 totalContributed,uint256 minimumRaise,uint256 maximumRaise,uint256 acceptedRaise,uint256 minContribution,uint64 startTime,uint64 endTime,uint64 migrationDeadline,uint256 saleSupply,uint256 lpTokenSupply,bool finalized,bool successful,bool migrated,uint8 state,uint256 contribution,bool tokenClaimed,bool excessRefundClaimed,bool failedRefundClaimed,uint256 claimable,uint256 refundable,uint256 acceptedContribution,uint256 allowance,uint8 venue,bytes32 poolId,address pool,address feeManager))",
]);

const snapshot = await client.readContract({
  address: crowdCoordinator,
  abi: crowdCoordinatorAbi,
  functionName: "crowdSnapshot",
  args: [token, account],
});

Crowd state values are: 0 active, 1 ended and ready to settle,2 below minimum, 3 migrated successfully, 4 finalized failure, and 5 migration deadline expired / refundable.

Fee claims

During Bonding Curve trading, creator and protocol amounts are credited throughFeeEscrow. After a market is on its canonical AMM, fee collection and permanent LP accounting move to the venue hook/adapter for that pool.

const feeEscrowAbi = parseAbi([
  "function balanceOf(address recipient) view returns (uint256)",
  "function balanceOfToken(address recipient,address token) view returns (uint256)",
  "function claim()",
  "function claimToken(address token)",
  "function claimTo(address recipient)",
  "function claimTokenTo(address token,address recipient)",
]);

Use the ABI shipped in frontend/app/web3/contracts.js for the current hook and coordinator interfaces. That file is kept in sync with the frontend's live contract calls and covers both canonical venues.

FAQ

Does depositing early in Crowd Launch give a better allocation?

No. Allocation is pro-rata after the window closes. A wallet's share depends on its contribution relative to total contributions, not the timestamp of the deposit.

Does the creator receive the Crowd Launch raise?

No. Accepted quote assets are used to seed permanent liquidity. The creator participates in ongoing trading fees through the creator-fee destination selected at launch.

Can Origoo switch a launch to another DEX if migration fails?

No. The liquidity adapter is fixed for the deployment. A temporary failure is retried on the same canonical venue; Crowd Launch eventually falls back to refunds, not another DEX.

Can I use any ERC-20 pair?

No. The launch form exposes the factory-approved quote-asset list and lets you search it by token name or contract address. There is no unrestricted custom-token entry path. An ERC-20 must already be approved by the factory, use 6–18 decimals, and satisfy Origoo's runtime exact-transfer checks before it can be used for a new launch.

Does Origoo custody my ORIGOO or LP when I use the Flywheel?

ORIGOO lock principal sits in an isolated OpenZeppelin TokenTimelock with you as beneficiary. Canonical ORIGOO/ETH liquidity remains in the official Uniswap v4 position NFT in your wallet. Origoo contracts account for rewards but do not hold the LP NFT as staking principal.

Do I have to enter my LP NFT number?

No. The Flywheel automatically discovers eligible canonical positions for the connected wallet. One position is selected automatically; if several are eligible, you choose from the detected positions. The selected NFT is still re-verified on-chain before commitment.

Can the trading-fee split change after launch?

No. The Origoo split remains 50% creator destination / 30% Origoo / 20% permanent LP. In normal payout mode the creator can change the recipient address, but strategy modes such as Buyback & Burn or Holder Rewards are locked.

Support

For contract integration, indexing, deployment, or fee-accounting questions, contact contact@origoo.org.

Deployed contracts are immutable. Protocol revisions are shipped as new deployment addresses and should be treated as separate versions by indexers.