# Bonding Curves Mathematics Source: https://docs.mobula.io/almanac/bonding-curves Deep dive into bonding curve mechanics for Pumpfun, Meteora DBC, and other launchpads # Bonding Curves: The Mathematics of Fair Launches Bonding curves are smart contract mechanisms that automatically determine token prices based on supply and demand. They enable **fair launches** where everyone trades against the same mathematical formula, eliminating the need for market makers and preventing price manipulation. **Why it matters**: Understanding bonding curve math helps you predict price movements, identify bonding thresholds, and build trading strategies around launchpad tokens. ## What is a Bonding Curve? A bonding curve is a mathematical function that defines the relationship between a token's price and its supply. As tokens are bought, the price increases along the curve. As tokens are sold, the price decreases. ``` Price = f(Supply) ``` The most common types are: | Curve Type | Formula | Characteristics | | - | - | - | | **Constant Product (x\*y=k)** | `price = k / supply` | Hyperbolic curve, used by Pumpfun | | **Exponential** | `price = base^supply` | Aggressive price growth | | **Linear** | `price = m * supply + b` | Predictable, steady growth | | **Sqrt Price** | `price = sqrtPrice² / 2^128` | Concentrated liquidity, used by Meteora DBC | *** ## Pumpfun: Constant Product AMM Pumpfun uses a **constant product Automated Market Maker (AMM)** with virtual reserves. This is the same formula popularized by Uniswap V2. ### Core Formula ``` x * y = k (constant) ``` Where: * `x` = Virtual SOL reserves (`reserve0`) * `y` = Virtual Token reserves (`reserve1`) * `k` = Constant product (invariant) ### Understanding Virtual vs Real Reserves **Critical Concept**: Pumpfun uses TWO types of reserves: * **Virtual Reserves**: Used for price calculation (includes "phantom" liquidity) * **Real Reserves**: Actual tokens/SOL locked in the contract | Reserve Type | SOL | Token | Purpose | | - | - | - | - | | **Virtual** | `virtualSolReserves` | `virtualTokenReserves` | Price calculation via AMM formula | | **Real** | `realSolReserves` | `realTokenReserves` | Actual assets in contract | | **Initial Virtual** | 30 SOL | 1,073,000,000,000,000 | Starting point for price curve | | **Initial Real Token** | 0 SOL | 793,100,000,000,000 | Tokens available for sale | **Why virtual reserves?** The virtual reserves create artificial depth at launch, preventing the first buyer from getting 100% of tokens for pennies. The 30 SOL virtual reserve means the price starts as if there's already 30 SOL of liquidity. ### Price Calculation The price (exchange rate) is calculated as: ```typescript theme={null} // Returns: how many tokens you get per 1 SOL exchangeRate = virtualTokenReserves / virtualSolReserves ``` In code: ```typescript theme={null} getPrice(pool: PumpfunPool): number { if (pool.reserve0 === 0n || pool.reserve1 === 0n) { return 0; } // reserve0 = virtualSolReserves, reserve1 = virtualTokenReserves // Returns tokens per SOL (exchange rate) return bigIntDiv(pool.reserve1, pool.reserve0); } ``` To get the **token price in SOL**: ```typescript theme={null} tokenPriceInSOL = virtualSolReserves / virtualTokenReserves // Or simply: 1 / exchangeRate ``` ### Initial Parameters When a Pumpfun token is created, the bonding curve initializes with: | Parameter | Value | Description | | - | - | - | | `initialVirtualSolReserves` | **30 SOL** (30,000,000,000 lamports) | Virtual SOL for price calculation | | `initialVirtualTokenReserves` | **1,073,000,000,000,000** | Virtual tokens (6 decimals = \~1.073B) | | `initialRealTokenReserves` | **793,100,000,000,000** | Actual tokens for sale (\~793.1M) | | `bondedCriteria` | **85.005 SOL** | Real SOL to trigger migration | **Note**: The total supply is 1B tokens, but only \~793.1M are available for purchase. The difference (\~280M) is the virtual reserve that creates initial price depth. ### How Buying Works When you buy tokens: 1. You send SOL to the bonding curve 2. The curve calculates tokens using the constant product formula: ```typescript theme={null} // Classic AMM swap formula tokens_out = (sol_in * virtualTokenReserves) / (virtualSolReserves + sol_in) ``` 3. Both virtual AND real reserves update: * `virtualSolReserves += sol_in` * `virtualTokenReserves -= tokens_out` * `realSolReserves += sol_in` * `realTokenReserves -= tokens_out` ### How Selling Works When you sell tokens: ```typescript theme={null} sol_out = (tokens_in * virtualSolReserves) / (virtualTokenReserves + tokens_in) ``` ### Bonding Percentage The bonding progress shows how close the token is to migration: ```typescript theme={null} // How many tokens have been sold vs total available bondingPercentage = (initialVirtualTokenReserves - currentVirtualTokenReserves) * 100 / initialRealTokenReserves ``` When tokens are bought, `virtualTokenReserves` decreases. The bonding percentage tracks what % of the `initialRealTokenReserves` has been purchased. ### Bonding (Migration) Threshold When `virtualSolReserves >= ~85 SOL`, the token "bonds" and migrates to Raydium: ```typescript theme={null} bondedCriteria = 86000000000n; // ~86 SOL in lamports async isBonded(pool: PumpfunPool): Promise { if (pool.bonded) return true; if (pool.reserve0 >= this.bondedCriteria) return true; return false; } ``` Since virtual SOL starts at 30 SOL, approximately **55-56 SOL** of real purchases triggers migration. ### Price Impact Formula For a given SOL input, the price impact is: ``` priceImpact = sol_in / (virtualSolReserves + sol_in) ``` **Example**: If virtual SOL reserves = 30 SOL and you buy with 3 SOL, your price impact is \~9.1%. Early buys have massive impact because of the relatively low virtual reserve. ### Numerical Example At launch: * Virtual SOL: 30,000,000,000 lamports (30 SOL) * Virtual Tokens: 1,073,000,000,000,000 (1.073B with 6 decimals) * Exchange rate: 1,073B / 30 = **35,766,666,666 tokens per SOL** * Token price: 30 / 1,073B = **0.000000028 SOL per token** After 10 SOL buy: * Tokens received: (10 × 1,073B) / (30 + 10) = **268,250,000,000 tokens** (\~268M) * New Virtual SOL: 40 SOL * New Virtual Tokens: 804,750,000,000,000 (804.75B) * New exchange rate: 804.75B / 40 = **20,118,750,000 tokens per SOL** * Price increased by \~44% *** ## Meteora DBC: Dynamic Bonding Curve Meteora's Dynamic Bonding Curve (DBC) uses a **sqrt price model** with concentrated liquidity, similar to Uniswap V3 but optimized for launchpads. ### Core Concept: Sqrt Price Instead of storing price directly, Meteora DBC stores the **square root of price** as a Q64.64 fixed-point number: ```typescript theme={null} sqrtPrice = sqrt(price) * 2^64 ``` To get the actual price: ```typescript theme={null} getPrice(pool: MeteoraDBCPool): number { const sqrtPrice = pool.extra?.sqrtPriceX64 ?? 0n; if (sqrtPrice === 0n) return 0; // Convert from Q64.64 fixed point return getPriceFromSqrtX(sqrtPrice, 64); } // Where getPriceFromSqrtX does: function getPriceFromSqrtX(sqrtPrice: bigint, resolution: number): number { const price = (sqrtPrice * sqrtPrice) / (1n << BigInt(resolution * 2)); return Number(price) / (2 ** resolution); } ``` ### The Curve Structure Meteora DBC defines a **curve** as an array of price/liquidity points: ```typescript theme={null} type Curve = Array<{ sqrtPrice: bigint; // Price at this point liquidity: bigint; // Liquidity available }>; ``` This creates a **piecewise linear** bonding curve where: * Each segment has different liquidity concentration * Price moves faster in segments with lower liquidity * Price moves slower in segments with higher liquidity ### Quote Reserve Calculation The virtual quote (SOL) reserve is calculated by integrating along the curve: ```typescript theme={null} calculateQuoteVirtualReserve(pool: MeteoraDBCPool): bigint { const curve = pool.extra.curve; const nextSqrtPrice = pool.extra.sqrtPriceX64; const sqrtStartPrice = pool.extra.sqrtPriceStart; let totalAmount = 0n; for (let i = 0; i < curve.length; i++) { const currentPoint = curve[i]; const lowerSqrtPrice = i === 0 ? sqrtStartPrice : curve[i - 1].sqrtPrice; if (nextSqrtPrice > lowerSqrtPrice) { const upperSqrtPrice = nextSqrtPrice < currentPoint.sqrtPrice ? nextSqrtPrice : currentPoint.sqrtPrice; // Calculate delta amount for this segment const maxAmountIn = getDeltaAmountQuoteUnsigned( lowerSqrtPrice, upperSqrtPrice, currentPoint.liquidity ); totalAmount += maxAmountIn; } } return totalAmount; } ``` ### Delta Amount Formula For each curve segment: ```typescript theme={null} getDeltaAmountQuoteUnsigned( lowerSqrtPrice: bigint, upperSqrtPrice: bigint, liquidity: bigint ): bigint { // Δquote = L * (√P_upper - √P_lower) / 2^128 const deltaSqrtPrice = upperSqrtPrice - lowerSqrtPrice; const prod = liquidity * deltaSqrtPrice; return prod >> BigInt(RESOLUTION * 2); // RESOLUTION = 64 } ``` ### Bonding Percentage Meteora DBC calculates bonding progress as: ```typescript theme={null} bondingPercentage = (quoteReserve / migrationQuoteThreshold) * 100 ``` When `bondingPercentage >= 100%`, the token migrates to Meteora DAMM. ### Migration Thresholds | Parameter | Description | | - | - | | `migrationQuoteThreshold` | SOL amount needed to trigger migration | | `sqrtPriceStart` | Initial sqrt price | | `curve` | Array of (sqrtPrice, liquidity) points defining the curve shape | *** ## Comparison: Pumpfun vs Meteora DBC | Aspect | Pumpfun | Meteora DBC | | - | - | - | | **Curve Type** | Constant Product (x\*y=k) | Sqrt Price with Concentrated Liquidity | | **Price Formula** | `SOL / Token` | `sqrtPrice² / 2^128` | | **Liquidity Distribution** | Uniform across all prices | Concentrated in curve segments | | **Price Impact** | Higher for same volume | Variable based on liquidity concentration | | **Bonding Trigger** | 86 SOL raised | Custom `migrationQuoteThreshold` | | **Migration Target** | Raydium | Meteora DAMM | | **Complexity** | Simple | More complex, more flexible | *** ## Practical Applications ### 1. Predicting Bonding Time For Pumpfun: ```typescript theme={null} // Bonding happens when virtualSolReserves reaches ~86 SOL // Since it starts at 30 SOL, you need ~56 SOL of real purchases const INITIAL_VIRTUAL_SOL = 30_000_000_000n; // 30 SOL const BONDED_CRITERIA = 86_000_000_000n; // 86 SOL // Current progress (using virtual reserves) const currentVirtualSol = pool.reserve0; const progress = Number(currentVirtualSol - INITIAL_VIRTUAL_SOL) * 100 / Number(BONDED_CRITERIA - INITIAL_VIRTUAL_SOL); // Real SOL needed to bond const solNeeded = BONDED_CRITERIA - currentVirtualSol; ``` For Meteora DBC: ```typescript theme={null} // Current progress const quoteReserve = calculateQuoteVirtualReserve(pool); const progress = (quoteReserve * 100n) / migrationQuoteThreshold; // SOL needed to bond const solNeeded = migrationQuoteThreshold - quoteReserve; ``` ### 2. Price Impact Estimation For a buy of `X` SOL on Pumpfun: ```typescript theme={null} // Current exchange rate (tokens per SOL) const currentRate = virtualTokenReserves / virtualSolReserves; // After your buy const newSolReserves = virtualSolReserves + X; const tokensReceived = (X * virtualTokenReserves) / newSolReserves; // Your effective rate (tokens per SOL) const effectiveRate = tokensReceived / X; // Price impact (how much worse your rate is vs spot) const priceImpact = (currentRate - effectiveRate) / currentRate; // Or equivalently: X / (virtualSolReserves + X) ``` ### 3. Slippage Calculation ```typescript theme={null} // Expected tokens at current spot rate (no slippage) const expectedTokens = (solIn * virtualTokenReserves) / virtualSolReserves; // Actual tokens (accounting for price impact) const actualTokens = (solIn * virtualTokenReserves) / (virtualSolReserves + solIn); // Slippage percentage const slippage = (expectedTokens - actualTokens) / expectedTokens * 100; // This equals: solIn / (virtualSolReserves + solIn) * 100 ``` ### 4. Calculating Token Price in USD ```typescript theme={null} // Get SOL price from oracle const solPriceUSD = 150; // example: $150 per SOL // Token price in SOL const tokenPriceInSOL = virtualSolReserves / virtualTokenReserves; // Token price in USD const tokenPriceUSD = tokenPriceInSOL * solPriceUSD; ``` *** ## API Access Query bonding curve data through Mobula's API: ```bash theme={null} # Get token details for a Pumpfun token (Fartcoin) curl -X GET "https://demo-api.mobula.io/api/2/token/details?blockchain=solana&address=9BB6NFEcjBCtnNLFko2FqVQBq8HHM13kCyYcdQbgpump" \ -H "Authorization: YOUR_API_KEY" # Get token details for Wojak curl -X GET "https://demo-api.mobula.io/api/2/token/details?blockchain=solana&address=8J69rbLTzWWgUJziFY8jeu5tDwEPBwUz4pKBMr5rpump" \ -H "Authorization: YOUR_API_KEY" ``` The response includes: * `bonded` - Whether the token has migrated to Raydium/Meteora * `bondingPercentage` - Progress toward migration (0-100) * `bondingCurveAddress` - Address of the bonding curve contract * `preBondingFactory` - Original launchpad (e.g., Pumpfun, Meteora DBC) * `liquidityUSD` - Current liquidity in the curve For real-time bonding curve updates, use the [WSS Market Details](/indexing-stream/stream/websocket/wss-market-details) WebSocket stream. # Borsh Parsing for Solana Instructions and Logs Source: https://docs.mobula.io/almanac/borsh-parsing-solana Understanding the three main methods to parse Borsh-encoded data from Solana transactions # Borsh Parsing for Solana Instructions and Logs When working with Solana transactions, you need to decode Borsh-encoded data to extract events and instruction data. This guide explains the three main approaches used in the codebase, each suited to different protocol implementations. **Why it matters**: Different Solana protocols emit events and instructions in different formats. Understanding which parsing method to use is crucial for correctly extracting swap data, liquidity events, and other on-chain information. ## Overview: Three Parsing Methods There are three primary methods to parse Borsh-encoded data from Solana transactions: 1. **`parseLogs()`** - Parse events directly from transaction log messages 2. **`borsh.events.decode()`** - Decode events from instruction data 3. **`borsh.instruction.decode()`** - Decode instruction data itself The method you use depends on how the protocol implements event emission. Some protocols emit events in transaction logs, while others embed events within instruction data. *** ## Method 1: parseLogs() - Event Parser from Logs This method parses events directly from the transaction's log messages. It's the most straightforward approach when protocols emit events as log entries. ### How it works The `EventParser` from Anchor reads the transaction's `logMessages` array and extracts structured event data based on the program's IDL. ### Example Implementation ```typescript theme={null} import { getSolanaParser } from '../getSolanaParser.ts'; const logMessages = tx.meta?.logMessages || []; const eventParser = getSolanaParser(PROGRAM_ID, 'event'); const parsedEvents = eventParser.parseLogs(logMessages); for (const e of parsedEvents) { if (e.name === 'SwapEvent') { const eventData = e.data; // Process swap event data } } ``` ### When to use * Events are emitted as log messages in the transaction * The protocol uses Anchor's standard event emission * You need to parse multiple events from a single transaction ### Characteristics * Works directly with `tx.meta.logMessages` * No need to decode instruction data manually * Events are already structured according to the IDL * Can parse multiple events from a single transaction *** ## Method 2: borsh.events.decode() - Decode Events from Instruction Data This method decodes events that are embedded within instruction data. You extract the event portion from the instruction bytes and decode it separately. ### How it works 1. Decode the instruction data from base58 2. Skip the first 8 bytes (instruction discriminator) 3. Extract the remaining bytes as event data 4. Encode to base64 and decode using `borsh.events.decode()` ### Example Implementation ```typescript theme={null} import { utils } from '@coral-xyz/anchor'; import { base64 } from '@coral-xyz/anchor/dist/cjs/utils/bytes/index.js'; import { getSolanaParser } from '../getSolanaParser.ts'; const borsh = getSolanaParser(PROGRAM_ID, 'borsh', true); // Decode instruction data const ixData = utils.bytes.bs58.decode(instruction.data); // Skip first 8 bytes (instruction discriminator) const eventData = ixData.subarray(8); // Encode to base64 for decoding const eventDataString = base64.encode(eventData); // Decode the event const event = borsh.events.decode(eventDataString); ``` ### When to use * Events are embedded within instruction data * The protocol doesn't emit events as separate log messages * You need to extract events from CPI (Cross-Program Invocation) calls ### Characteristics * Requires manual extraction of event data from instruction bytes * Must skip the instruction discriminator (first 8 bytes) * Events are encoded within the instruction data structure * Useful for parsing events from inner instructions *** ## Method 3: borsh.instruction.decode() - Decode Instruction Data This method decodes the instruction itself, not events. It's used when you need to extract instruction parameters or when instructions contain the data you need directly. ### How it works 1. Decode the instruction data from base58 2. Convert to Buffer format 3. Decode using `borsh.instruction.decode()` with the appropriate format ('hex' or 'base64') ### Example Implementation ```typescript theme={null} import { utils } from '@coral-xyz/anchor'; import { getSolanaParser } from '../getSolanaParser.ts'; const borsh = getSolanaParser(PROGRAM_ID, 'borsh', true); // Decode instruction data const decoded = utils.bytes.bs58.decode(instruction.data); const ixData = Buffer.from(decoded.buffer, decoded.byteOffset, decoded.byteLength); // Decode the instruction const decodedInstruction = borsh.instruction.decode(ixData, 'hex') as { name: string; data: Record; }; ``` ### When to use * You need instruction parameters, not events * The protocol embeds data directly in instructions * You're detecting instruction types (e.g., swap, deposit, withdraw) * You need to identify pool creation or migration instructions ### Characteristics * Decodes the entire instruction structure * Provides instruction name and parameters * Useful for instruction-based detection (e.g., pool creation) * Can be combined with event decoding for comprehensive parsing *** ## Fundamental Borsh Differences At the core Borsh level, the three methods differ in how they handle the **instruction discriminator** and **data structure**: ### Instruction Discriminator (8 bytes) In Solana, all Anchor instructions start with an **8-byte discriminator** that identifies the instruction type. This discriminator is computed from the instruction name using SHA256. **Structure of instruction data:** ``` [8 bytes: instruction discriminator][N bytes: instruction parameters] ``` ### Differences at the Borsh Level 1. **`parseLogs()` - Event Parser** * **Does NOT deal with instruction data directly** * Events are emitted by Anchor's runtime as **structured log messages** * The EventParser reads these log messages (which are already formatted strings) * No discriminator handling needed - logs are pre-processed by Anchor 2. **`borsh.events.decode()` - Event from Instruction Data** * **Must skip the 8-byte instruction discriminator** * The event data is embedded **after** the discriminator in the instruction bytes * You extract bytes 8+ and decode them as a Borsh event * The discriminator identifies the instruction, not the event 3. **`borsh.instruction.decode()` - Full Instruction Decode** * **Includes the 8-byte discriminator in the decode process** * Decodes the entire instruction structure: discriminator + parameters * Returns both the instruction name (from discriminator) and parameter data * Used when you need instruction parameters, not events ### Why This Matters The fundamental difference is **where the data lives** and **how Borsh deserializes it**: * **Logs**: Events are serialized by Anchor's runtime and written as log messages. The EventParser deserializes from these pre-formatted strings. * **Instruction data (events)**: Events are Borsh-encoded within instruction bytes, but you must skip the instruction discriminator to reach the event data. * **Instruction data (full)**: The entire instruction (discriminator + params) is Borsh-encoded together and decoded as one structure. ## Key Differences Summary | Method | Data Source | Borsh Structure | Discriminator Handling | | - | - | - | - | | `parseLogs()` | `tx.meta.logMessages` | Pre-formatted log strings | Not applicable (logs are already processed) | | `borsh.events.decode()` | Instruction data (bytes 8+) | Event data only (after discriminator) | Must skip first 8 bytes | | `borsh.instruction.decode()` | Instruction data (full) | Discriminator + parameters | Included in decode | *** ## Protocol Implementation Differences Different protocols implement event emission differently: The implementation approach depends on the protocol's architecture and how it structures its on-chain data. Always refer to the protocol's IDL to determine which method is appropriate. # Detecting Snipers & Bundlers Source: https://docs.mobula.io/almanac/detecting-snipers-bundlers Understanding how to identify snipers, bundlers, and insider traders in memecoin launches # Detecting Snipers & Bundlers When a new token launches, certain actors use automated tools and coordinated strategies to gain unfair advantages. Understanding these patterns is crucial for evaluating token health and avoiding manipulated launches. **Why it matters**: Tokens with high sniper/bundler activity often indicate coordinated manipulation. Detecting these patterns helps traders avoid rug pulls and identify legitimate organic trading. *** ## The Terminology ### Sniper A **sniper** is a wallet that purchases tokens within the first few blocks (typically 0-3 blocks) after a token launches. They use: * **MEV bots** to front-run other buyers * **Private RPCs** to get faster transaction inclusion * **Pre-signed transactions** ready to fire the moment the token deploys **Why it's a red flag**: Snipers often acquire large positions at the lowest prices, then dump on retail traders. A launch with 50%+ supply held by snipers is highly likely to experience a coordinated dump. ### Bundler A **bundler** coordinates multiple wallets to buy in the same block or even the same transaction. This is done to: * **Bypass max wallet limits** set by the token contract * **Create artificial demand** by making it look like many people are buying * **Distribute tokens** across wallets for a coordinated later dump **How to spot them**: Multiple wallets funded from the same source, all buying the exact same block, often with similar amounts. ### Insider An **insider** has privileged access to information about the token before public launch: * Funded directly by the deployer wallet * Has transaction history with the dev team * Bought tokens before any public announcement **Why it matters**: Insiders often have information about planned marketing, exchange listings, or know the dev won't rug. They profit from asymmetric information. ### Dev (Deployer) The **dev** tag marks the wallet that deployed the token contract. Tracking dev holdings is critical: * **Dev selling early** = major red flag * **Dev holding** = aligned incentives (but not always) * **Dev wallet transferring to new wallets** = potential stealth dump preparation *** ## How Detection Works ### Sniper Detection We identify snipers by analyzing the **timing and context** of early buys: | Signal | What We Check | | - | - | | **Block proximity** | Did the buy happen within 0-3 blocks of token creation? | | **Transaction position** | Was it in the same block as deployment or the very next? | | **Wallet age** | Was the wallet created recently (fresh wallet)? | | **Funding pattern** | Was it funded just before the launch? | | **Gas behavior** | Did it use high priority fees or MEV bundles? | A wallet matching multiple signals gets tagged as a sniper. ### Bundler Detection Bundlers are detected through **cluster analysis** of related wallets: | Signal | What We Check | | - | - | | **Same transaction** | Multiple distinct wallets buying in one atomic transaction | | **Common funder** | All wallets received ETH/SOL from the same source | | **Identical timing** | All buys in the exact same block | | **Similar amounts** | Buy amounts within a tight range (e.g., all buying 0.5 SOL) | | **Transfer patterns** | Tokens later consolidated to a single wallet | When we find a cluster of 3+ wallets with these patterns, all get tagged as bundlers. ### Insider Detection Insiders are identified through **on-chain relationship analysis**: | Signal | What We Check | | - | - | | **Deployer connection** | Direct transactions with the deployer wallet | | **Pre-launch activity** | Bought before any public announcement | | **Funding source** | Received funds from dev or known insider wallets | | **Timing correlation** | Activity patterns matching team wallets | *** ## Reading the Data ### Holder Concentration Metrics We calculate how concentrated token ownership is: | Metric | What It Means | | - | - | | **Top 10 Holdings %** | Percentage held by the 10 largest wallets | | **Top 50 Holdings %** | Percentage held by the 50 largest wallets | | **Top 100 Holdings %** | Percentage held by the 100 largest wallets | | **Dev Holdings %** | Percentage still held by the deployer | **Healthy ranges**: * Top 10: \< 30% (excluding liquidity pools) * Dev: \< 5% or locked/burned ### Tag Distribution For any token, you can see the breakdown of holder types: ```json theme={null} { "holdersCount": 1542, "taggedHolders": { "sniper": 23, "bundler": 45, "insider": 3, "dev": 1 }, "taggedHoldingsPercentage": { "sniper": 12.5, "bundler": 18.2, "insider": 4.1, "dev": 2.3 } } ``` *** ## Risk Assessment Framework ### Green Flags 🟢 * No snipers in top 20 holders * Zero bundler activity detected * Dev wallet has \< 3% and hasn't sold * Organic distribution across many wallets * Top 10 holds \< 25% ### Yellow Flags 🟡 * 1-2 snipers in top 20 (common, not always bad) * Small bundler cluster (\< 5% total holdings) * Dev slowly selling (\< 10% sold) * Top 10 holds 25-40% ### Red Flags 🔴 * Multiple sniper wallets holding > 20% combined * Large bundler networks (10+ wallets) * Snipers haven't sold (coordinated dump incoming) * Dev wallet transferring to fresh wallets * Insiders holding significant amounts * Top 10 holds > 50% *** ## Practical Examples ### Example 1: Clean Launch ``` Token: $ORGANIC Holders: 2,341 Snipers: 2 (holding 1.2% combined, already sold) Bundlers: 0 Top 10: 18% Dev: 0% (renounced) ``` **Assessment**: Very healthy. Snipers took small positions and exited. No coordination. Organic distribution. ### Example 2: Suspicious Launch ``` Token: $SKETCHY Holders: 892 Snipers: 8 (holding 34% combined, none sold) Bundlers: 12 wallets (holding 22% combined) Top 10: 67% Dev: 5% (no sales) ``` **Assessment**: High risk. Snipers and bundlers control 56% combined and haven't sold. Likely coordinated dump incoming. ### Example 3: Insider Activity ``` Token: $CONNECTED Holders: 1,203 Snipers: 3 (holding 8%) Bundlers: 0 Insiders: 4 (holding 15%, all funded by dev pre-launch) Top 10: 31% Dev: 2% ``` **Assessment**: Medium risk. Insider allocation suggests team/friends got early access. Watch for insider selling patterns. *** ## API Access ### Get Holder Positions with Labels Use the holder-positions endpoint to get holders with their tags (sniper, bundler, insider, etc.): ```bash theme={null} # Get all holder positions for Fartcoin curl -X GET "https://demo-api.mobula.io/api/2/token/holder-positions?blockchain=solana&address=9BB6NFEcjBCtnNLFko2FqVQBq8HHM13kCyYcdQbgpump&limit=50" \ -H "Authorization: YOUR_API_KEY" # Filter by label (snipers only) curl -X GET "https://demo-api.mobula.io/api/2/token/holder-positions?blockchain=solana&address=9BB6NFEcjBCtnNLFko2FqVQBq8HHM13kCyYcdQbgpump&label=sniper" \ -H "Authorization: YOUR_API_KEY" # Filter by label (bundlers only) curl -X GET "https://demo-api.mobula.io/api/2/token/holder-positions?blockchain=solana&address=9BB6NFEcjBCtnNLFko2FqVQBq8HHM13kCyYcdQbgpump&label=bundler" \ -H "Authorization: YOUR_API_KEY" ``` Response: ```json theme={null} { "data": [ { "chainId": "solana:solana", "walletAddress": "7xK9...", "tokenAddress": "9BB6NFEcjBCtnNLFko2FqVQBq8HHM13kCyYcdQbgpump", "tokenAmount": "1000000", "pnlUSD": "5420.50", "buys": 1, "sells": 0, "volumeBuyUSD": "2500.00", "volumeSellUSD": "0", "avgBuyPriceUSD": "0.0025", "labels": ["sniper", "proTrader"], "firstTradeAt": "2024-12-01T00:01:15.000Z" } ] } ``` ### Get Token Details with Holdings Stats For aggregated stats (top 10%, sniper %, bundler %), use token-details: ```bash theme={null} # Get Wojak token details including holder distribution curl -X GET "https://demo-api.mobula.io/api/2/token/details?blockchain=solana&address=8J69rbLTzWWgUJziFY8jeu5tDwEPBwUz4pKBMr5rpump" \ -H "Authorization: YOUR_API_KEY" ``` Response includes: * `top10HoldingsPercentage`, `top50HoldingsPercentage`, `top100HoldingsPercentage` * `devHoldingsPercentage` * `snipersHoldingsPercentage` * `bundlersHoldingsPercentage` * `insidersHoldingsPercentage` ### WebSocket Stream Subscribe to real-time holder updates: ```javascript theme={null} const ws = new WebSocket('wss://general-api-v2.mobula.io'); ws.send(JSON.stringify({ type: 'holders', authorization: 'YOUR_API_KEY', payload: { tokens: [{ address: '9BB6NFEcjBCtnNLFko2FqVQBq8HHM13kCyYcdQbgpump', chainId: 'solana:solana' }] } })); ``` For detailed WebSocket documentation, see [Holders Stream](/indexing-stream/stream/websocket/holders-stream). *** ## Combining Signals The most powerful analysis combines holder tags with other data: ### With Trading Fees High sniper activity + high platform fees = likely bot trading through aggregators like Axiom/GMGN. See [Understanding Trade Fees](/almanac/understanding-trade-fees). ### With Bonding Curve Progress Snipers buying before 50% bonded = trying to get lowest prices. Snipers buying after 80% bonded = anticipating Raydium migration momentum. See [Bonding Curves](/almanac/bonding-curves). ### With Volume Patterns Sudden volume spike + no new snipers = organic interest. Sudden volume spike + new bundler cluster = coordinated pump. *** ## Summary | Tag | Detection Method | Risk Implication | | - | - | - | | **Sniper** | Early blocks + timing analysis | First to dump, watch for sells | | **Bundler** | Cluster analysis + funding traces | Coordinated manipulation | | **Insider** | Deployer connection mapping | Asymmetric information | | **Dev** | Contract deployment tracking | Aligned incentives (monitor) | Understanding these patterns gives you an edge in evaluating whether a token launch is organic or orchestrated. # Pricing Engine Deep Dive Source: https://docs.mobula.io/almanac/pricing-engine How Mobula calculates accurate token prices using weighted averages and outlier filtering # Pricing Engine: Weighted Averages & Outlier Filtering Mobula's pricing engine aggregates price data from hundreds of liquidity pools across multiple chains to compute a single, reliable USD price for every token. This guide explains the mathematics and algorithms behind accurate price discovery. **Why it matters**: A token like WETH might trade at slightly different prices on Uniswap, Sushiswap, Curve, and 50 other DEXs. Our engine combines all these prices into one reliable value, filtering out manipulated pools and scams. ## Overview: The Pricing Pipeline ``` Pool Data Collection → Mode Selection → Outlier Filtering → Weight Calculation → Weighted Average ``` Each step is critical for accuracy: 1. **Pool Data Collection**: Gather price, volume, reserve, and depth from all pools 2. **Mode Selection**: Choose between volume-based or reserve-based weighting 3. **Outlier Filtering**: Remove scam pools and manipulated prices 4. **Weight Calculation**: Apply stable multiplier and depth adjustments 5. **Weighted Average**: Compute final price *** ## Step 1: Pool Data Collection For each pool trading a token, we extract: ```typescript theme={null} interface PoolWeight { price: number; // Token's USD price in this pool normalizedVolume: number; // 24h volume (0 if below threshold) realVolume: number; // Actual 24h volume for metrics reserve: number; // Total liquidity (TVL) depthUp: number; // Buy-side market depth depthDown: number; // Sell-side market depth } ``` **Example**: Token XYZ trading on 4 pools: | Pool | Price | Volume | Reserve | Paired With | | - | - | - | - | - | | Uniswap V3 | \$1.00 | \$5M | \$10M | USDC | | Sushiswap | \$1.02 | \$2M | \$4M | ETH | | PancakeSwap | \$0.98 | \$1M | \$2M | USDT | | ScamDEX | \$0.10 | \$1K | \$10K | ETH | *** ## Step 2: Mode Selection The engine chooses a weighting strategy based on available data: ```typescript theme={null} const computeMode: 'volume' | 'reserve' = totalNormalizedVolume > 0 ? 'volume' : 'reserve'; ``` | Condition | Mode | Weight Source | Use Case | | - | - | - | - | | Any pool has volume > 0 | `volume` | normalizedVolume | Active tokens | | All pools have volume = 0 | `reserve` | reserve (TVL) | New/inactive tokens | **Reserve mode** is a fallback for newly listed or low-activity tokens where volume data isn't reliable. *** ## Step 3: Outlier Filtering (Two-Phase Median) This is the most critical step. It removes: * Scam pools with manipulated prices * Stale pools with outdated prices * Low-liquidity pools with extreme slippage ### Phase 1: Weighted Median Calculation ```typescript theme={null} // Sort prices by value const sortedPrices = prices.sort((a, b) => a - b); // Find weighted median let accumulatedWeight = 0; let medianPrice = 0; for (let i = 0; i < sortedPrices.length; i++) { accumulatedWeight += weights[i]; if (accumulatedWeight >= totalWeight / 2) { medianPrice = sortedPrices[i]; break; } } ``` ### Phase 2: Log-Space Deviation Check ```typescript theme={null} // Calculate deviation in log space (handles multiplicative differences) const logPrice = Math.log(price); const logMedian = Math.log(medianPrice); const deviation = Math.abs(logPrice - logMedian); // Threshold: 10% in volume mode, 15% in reserve mode (more permissive) const threshold = computeMode === 'reserve' ? BASE_THRESHOLD * 1.5 : BASE_THRESHOLD; const isOutlier = deviation > threshold; ``` **Why log space?** * A price of $0.50 vs $1.00 (50% lower) should be treated the same as $2.00 vs $1.00 (100% higher) * Log space makes these symmetric: `log(0.5) = -0.69`, `log(2) = 0.69` ### Filtering Result After filtering our example: | Pool | Price | Status | | - | - | - | | Uniswap V3 | \$1.00 | ✅ Valid (near median) | | Sushiswap | \$1.02 | ✅ Valid (2% deviation) | | PancakeSwap | \$0.98 | ✅ Valid (2% deviation) | | ScamDEX | \$0.10 | ❌ Outlier (90% deviation) | *** ## Step 4: Weight Calculation ### Stable Multiplier Pools paired with stablecoins provide more reliable pricing than pools paired with volatile assets: ```typescript theme={null} const STABLE_MULTIPLIER = 3; let weight = normalizedVolume; // Non-stable pairs get boosted weight to compensate for their // typically lower volume but higher price accuracy if (!baseQuote.isStableCoin({ chainId, address })) { weight *= STABLE_MULTIPLIER; } ``` **Why boost non-stable pairs?** * Stable-paired pools (USDC, USDT) give direct USD prices * ETH-paired pools require ETH→USD conversion, introducing small errors * But ETH pairs often have MORE volume, so we boost stable pairs to balance ### Depth Weighting (Optional) When `ponderWithDepth = true`: ```typescript theme={null} if (ponderWithDepth) { const depth = depthUp + depthDown; weight = depth > 0 ? normalizedVolume * depth : normalizedVolume; } ``` This prioritizes pools where large trades can execute with minimal slippage. ### Final Weights Example | Pool | Volume | Paired | Multiplier | Final Weight | | - | - | - | - | - | | Uniswap V3 | \$5M | USDC | ×1 | \$5M | | Sushiswap | \$2M | ETH | ×3 | \$6M | | PancakeSwap | \$1M | USDT | ×1 | \$1M | *** ## Step 5: Weighted Average The final price is computed as: ```typescript theme={null} function computeWeightedMean( prices: number[], weights: number[], count: number ): [number, number] { let weightedSum = 0; let totalWeight = 0; for (let i = 0; i < count; i++) { weightedSum += prices[i] * weights[i]; totalWeight += weights[i]; } const price = weightedSum / totalWeight; return [price, totalWeight]; } ``` ### Example Calculation ``` numerator = (1.00 × 5M) + (1.02 × 6M) + (0.98 × 1M) = 5M + 6.12M + 0.98M = 12.1M denominator = 5M + 6M + 1M = 12M finalPrice = 12.1M / 12M = $1.0083 ``` *** ## Asset-Level Pricing For tokens deployed on multiple chains, we aggregate token prices into a single **asset price**. ### Why Aggregate? The same token can have different prices on different chains due to: * Bridge delays and costs * Chain-specific liquidity * Arbitrage opportunities ### Aggregation Algorithm ```typescript theme={null} computeAssetPrice(tokenResults: Map) { const count = tokenResults.size; if (count === 0) return null; // Determine weighting mode let totalVolume = 0; let totalReserve = 0; for (const data of tokenResults.values()) { totalVolume += data.volume; totalReserve += data.reserve; } const useVolume = totalVolume > 0; const total = useVolume ? totalVolume : totalReserve; // Filter by threshold (1% minimum share) const VOLUME_THRESHOLD = 0.01; const validTokens = []; for (const data of tokenResults.values()) { const share = useVolume ? data.volume / total : data.reserve / total; if (share >= VOLUME_THRESHOLD) { validTokens.push(data); } } // Weighted average return computeWeightedMean( validTokens.map(t => t.price), validTokens.map(t => useVolume ? t.volume : t.reserve), validTokens.length ); } ``` ### Example: USDT Asset Price | Chain | Token Price | Volume | Share | | - | - | - | - | | Ethereum | \$1.001 | \$500M | 89.3% | | BSC | \$0.999 | \$50M | 8.9% | | Polygon | \$1.000 | \$10M | 1.8% | | Obscure Chain | \$0.50 | \$100 | 0.00002% ← Filtered | ``` assetPrice = (1.001×500M + 0.999×50M + 1.000×10M) / 560M = $1.0008 ``` *** ## Outlier Detection for Assets When aggregating across chains, we also filter token-level outliers: ```typescript theme={null} const ASSET_TOKEN_OUTLIER_THRESHOLD = 2.0; // 200% deviation for (const token of filteredTokens) { const priceDeviation = Math.abs(token.price - assetPrice) / assetPrice; if (priceDeviation > ASSET_TOKEN_OUTLIER_THRESHOLD) { outlierTokens.push(token); continue; } validTokens.push(token); } // Re-compute price without outliers if (outlierTokens.length > 0 && validTokens.length > 0) { return computeWeightedMean(validTokens); } ``` *** ## Performance Optimizations ### Pre-allocated Buffers ```typescript theme={null} // Avoid allocations in hot path private readonly priceBuffer: Float64Array; private readonly weightBuffer: Float64Array; private readonly logPriceBuffer: Float64Array; constructor(maxPoolsPerToken = 256) { this.priceBuffer = new Float64Array(maxPoolsPerToken); this.weightBuffer = new Float64Array(maxPoolsPerToken); this.logPriceBuffer = new Float64Array(maxPoolsPerToken); } ``` ### Selector Caching ```typescript theme={null} private readonly selectorCache: Map; private parseSelectorCached(selector: SelectorStr) { let cached = this.selectorCache.get(selector); if (!cached) { cached = parseSelector(selector); if (this.selectorCache.size < 1000) { this.selectorCache.set(selector, cached); } } return cached; } ``` *** ## Validation & Safety ### Price Bounds ```typescript theme={null} const INSANE_PRICE_THRESHOLD = 1e15; // $1 quadrillion isValidPrice(price: number): boolean { return price > 0 && price < INSANE_PRICE_THRESHOLD && Number.isFinite(price); } ``` ### Minimum Valid Prices ```typescript theme={null} const MIN_VALID_PRICES = 2; // Require at least 2 valid pools for reliable pricing if (validIndices.length < MIN_VALID_PRICES) { return null; } ``` *** ## API Access ### Token Price ```bash theme={null} # Get price for Fartcoin on Solana curl -X GET "https://demo-api.mobula.io/api/2/token/details?blockchain=solana&address=9BB6NFEcjBCtnNLFko2FqVQBq8HHM13kCyYcdQbgpump" \ -H "Authorization: YOUR_API_KEY" # Get price for Wojak on Solana curl -X GET "https://demo-api.mobula.io/api/2/token/details?blockchain=solana&address=8J69rbLTzWWgUJziFY8jeu5tDwEPBwUz4pKBMr5rpump" \ -H "Authorization: YOUR_API_KEY" # Get WETH price on Ethereum curl -X GET "https://demo-api.mobula.io/api/2/token/details?blockchain=ethereum&address=0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" \ -H "Authorization: YOUR_API_KEY" ``` Response includes: ```json theme={null} { "data": { "priceUSD": 0.0234, "volume24hUSD": 890000.50, "liquidityUSD": 250000.75, "priceChange24hPercentage": -5.8, "approximateReserveUSD": 125000.50 } } ``` ### Real-Time Updates For real-time price updates, use the [WSS Token Details](/indexing-stream/stream/websocket/wss-token-details) WebSocket stream. *** ## Summary | Step | Purpose | Key Technique | | - | - | - | | Data Collection | Gather all pool data | Multi-DEX aggregation | | Mode Selection | Choose weighting strategy | Volume vs Reserve fallback | | Outlier Filtering | Remove manipulated prices | Two-phase log-space median | | Weight Calculation | Prioritize reliable sources | Stable multiplier (×3) | | Weighted Average | Compute final price | Σ(price × weight) / Σweight | The result: **accurate, manipulation-resistant prices** updated in real-time across 100+ blockchains. # How to Integrate ApeStore on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/apestore Complete ApeStore integration guide for Robinhood Chain: contracts, ABI, Uniswap V3 pricing, liquidity tracking, market cap bonding progress, migration, and token metadata. # ApeStore Launchpad Integration on Robinhood Chain Learn how to index and integrate the ApeStore launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. Integrate ApeStore launches and their concentrated-liquidity markets on Robinhood Chain. This guide describes the public contract surface for an independent integration. ## Network and contracts Unless another chain is listed, these addresses are for Robinhood Chain (`chainId 4663`). Verify proxy implementations and mutable configuration at the indexed block. | Role | Address | | - | - | | ApeStore launcher | `0x6e4910ea5a04376032f6564da9a9e4e88b7a87c1` | | Concentrated-liquidity factory | `0x1f7d7550b1b028f7571e69a784071f0205fd2efa` | | WETH | `0x0bd7d308f8e1639fab988df18a8011f41eacad73` | ## Market discovery and ABI ApeStore creates a Uniswap V3-compatible WETH pair. Discover a launch from the launcher transaction and the `PoolCreated(token0, token1, fee, tickSpacing, pool)` event emitted by the concentrated-liquidity factory. Confirm the launcher transaction contains the token and that the resulting pool reports the expected factory, `token0`, and `token1`. ### Relevant ABI ```solidity theme={null} event PoolCreated(address indexed token0, address indexed token1, uint24 indexed fee, int24 tickSpacing, address pool); function token0() view returns (address); function token1() view returns (address); function factory() view returns (address); function slot0() view returns (uint160 sqrtPriceX96, int24 tick, uint16, uint16, uint16, uint8, bool); event Swap(address indexed sender,address indexed recipient,int256 amount0,int256 amount1,uint160 sqrtPriceX96,uint128 liquidity,int24 tick); ``` ## Launchpad architecture and AMM model ApeStore is a token launchpad built on top of Uniswap v3-style concentrated-liquidity markets. The underlying AMM provides trading and liquidity mechanics; ApeStore adds launch attribution, token discovery, metadata, and market-cap-based completion semantics. **Classification: Uniswap v3-like.** The market exposes the standard V3 pool surface: `token0`, `token1`, `slot0`, concentrated liquidity, signed swap deltas, ticks, and `Mint`/`Burn`/`Collect` events. The difference is launch attribution and completion: the ApeStore launcher identifies eligible pools, while progress is market-cap based and does not trigger a pool migration. **Shared with V3:** square-root pricing, tick-based liquidity, position ranges, and pool event semantics. **Protocol-specific:** launcher verification, metadata discovery, and the `$69,000` completion rule. ## Price calculation Use the V3 square-root price: `raw(token1/token0) = sqrtPriceX96² / 2¹⁹²`. Apply `10^(decimals0-decimals1)`. Invert only when requesting `token0/token1`; never reorder the pool. ## Liquidity tracking Track `Mint`, `Burn`, `Collect`, `Swap`, and `Flash`. For token balances, use pool balances at a fixed block or reconstruct signed event deltas. V3 active liquidity is not itself token TVL; convert liquidity across tick ranges or value actual balances. ## Launchpad state, bonding, and migration The market remains in the same concentrated-liquidity pool. Progress is market-cap based, with a launch target of `$69,000`: `progress = clamp(marketCapUSD / 69,000 × 100)`. Mark completion only when the target is reached according to the same quote-price snapshot used for market cap. ## Metadata Read ERC-20 `name()`, `symbol()`, `decimals()`, and `totalSupply()`. The launch transaction is the authoritative association between the launcher and pool; do not classify every pool from the same V3 factory as ApeStore. ## Indexing checklist 1. Index creation and bind the launched token to its canonical market. 2. Preserve on-chain token/currency order exactly. 3. Replay logs in block, transaction, and log-index order. 4. Keep raw integers until decimals are applied. 5. Treat graduation as protocol state, not a generic price shortcut. ## Historical indexing notes Use block-scoped reads when initializing historical state. Do not mix `latest` reads into an old-block replay. Store launched-token identity separately from native pool ordering. ## Related Robinhood Chain launchpad integrations * [Bottom.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/bottomfun) * [Hood.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/hoodfun) * [Pons launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/pons) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate Bottom.fun on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/bottomfun Complete Bottom.fun integration guide for Robinhood Chain: contracts, ABI, Uniswap V4 pricing, liquidity tracking, hook bonding curve graduation, migration, and token metadata. # Bottom.fun Launchpad Integration on Robinhood Chain Learn how to index and integrate the Bottom.fun launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. Integrate Bottom.fun Uniswap v4 hook pools, curve progress, graduation, and metadata. This guide describes the public contract surface for an independent integration. ## Network and contracts Unless another chain is listed, these addresses are for Robinhood Chain (`chainId 4663`). Verify proxy implementations and mutable configuration at the indexed block. | Role | Address | | - | - | | Factory | `0x1bed2687321074a198302c004036b51923812b18` | | Hook | `0xd23c94bd8cbeb48c169c020e16a844aeab2368cc` | | Locker | `0xf46663171d1d0653fe7c3b8e42d43bccac137c56` | | WETH | `0x0bd7d308f8e1639fab988df18a8011f41eacad73` | ## Market discovery and ABI The market is a Uniswap v4 pool identified by `PoolId`, not a pool contract address. Accept only pool keys whose `hooks` field equals the Bottom.fun hook. Resolve the pool key from the locker and preserve `currency0/currency1` order. ### Relevant ABI ```solidity theme={null} event CurveSwap(bytes32 indexed poolId,address indexed trader,bool isBuy,uint256 amountIn,uint256 amountOut,uint160 sqrtPriceX96,uint24 feeBps,address referrer); event Graduated(bytes32 indexed poolId,address indexed token,uint256 quoteRaised,uint256 blockNumber); function graduationQuote() view returns (uint256); function poolState(bytes32 id) view returns (uint8 phase,uint256 quoteRaised,uint24 feeBps,uint256 launchBlock); function pools(bytes32 id) view returns (address token,bool tokenIs0,uint8 phase,uint64 launchBlock,uint128 quoteRaised); function poolKeys(bytes32 id) view returns (address currency0,address currency1,uint24 fee,int24 tickSpacing,address hooks); function launches(address token) view returns (address token,address creator,bytes32 poolId,bytes32 socialClaimId,uint64 launchBlock,address factory,string metadataURI); ``` ## Launchpad architecture and AMM model Bottom.fun is a token launchpad built on top of Uniswap v4. PoolManager provides the shared AMM and concentrated-liquidity engine, while the Bottom.fun hook, factory, registry, and locker add launch creation, curve accounting, fees, metadata, and graduation. **Classification: Uniswap v4-like with a custom hook.** The market is a PoolManager `PoolId`/`PoolKey`, uses `currency0`, `currency1`, `sqrtPriceX96`, ticks, and `ModifyLiquidity`. Unlike a plain v4 pool, the Bottom.fun hook emits `CurveSwap`, owns curve phase and quote-raised state, and emits an explicit graduation event. **Shared with V4:** singleton PoolManager identity, PoolKey ordering, square-root pricing, hooks, and concentrated liquidity. **Protocol-specific:** factory/registry/locker wiring, hook-level swap accounting, `phase`, `quoteRaised`, and `graduationQuote`. ## Price calculation Use `sqrtPriceX96` from `CurveSwap` or PoolManager state with the Uniswap v4 formula `currency1/currency0 = sqrtPriceX96² / 2¹⁹²`, followed by decimal adjustment. Determine whether the launched token is currency0 from `tokenIs0`. ## Liquidity tracking Before graduation, update quote raised and token/quote flows from each `CurveSwap`. Track PoolManager `ModifyLiquidity` for the v4 position. Do not treat the v4 liquidity scalar as reserves; derive token amounts from the current price and tick range. ## Launchpad state, bonding, and migration Read `graduationQuote()` instead of assuming a constant. While `phase < 2`, `progress = clamp(quoteRaised / graduationQuote × 100)`. `phase >= 2` or `Graduated` means bonded. Buys add to `quoteRaised`; sells must subtract according to emitted quote flow. ## Metadata Resolve the registry with `factory.registry()`, then read `launches(token).metadataURI`. Fetch JSON from HTTPS/IPFS and map `name`, `symbol`, `image`, `description`, `website`, `twitter`, and `telegram`; use ERC-20 fields as fallback. ## Indexing checklist 1. Index creation and bind the launched token to its canonical market. 2. Preserve on-chain token/currency order exactly. 3. Replay logs in block, transaction, and log-index order. 4. Keep raw integers until decimals are applied. 5. Treat graduation as protocol state, not a generic price shortcut. ## Historical indexing notes Use block-scoped reads when initializing historical state. Do not mix `latest` reads into an old-block replay. Store launched-token identity separately from native pool ordering. ## Related Robinhood Chain launchpad integrations * [Bow.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/bowfun) * [Klik launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/klik) * [RobinFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/robinfun) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate Bow.fun on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/bowfun Complete Bow.fun integration guide for Robinhood Chain: contracts, ABI, Uniswap V3 pricing, liquidity tracking, PancakeSwap V3 graduation, migration, and token metadata. # Bow\.fun Launchpad Integration on Robinhood Chain Learn how to index and integrate the Bow\.fun launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. ## Network and contracts | Role | Address | | - | - | | Bow factory | `0xc70e510e14710ea535cab7b2414860af63feab79` | | Robinhood V3 factory | `0x1f7d7550b1b028f7571e69a784071f0205fd2efa` | | Pancake V3 factory | `0x0bfbcf9fa4f9c56b0f40a671ad40e0805a091865` | | WETH | `0x0bd7d308f8e1639fab988df18a8011f41eacad73` | ## Market discovery and ABI ### Relevant ABI ```solidity theme={null} event Launched(address indexed token,address indexed deployer,address pool,uint256 positionId,uint256 launchId); function pool() view returns (address); function migrated() view returns (bool); function GRADUATION_WETH() view returns (uint256); function imageUrl() view returns (string); function metadata() view returns (string); function context() view returns (string); function deployerOf(address token) view returns (address); ``` Verify pool factory/token0/token1 and index V3 or Pancake V3 `Swap`, `Mint`, `Burn`, `Collect`, and `Flash`. ## Launchpad architecture and AMM model Bow\.fun is a token launchpad built on top of Uniswap v3-compatible concentrated-liquidity pools, including PancakeSwap V3 deployments. The V3 pool handles trading; Bow adds token deployment, launch ownership, metadata, graduation accounting, and migration state. **Classification: Uniswap v3-like, with support for both a V3-compatible factory and PancakeSwap V3.** Pools use `sqrtPriceX96`, ticks, positions, and standard concentrated-liquidity events. Bow adds a launch token contract that exposes the pool, metadata, migration flag, and WETH graduation target. **Shared with V3:** pool token order, signed swap deltas, tick math, and liquidity-position accounting. **Protocol-specific:** `Launched`, token-level `pool()`/`migrated()`, `GRADUATION_WETH()`, and token-contract metadata. ## Price calculation Use V3 `sqrtPriceX96`, decimal adjustment, and actual token order. Signed swap amounts are pool deltas; orient display prices without reordering state. ## Liquidity tracking Reconstruct pool balances from signed events or block-scoped balances. Convert concentrated position liquidity through tick bounds for position amounts. ## Launchpad state, bonding, and migration Read `GRADUATION_WETH()` dynamically and compare it with the protocol WETH progress quantity. `migrated()` is authoritative completion. Never use a hardcoded threshold. ## Metadata Read `imageUrl()`, `metadata()`, and `context()` from the launched token plus `deployerOf(token)`. Accept inline JSON, URI JSON, IPFS and Arweave, then merge ERC-20 fields. ## Related Robinhood Chain launchpad integrations * [DYOR.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/dyorfun) * [Long.xyz launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/longxyz) * [Printr launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/printr) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate DYOR.fun on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/dyorfun Complete DYOR.fun integration guide for Robinhood Chain: contracts, ABI, Uniswap V3 pricing, liquidity tracking, bonding progress graduation, migration, and token metadata. # DYOR.fun Launchpad Integration on Robinhood Chain Learn how to index and integrate the DYOR.fun launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. DYOR.fun is a permissionless launchpad whose tokens trade in concentrated-liquidity pools. > Protocol reference: [DYOR Fun developer documentation](https://dyorv3.org/docs) ## Network and contracts | Role | Robinhood Chain address | | - | - | | Launch factory | `0x80b42aed46d73f47119dc444bea28a9e68f32bf4` | | V3 factory | `0x1f7d7550b1b028f7571e69a784071f0205fd2efa` | | WETH | `0x0bd7d308f8e1639fab988df18a8011f41eacad73` | ## Market discovery and ABI Use `TokenLaunched` or `getLaunchedToken(token)` to bind token, pair, pool, fee, position and metadata. Verify the exact V3 pool for the returned pair and fee and preserve `token0/token1`. ### Relevant ABI ```solidity theme={null} event TokenLaunched(address token,address deployer,address dexFactory,address pairToken,address pool,uint256 positionId,uint256 restrictionsEndBlock,uint256 initialBuyAmount,string metadataURI,address feeRecipient); event Graduated(address token,uint256 liquidityEth); function getLaunchedToken(address token) view returns (address token,address deployer,address pairedToken,address positionManager,uint256 positionId,uint256 restrictionsEndBlock,uint256 supply,bool isToken0,uint24 poolFee,bool exists,uint256 initialBuyAmount,address pool,address feeRecipient,string metadataURI); function graduated(address token) view returns (bool); function graduationLiquidityEth() view returns (uint256); function graduationProgressBps(address token) view returns (uint256); function liquidityEth(address token) view returns (uint256); ``` Also index V3 `Swap`, `Mint`, `Burn`, `Collect`, and `Flash`. ## Launchpad architecture and AMM model DYOR.fun is a token launchpad built on top of Uniswap v3-style pools. Uniswap-compatible contracts provide price discovery and concentrated liquidity, while the DYOR launch factory adds token configuration, restrictions, metadata, progress accounting, and graduation. **Classification: Uniswap v3-like with launchpad accounting layered over the V3 pool.** Trading and liquidity follow V3 semantics, while the launch factory records the token, position, pool fee, restrictions, ETH liquidity, progress, and graduation. **Shared with V3:** `sqrtPriceX96`, token0/token1, ticks, signed swaps, and `Mint`/`Burn`/`Collect`. **Protocol-specific:** launch records, `liquidityEth`, progress basis points, configurable graduation liquidity, restrictions, and `Graduated`. ## Price calculation Compute `token1/token0 = sqrtPriceX96² / 2¹⁹²`, then apply `10^(decimals0-decimals1)`. Use `isToken0` only to orient the launched-token display price; never reorder the pool. ## Liquidity tracking `liquidityEth(token)` is protocol progress liquidity. Track V3 events and pool balances separately for market TVL. The V3 liquidity scalar is not an ETH reserve. ## Launchpad state, bonding, and migration Use `graduated(token)` and `Graduated` as terminal state. Active progress is `graduationProgressBps(token) / 100` percent. Read `graduationLiquidityEth()` dynamically; do not hardcode its historical 4.5 WETH value. ## Metadata Fetch `metadataURI` from the launch record. Support inline JSON, HTTPS, IPFS, and Arweave; map image, description, website, X/Twitter, and Telegram. Fall back to ERC-20 fields. ## Historical indexing notes Use block-scoped reads, replay events in canonical log order, and never mix `latest` state into historical replay. ## Related Robinhood Chain launchpad integrations * [Hood.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/hoodfun) * [Pons launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/pons) * [NoxaFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/noxafun) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate Hood.fun on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/hoodfun Complete Hood.fun integration guide for Robinhood Chain: contracts, ABI, bonding curve and Uniswap V3 pricing, liquidity tracking, token migration, migration, and token metadata. # Hood.fun Launchpad Integration on Robinhood Chain Learn how to index and integrate the Hood.fun launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. ## Network and contracts | Role | Address | | - | - | | Launchpad | `0x5fcc1df0dc020cf454e742e9a8ae2554c37a452c` | | Platform | `0xc6a2941b962fb667786d7f4b97f7f965d6f0a4f8` | | V3 factory | `0x1f7d7550b1b028f7571e69a784071f0205fd2efa` | | WETH | `0x0bd7d308f8e1639fab988df18a8011f41eacad73` | ## Market discovery and ABI Index the token curve first and attach the migrated V3 pool only after its explicit graduation link. ### Relevant ABI ```solidity theme={null} event TokenCreated(address indexed token,address indexed creator,string name,string symbol,string metadataURI,uint256 virtualEth,uint256 curveSupply); event Trade(address indexed token,address indexed trader,bool isBuy,uint256 ethAmount,uint256 tokenAmount,uint256 newRealEth,uint256 newRealTokens); event Graduated(address indexed token,address indexed pool,uint256 liquidityEth,uint256 liquidityTokens); function curves(address token) view returns (uint256 virtualEth,uint256 virtualTokens,uint256 realEth,uint256 realTokens,uint256 tradeFeeBps,bool readyToGraduate,bool graduated,bool migrated,address creator); function currentPrice(address token) view returns (uint256); function isHoodToken(address token) view returns (bool); ``` ## Launchpad architecture and AMM model Hood.fun is a launchpad with its own bonding-curve phase followed by a Uniswap v3-style market. The custom curve bootstraps the token and measures graduation; after graduation, the linked V3 pool becomes the trading and liquidity venue. **Classification: custom bonding curve before graduation, then Uniswap v3-like.** The active curve uses virtual/real ETH and token reserves plus protocol `Trade` events; it is not a V3 pool and must not use tick or `sqrtPriceX96` math. After migration, the linked pool follows V3 concentrated-liquidity semantics. **Shared with V3 after migration:** token0/token1, square-root price, ticks, signed swaps, and liquidity positions. **Protocol-specific before migration:** virtual reserves, `currentPrice`, trade-fee basis points, readiness/graduation flags, and the explicit curve-to-pool link. ## Price calculation Before migration use `currentPrice(token)`, scaled by 1e18, or the full virtual-reserve invariant. After migration use V3 `sqrtPriceX96` with decimals in exact pool order. ## Liquidity tracking Expose virtual reserves for pricing separately from real ETH/token liquidity. Apply every `Trade` post-state. After migration track the linked V3 pool without deleting curve history. ## Launchpad state, bonding, and migration Use contract progress basis points divided by 100. `readyToGraduate` is pending; `graduated`, `migrated`, or the explicitly linked migrated pool is terminal. Do not classify an unrelated V3 pool. ## Metadata `TokenCreated` contains name, symbol and `metadataURI`. Parse inline JSON or URI JSON and retain logo, description, website, X/Twitter, Telegram and creator. ## Related Robinhood Chain launchpad integrations * [Klik launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/klik) * [RobinFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/robinfun) * [RealFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/realfun) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate Klik on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/klik Complete Klik integration guide for Robinhood Chain: contracts, ABI, Uniswap V4 pricing, liquidity tracking, dynamic fee hook, migration, and token metadata. # Klik Launchpad Integration on Robinhood Chain Learn how to index and integrate the Klik launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. > Protocol reference: [Klik developer documentation](https://klik.finance/docs) ## Network and contracts | Chain | ID | Factory | Hook | | - | -: | - | - | | Ethereum | 1 | `0x254Bf550657040f78608476cE9AaD820aB2266ad` | Read from PoolKey | | Base | 8453 | `0xB6CB1c049ee8942683Fd3172f7EBA63B6e8a6835` | `0x487f034772b128e917b23a4edfd53442aa8de0cc` | | Robinhood | 4663 | `0x16cF6788B762EE8969744586eD16fc5705140dd7` | `0x745d717620052a97a22deee2e5eba59583f3e0cc` | ## Market discovery and ABI Discover PoolIds from PoolManager `Initialize`; verify the chain hook and factory registration. Preserve PoolKey currency order. ### Relevant ABI ```solidity theme={null} function tokenInfoByAddress(address token) view returns (address tokenAddress,string name,string symbol,address deployer,uint256 time,string metadata,uint256 marketCapInETH,uint256 totalFeesGenerated); function deployCoin(string name,string symbol,string metadataUri,bytes32 salt,...) returns (address token); function collectFees(address tokenAddress) returns (uint256 ethCollected); ``` Index PoolManager `Initialize`, `Swap`, and `ModifyLiquidity`. ## Launchpad architecture and AMM model Klik is a token launchpad built on top of Uniswap v4. PoolManager supplies the AMM, while the Klik hook and factory add atomic token deployment, dynamic launch fees, creator revenue, metadata registration, and inventory-based launch progress. **Classification: Uniswap v4-like with a Klik hook.** Markets are PoolManager PoolIds and use standard PoolKeys, square-root pricing, ticks, swaps, and liquidity modification. The hook adds dynamic fees and creator/platform fee routing; Klik also treats consumption of the seeded token inventory as launch progress without migrating pools. **Shared with V4:** singleton PoolManager, currency ordering, hook address in PoolKey, `sqrtPriceX96`, and `ModifyLiquidity`. **Protocol-specific:** chain-specific factory/hook verification, dynamic fee schedule, 1-billion-token seeded inventory, creator fees, and metadata registration. ## Price calculation Use `currency1/currency0 = sqrtPriceX96² / 2¹⁹²`, adjusted for decimals. Dynamic hook fees affect execution amounts, not the square-root spot-price definition. ## Liquidity tracking Track PoolManager liquidity deltas by PoolId and convert position liquidity to currency amounts using current sqrt price and ticks. Do not treat liquidity `L` as reserve balances. ## Launchpad state, bonding, and migration Klik seeds 1,000,000,000 tokens and does not migrate. `progress = clamp((initialSupply - launchedTokenReserve) / initialSupply × 100)`. Sells return tokens and reduce progress. ## Metadata Read `tokenInfoByAddress(token).metadata`, normalize HTTPS/IPFS, and parse name, symbol, description, image, website, Twitter and Telegram. ## Related Robinhood Chain launchpad integrations * [Long.xyz launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/longxyz) * [Printr launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/printr) * [ApeStore launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/apestore) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate LaunchProof on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/launchproof LaunchProof integration guide for Robinhood Chain: Uniswap Liquidity Launcher attribution, Instant and Crowd launches, V4 pricing, liquidity, bonding state, and token metadata. # LaunchProof Integration on Robinhood Chain LaunchProof is a frontend and attribution layer over the official Uniswap Liquidity Launcher on Robinhood Chain. Its pools use the same Uniswap V4 PoolManager and launch strategies as launches created by other frontends, so contract addresses alone do not prove LaunchProof provenance. ## Network and contracts | Role | Robinhood Chain address | | - | - | | Current LiquidityLauncher | `0x0000FffFBE8efE702c8703aE3477FF5dE3d319C0` | | Current Instant strategy, creator fees | `0x23f8209572b4a1C2AD88A42749E830791Fb027f1` | | Current Instant strategy, no creator fees | `0xAD44D55E7f8337C3cE113fBb591486E85be104b2` | | LBP strategy used by Crowd launches | `0x05d552391067389EE44fec3924157ed33F976000` | | UERC20 token factory | `0x000000e200088D55C39a11F609E5F667729ad49b` | | CCA factory | `0x000000001F26a0044BaA66024e7b6599c61963F8` | | Uniswap V4 PoolManager | `0x8366a39cc670b4001a1121b8f6a443a643e40951` | Treat these addresses as discovery boundaries, not attribution proof. The Instant and LBP strategies are shared official Uniswap deployments. Consume the append-only `INSTANT_LAUNCH_DEPLOYMENTS` registry from `@uniswap/liquidity-launcher-sdk`; never replace historical strategy rows when Uniswap redeploys the current stack. Validate each `TokenDistributed` event against that strategy's immutable `launcher()` value, because historical strategies remain pinned to their historical launcher. ## Attribution Read the token's immutable public UERC20 `metadata()` value. Batch that call with `name()`, `symbol()`, `decimals()`, and `totalSupply()` through Multicall3. A launch belongs to LaunchProof when its metadata contains either: * the exact description suffix `Launched through Uniswap via launchproof.fun`; or * an `xVerificationToken` in the JSON `extraData` field, using the same token shape accepted by the LaunchProof frontend. Fail closed when the immutable metadata cannot be read or neither marker is present. This prevents all Robinhood Uniswap Launcher pools from being mislabeled as LaunchProof without scanning historical logs during pool resolution or extraction. ## Pool discovery and ordering Instant launches emit `TokenLaunched`; Crowd launches emit `Migrated` only when their auction graduates into the final V4 market. Validate the registered strategy and the corresponding distribution or auction state before claiming the shared event. Always derive token0 and token1 from the emitted or recovered Uniswap V4 `PoolKey`. Native currency is normalized from the V4 zero address to the chain-native sentinel. Never reorder the pair based on which token was launched: LaunchProof and generic Uniswap V4 resolution must produce the same ordering so historical pool-type backfills cannot invert price or reserves. ## Price and liquidity LaunchProof inherits the canonical Uniswap V4 state model. Read `sqrtPriceX96`, active liquidity, ticks, positions, and reserves through the existing V4 implementation. Compute the raw token1/token0 ratio as: `sqrtPriceX96^2 / 2^192` Apply the token decimal adjustment once, and invert only for the requested display pair. Preserve reserve0 and reserve1 in PoolKey order. Swap handling must use the same V4 event decoder and hook-aware reserve logic as generic Uniswap V4 pools. ## Bonding state An Instant launch enters its final V4 pool immediately. In Mobula's launchpad fields it is represented as `bonded: false` and `bondingPercentage: 0`; these values describe the absence of a completed Crowd auction, not an active AMM bonding curve. A Crowd auction is not indexed as a swappable AMM pool before migration. Once `Migrated` creates the final V4 pool, represent it as `bonded: true` and `bondingPercentage: 100`. There is no intermediate percentage to infer from the post-migration V4 pool. ## Metadata and backfills Use the immutable UERC20 metadata for logo, description, website, and social links. Read it in the same Multicall3 request as the standard ERC-20 metadata. The original launch receipt remains a fallback for older compatible token contracts that do not expose `metadata()`. During a historical backfill, classify LaunchProof before generic Uniswap Launcher, then persist the resolved pool type, token source, canonical V4 state, launch extras, bonding fields, and token metadata together. Keep the shared strategy factory rows unchanged because non-LaunchProof launches can use those same contracts. For a cold PoolManager swap, enable the fail-closed launchpad resolver only on chains where the corresponding launcher registry is deployed. Do not derive that decision from an empty protocol filter: an empty filter means all protocols. Emit a structured, counted alert whenever no exact launchpad resolver can classify the pool, and backfill the missing canonical pool before replaying its swaps. # How to Integrate Long.xyz on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/longxyz Complete Long.xyz integration guide for Robinhood Chain: contracts, ABI, Uniswap V4 pricing, liquidity tracking, Airlock launch epochs, migration, and token metadata. # Long.xyz Launchpad Integration on Robinhood Chain Learn how to index and integrate the Long.xyz launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. ## Network and contracts | Role | Address | | - | - | | Factory | `0x22e99278308b393ea1260859b181ad7e78f5eeed` | | Airlock | `0xeb7c034704ef8dcd2d32324c1545f62fb4ad0862` | ## Market discovery and ABI Confirm token ownership by Airlock, resolve asset data, and verify numeraire, pool initializer/hook and PoolId against the v4 PoolKey. ### Relevant ABI ```solidity theme={null} function owner() view returns (address); function getAssetData(address asset) view returns (address numeraire,address timelock,address governance,address liquidityMigrator,address poolInitializer,address pool); function tokenURI() view returns (string); event Created(address indexed asset,address hook,address creator,bytes32 poolId,uint256 epochStart,uint256 epochEnd,string name); ``` ## Launchpad architecture and AMM model Long.xyz is a token launchpad built on top of Uniswap v4 and an Airlock deployment system. Uniswap v4 supplies pool execution and concentrated liquidity; Long.xyz adds asset ownership, pool initialization, numeraire selection, launch epochs, and time-based completion. **Classification: Uniswap v4-like, initialized through an Airlock-controlled hook.** The market uses a PoolId/PoolKey, v4 square-root pricing, ticks, swaps, and liquidity modifications. Long.xyz adds Airlock asset ownership, numeraire and initializer verification, plus a time-defined launch epoch. **Shared with V4:** PoolManager identity, exact currency order, hook-based execution, `sqrtPriceX96`, and concentrated liquidity. **Protocol-specific:** Airlock asset data, factory creation record, numeraire, epoch start/end, and time-based completion rather than reserve-based bonding. ## Price calculation Use v4 `sqrtPriceX96` in native PoolKey order with decimals. Identify the launched asset through Airlock; never force it into currency0. ## Liquidity tracking Track `Swap` and `ModifyLiquidity` by PoolId. Convert liquidity to token amounts with current price and tick boundaries; the numeraire is the quote asset. ## Launchpad state, bonding, and migration Progress is time based: `clamp((blockTimestamp - epochStart) / (epochEnd - epochStart) × 100)`. Completion occurs at `epochEnd`; use block timestamps for historical state. ## Metadata Read ERC-20 fields and `tokenURI()`. Resolve HTTPS/IPFS JSON. The creation event also provides creator, name and epoch boundaries. ## Related Robinhood Chain launchpad integrations * [Pons launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/pons) * [NoxaFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/noxafun) * [Bottom.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/bottomfun) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate NoxaFun on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/noxafun Complete NoxaFun integration guide for Robinhood Chain: contracts, ABI, Uniswap V3 pricing, liquidity tracking, bonding curve progress, migration, and token metadata. # NoxaFun Launchpad Integration on Robinhood Chain Learn how to index and integrate the NoxaFun launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. ## Network and contracts | Role | Address | | - | - | | Launch factory | `0xd9ec2db5f3d1b236843925949fe5bd8a3836fccb` | ## Market discovery and ABI Resolve the launch, DEX config and launch config, then verify the exact V3 pool and preserve its token order. ### Relevant ABI ```solidity theme={null} event TokenLaunched(address indexed token,address indexed deployer,address indexed dexFactory,address pairToken,address pool,uint256 dexId,uint256 launchConfigId,uint256 positionId,uint256 restrictionsEndBlock,uint256 initialBuyAmount); function getLaunchedToken(address token) view returns (address token,address deployer,address pairedToken,address positionManager,uint256 positionId,uint256 dexId,uint256 launchConfigId,uint256 restrictionsEndBlock,uint256 supply,bool isToken0,uint24 poolFee,bool exists,uint256 initialBuyAmount); function getDexConfig(uint256 dexId) view returns (string name,address factory,address positionManager,address router,uint24 poolFee,int24 tickSpacing,bool enabled); function getLaunchConfig(uint256 id) view returns (address pairToken,uint256 dexId,int24 initialTick,uint256 supply,uint16 maxWalletBps,uint16 maxTxBps,uint32 restrictionBlocks,uint24 buyPairHopFee,bool enabled,bool permissioned); ``` ## Launchpad architecture and AMM model NoxaFun is a token launchpad built on top of configurable Uniswap v3-style DEX deployments. The selected V3 factory provides trading and concentrated liquidity, while Noxa adds launch and DEX configuration, restrictions, token attribution, progress, and metadata. **Classification: Uniswap v3-like with configurable DEX and launch records.** The launch factory selects a DEX configuration, pool fee, tick spacing, position manager, and pair token; the resolved pool then follows V3 pricing and liquidity semantics. **Shared with V3:** `token0`/`token1`, `slot0`, `sqrtPriceX96`, ticks, signed swaps, and concentrated positions. **Protocol-specific:** DEX/launch configuration IDs, anti-whale restriction fields, launch registration, quote-progress target, and launch-transaction metadata. ## Price calculation Use V3 `sqrtPriceX96` in exact pool order, adjusted for decimals. Use `isToken0` only for launched-token orientation. ## Liquidity tracking Track signed V3 swaps and `Mint/Burn/Collect/Flash`. Pool balances represent inventory; concentrated liquidity needs tick conversion. ## Launchpad state, bonding, and migration The launch target is 4.2 quote ETH for the current Robinhood deployment. `progress = clamp(currentQuote / 4.2e18 × 100)`. Apply signed quote deltas so sells reduce progress; completion requires the target or explicit terminal state. ## Metadata Decode metadata/social parameters from `launchToken` input and enrich from the protocol token endpoint. Merge with ERC-20 fields; factory registration remains the identity source. ## Related Robinhood Chain launchpad integrations * [RealFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/realfun) * [Bow.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/bowfun) * [Klik launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/klik) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate Pons on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/pons Complete Pons integration guide for Robinhood Chain: contracts, ABI, Uniswap V3 pricing, liquidity tracking, bonding percentage graduation, migration, and token metadata. # Pons Launchpad Integration on Robinhood Chain Learn how to index and integrate the Pons launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. Integrate Pons V3 launch markets, both factory generations, graduation state, and launcher metadata. This guide describes the public contract surface for an independent integration. ## Network and contracts Unless another chain is listed, these addresses are for Robinhood Chain (`chainId 4663`). Verify proxy implementations and mutable configuration at the indexed block. | Role | Address | | - | - | | Active factory | `0xA5aAb3F0c6EeadF30Ef1D3Eb997108E976351feB` | | Active locker | `0x736D76699C26D0d966744cAe304C000d471f7F35` | | Legacy factory | `0x0c37a24F5D23A486FA692d1500881d698B1F77a4` | | Legacy locker | `0x31ca5E101941A93A7DD6d0497928700625CF54B5` | | V3 factory | `0x1f7d7550b1b028f7571e69a784071f0205fd2efa` | ## Market discovery and ABI `TokenLaunched` and `getLaunchedToken` bind token, pair, fee, position manager, position ID, and source factory. Support active and legacy factories independently. Verify the V3 pool returned for `(token, pairedToken, poolFee)` and preserve its `token0/token1`. ### Relevant ABI ```solidity theme={null} event TokenLaunched(address indexed token,address indexed deployer,address indexed dexFactory,address pairToken,address pool,uint256 dexId,uint256 launchConfigId,uint256 positionId,uint256 restrictionsEndBlock,uint256 initialBuyAmount); function getLaunchedToken(address token) view returns (address token,address deployer,address pairedToken,address positionManager,uint256 positionId,uint256 dexId,uint256 launchConfigId,uint256 restrictionsEndBlock,uint256 supply,bool isToken0,uint24 poolFee,bool exists,uint256 initialBuyAmount); function graduationStatus(address token) view returns (uint256 current,uint256 threshold,bool graduated); function getTokenInfo() view returns (address tokenDeployer,string tokenLogo,string tokenDescription,(string twitter,string telegram,string discord,string website,string farcaster) tokenSocials); function positions(uint256 tokenId) view returns (uint96,address,address token0,address token1,uint24 fee,int24 tickLower,int24 tickUpper,uint128 liquidity,uint256,uint256,uint128,uint128); ``` ## Launchpad architecture and AMM model Pons is a token launchpad built on top of Uniswap v3-style concentrated-liquidity pools. The V3 market handles swaps and positions, while Pons factories and lockers add launch configuration, token attribution, managed graduation positions, progress, and social metadata. **Classification: Uniswap v3-like with a launch factory and managed graduation position.** The canonical market uses V3 token ordering, square-root price, ticks, swaps, and NFT position liquidity. Pons adds active/legacy launch factories, lockers, launch configurations, a position ID, and explicit graduation status. **Shared with V3:** pool factory verification, `token0`/`token1`, `slot0`, signed swap amounts, and concentrated position math. **Protocol-specific:** factory generations, locker association, `getLaunchedToken`, `graduationStatus`, managed position metadata, and launcher-token socials. ## Price calculation Use V3 `sqrtPriceX96` in actual pool order. Apply decimals and orient the displayed launched-token price using `isToken0`; never mutate pool order. ## Liquidity tracking Track V3 swaps and position liquidity. The graduation position returned by the position manager supplies tick bounds and liquidity; convert it to token amounts at current sqrt price. Pool token balances provide a separate TVL measure. ## Launchpad state, bonding, and migration Use `graduationStatus(token)` directly: `progress = clamp(current / threshold × 100)`, and `graduated` is authoritative. When replaying swaps, update the same quote/current quantity according to the launched token side so buys increase and sells decrease progress. ## Metadata Call `getTokenInfo()` on the launcher token contract. It returns logo, description, deployer, and Twitter/Telegram/Discord/website/Farcaster. Normalize `ipfs://` and `ar://`; merge ERC-20 name/symbol/decimals. ## Indexing checklist 1. Index creation and bind the launched token to its canonical market. 2. Preserve on-chain token/currency order exactly. 3. Replay logs in block, transaction, and log-index order. 4. Keep raw integers until decimals are applied. 5. Treat graduation as protocol state, not a generic price shortcut. ## Historical indexing notes Use block-scoped reads when initializing historical state. Do not mix `latest` reads into an old-block replay. Store launched-token identity separately from native pool ordering. ## Related Robinhood Chain launchpad integrations * [RobinFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/robinfun) * [RealFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/realfun) * [Bow.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/bowfun) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate Printr on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/printr Complete Printr integration guide for Robinhood Chain: contracts, ABI, multi-chain bonding curve pricing, liquidity tracking, Telecoin graduation, migration, and token metadata. # Printr Launchpad Integration on Robinhood Chain Learn how to index and integrate the Printr launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. Integrate Printr multi-chain Telecoin bonding curves, trades, graduation, and metadata. This guide describes the public contract surface for an independent integration. > Protocol reference: [https://printr.fun](https://printr.fun) ## Network and contracts Unless another chain is listed, these addresses are for Robinhood Chain (`chainId 4663`). Verify proxy implementations and mutable configuration at the indexed block. | Role | Address | | - | - | | Printr protocol | `0xb77726291b125515d0a7affeea2b04f2ff243172` | | Public launch token | `0x0bc0ce5c9e36c0ec914b2b6643f8b0f1a1b77777` | ## Market discovery and ABI A Telecoin may have one curve per chain. Use `CurveCreated` to bind the token to `telecoinId`, base pair, virtual reserve, maximum supply, number of curves, and completion threshold. The token address is the curve identity on that chain. ### Relevant ABI ```solidity theme={null} event CurveCreated(bytes32 indexed telecoinId,address indexed token,address basePair,uint256 maxTokenSupply,uint256 totalCurves,uint256 virtualReserve,uint256 completionThreshold); event TokenTrade(bytes32 indexed telecoinId,address indexed token,address indexed trader,bool isBuy,uint256 tokenAmount,uint256 baseAmount,uint256 effectivePrice,uint256 issuedSupply,uint256 reserve); event LiquidityDeployed(bytes32 indexed telecoinId,address indexed token,address pool,uint256 tokenAmount,uint256 baseAmount); event TokenGraduated(bytes32 indexed telecoinId,address indexed token); function getCurve(address token) view returns (address basePair,uint256 totalCurves,uint256 maxTokenSupply,uint256 virtualReserve,uint256 reserve,uint256 completionThreshold); function getTelecoinId(address token) view returns (bytes32); function treasury() view returns (address); ``` ## Launchpad architecture and AMM model Printr is a multi-chain token launchpad whose active launch phase uses a protocol-specific bonding curve rather than Uniswap v3 or v4. Printr adds Telecoin identity, cross-chain supply allocation, curve trading, graduation, and later deployment of liquidity to an external AMM. **Classification: custom multi-chain bonding curve; not V3- or V4-like while active.** Pricing uses virtual quote reserve, real reserve, remaining curve inventory, issued supply, and a completion threshold. A later `LiquidityDeployed` event names the destination market, whose AMM type must be detected independently. **Shared with Uniswap-style AMMs:** deterministic reserve-dependent pricing and explicit token/quote trade amounts. **Different from V3/V4:** no tick, `sqrtPriceX96`, PoolKey, or concentrated-liquidity state on the curve; Telecoin supply and progress are distributed across multiple chains. ## Price calculation For a trade, `effectivePrice` is the authoritative execution/current price with 18-decimal scaling. For a snapshot, let `issued = completionThreshold - treasuryTokenBalance` and `remaining = completionThreshold - issued`; then spot price is `(virtualReserve + reserve) / remaining`, with base/token decimals applied. ## Liquidity tracking The active curve quote liquidity is `reserve`; the virtual component is `virtualReserve`. Remaining curve inventory comes from treasury token balance. After `LiquidityDeployed`, track the emitted destination pool independently and do not count virtual reserve as withdrawable liquidity. ## Launchpad state, bonding, and migration A zero `completionThreshold` indicates graduation. For an active multi-chain curve let `M = maxTokenSupply / totalCurves`, `G = completionThreshold × 10,000 / M`, and `R = reserve`, `V = virtualReserve`. Progress in basis points is `R × (10,000-G) × 10,000 / (V × G)`; divide by 100 for percent and clamp to \[0,100]. `LiquidityDeployed` or `TokenGraduated` is authoritative completion. ## Metadata Resolve the Telecoin ID, then fetch its `metaURI`/protocol metadata. Expected fields include name, symbol, description, image, and external links (website, X/Twitter, Telegram). Use ERC-20 metadata as fallback and keep the Telecoin ID for cross-chain grouping. ## Indexing checklist 1. Index creation and bind the launched token to its canonical market. 2. Preserve on-chain token/currency order exactly. 3. Replay logs in block, transaction, and log-index order. 4. Keep raw integers until decimals are applied. 5. Treat graduation as protocol state, not a generic price shortcut. ## Historical indexing notes Use block-scoped reads when initializing historical state. Do not mix `latest` reads into an old-block replay. Store launched-token identity separately from native pool ordering. ## Related Robinhood Chain launchpad integrations * [NoxaFun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/noxafun) * [Bottom.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/bottomfun) * [Hood.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/hoodfun) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate RealFun on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/realfun Complete RealFun integration guide for Robinhood Chain: contracts, ABI, Uniswap V3 pricing, liquidity tracking, locked liquidity launch, migration, and token metadata. # RealFun Launchpad Integration on Robinhood Chain Learn how to index and integrate the RealFun launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. RealFun launches each token directly into a locked Uniswap v3 token/WETH pool. There is no pre-migration bonding curve: the launch market is the final AMM from its first block. ## Network and contracts | Role | Robinhood Chain address | | - | - | | Single-sided launcher | `0xa3A71925be892c609Ac4BE4EFe918Dc9C35fc5e8` | | V3 factory | `0x1f7d7550b1b028f7571e69a784071f0205fd2efa` | | WETH | `0x0bd7d308f8e1639fab988df18a8011f41eacad73` | Read `weth()` and `v3Factory()` from the launcher when possible rather than assuming configuration is immutable. ## Market discovery and ABI Filter `TokenCreated` by the launcher address because another protocol may use the same event signature. Resolve the market through `poolOf(token)` or `launches(token)`, then verify the pool's factory and exact `token0`/`token1` values. RealFun uses a 1% V3 pool at launch. ### Relevant ABI ```solidity theme={null} event TokenCreated( uint256 ts, address creator, uint256 nonce, address token, string name, string symbol, string meta ); function poolOf(address token) view returns (address); function launches(address token) view returns ( address pool, uint256 nonce, uint8 mode, address feeWallet, address distributor, bool exists ); function weth() view returns (address); function v3Factory() view returns (address); ``` Also index the standard V3 `PoolCreated`, `Swap`, `Mint`, `Burn`, `Collect`, and `Flash` events. ## Launchpad architecture and AMM model RealFun is a token launchpad built directly on top of Uniswap v3-style locked liquidity. Instead of running a separate bonding curve, it launches the token immediately into its final concentrated-liquidity market and adds creation records, ownership, locking, and metadata. **Classification: directly Uniswap v3-like from launch.** RealFun creates a locked 1% token/WETH concentrated-liquidity pool immediately; there is no custom pre-bonding AMM and no migration between pool models. **Shared with V3:** exact token0/token1 ordering, `slot0`, `sqrtPriceX96`, ticks, signed swap deltas, and position liquidity. **Protocol-specific:** single-sided launcher attribution, locked launch liquidity, `poolOf`/`launches` records, and metadata carried by `TokenCreated`. ## Price calculation Read `sqrtPriceX96` from `slot0()` or the latest `Swap` event: `raw token1/token0 = sqrtPriceX96² / 2¹⁹²` Apply `10^(decimals0-decimals1)` to obtain the decimal-adjusted token1/token0 price. Invert only for the requested display pair. Preserve the pool's on-chain order even when the launched token is token1. ## Liquidity tracking Track signed `Swap` deltas and V3 `Mint`, `Burn`, `Collect`, and `Flash` events. Pool token balances at a fixed block are the simplest inventory measure. To calculate position amounts from concentrated liquidity, combine each position's liquidity and tick range with the current square-root price; liquidity `L` is not itself TVL. Because RealFun liquidity is locked and final from launch, do not create a synthetic pre-bonding reserve or later migration market. ## Launchpad state, bonding, and migration RealFun has no bonding or migration phase. Once a valid `TokenCreated` record and its verified V3 pool exist, the token is already in its terminal market state. For systems exposing generic launchpad fields, represent this as bonded/completed with 100% progress, while clearly identifying that this means “launched directly into the final AMM,” not “a curve reached a threshold.” ## Metadata `TokenCreated` provides creator, name, symbol, timestamp, nonce, and `meta`. The `meta` value may be: * an HTTPS/IPFS URL to JSON; * a direct image URL; * protocol metadata containing image, description, website, Twitter/X, and Telegram. Normalize decentralized-storage URLs, parse JSON when applicable, and merge it with ERC-20 `name()`, `symbol()`, `decimals()`, and `totalSupply()`. Keep the event fields as the authoritative launch context. ## Historical indexing notes Use block-scoped reads when initializing old pools. Replay events in `(blockNumber, transactionIndex, logIndex)` order and never combine historical events with a `latest` pool snapshot. ## Related Robinhood Chain launchpad integrations * [ApeStore launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/apestore) * [DYOR.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/dyorfun) * [Long.xyz launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/longxyz) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # How to Integrate RobinFun on Robinhood Chain Source: https://docs.mobula.io/almanac/robinhood-launchpads/robinfun Complete RobinFun integration guide for Robinhood Chain: contracts, ABI, custom bonding curve pricing, liquidity tracking, token graduation, migration, and token metadata. # RobinFun Launchpad Integration on Robinhood Chain Learn how to index and integrate the RobinFun launchpad on Robinhood Chain, including contract discovery, ABI events, token pricing, liquidity, bonding state, graduation, and metadata. Integrate RobinFun native bonding curves and graduation events on Robinhood Chain. This guide describes the public contract surface for an independent integration. ## Network and contracts Unless another chain is listed, these addresses are for Robinhood Chain (`chainId 4663`). Verify proxy implementations and mutable configuration at the indexed block. | Role | Address | | - | - | | Factory / curve manager | `0xd861cb5dc71a0171e8f0f6586cadb069f3a35e4d` | | WETH | `0x0bd7d308f8e1639fab988df18a8011f41eacad73` | ## Market discovery and ABI The token address identifies the pre-graduation curve. Index `TokenCreated`, then apply `Buy` and `Sell` events to the curve state. Link the post-graduation pair from `Graduated`. ### Relevant ABI ```solidity theme={null} event TokenCreated(address indexed token,address indexed creator,string name,string symbol,uint256 totalSupply,uint256 ethUsdSnapshot,uint256 virtualEth,uint256 raiseTarget); event Buy(address indexed token,address indexed buyer,uint256 ethIn,uint256 tokensOut,uint256 newRealEth,uint256 newPriceWeiPerToken); event Sell(address indexed token,address indexed seller,uint256 tokensIn,uint256 ethOut,uint256 newRealEth,uint256 newPriceWeiPerToken); event Graduated(address indexed token,address indexed pair,uint256 lpEth,uint256 lpTokens,uint256 treasuryEth,uint256 liquidityBurned); function curves(address token) view returns (uint256 virtualEth,uint256 realEth,uint256 tokenReserve,uint256 raiseTarget,uint256 lpEth,uint256 treasuryEth,uint256 k,bool readyToGraduate,bool graduated,address creator,address feeRecipient,uint256 totalSupply); function currentPrice(address token) view returns (uint256); ``` ## Launchpad architecture and AMM model RobinFun is a token launchpad whose launch phase uses a protocol-specific bonding-curve AMM rather than Uniswap v3 or v4. The curve handles initial price discovery and fundraising; after graduation, RobinFun creates or identifies a separate terminal AMM pair. **Classification: custom constant-product-style bonding curve before graduation; not inherently V3- or V4-like.** The curve has virtual ETH, real ETH, token reserve, and invariant `k`, and emits protocol-specific `Buy`/`Sell` post-state. The `Graduated` event identifies a terminal pair, whose AMM model must be verified from that pair rather than assumed. **Shared with Uniswap-style AMMs:** reserve/invariant-based price movement and buy/sell asset flows. **Different from V3/V4:** no PoolKey, tick, `sqrtPriceX96`, concentrated-liquidity position, or PoolManager during the curve phase; graduation accounting explicitly separates LP ETH, LP tokens, treasury ETH, and burned liquidity. ## Price calculation Use `currentPrice(token)` or `newPriceWeiPerToken`, scaled by 1e18. If deriving the curve price, use the contract invariant and virtual ETH plus real state; do not use only real reserves. ## Liquidity tracking Before graduation, report real ETH and token inventory separately from virtual reserves. `Buy`/`Sell` provide authoritative post-trade `newRealEth`. On graduation, `lpEth` and `lpTokens` describe deployed liquidity and `treasuryEth` is not LP liquidity. ## Launchpad state, bonding, and migration `progress = clamp(realEth / raiseTarget × 100)`. Buys increase `realEth`; sells reduce it. `readyToGraduate` is not final. `graduated` or the `Graduated` event is authoritative bonded state. ## Metadata Name, symbol, total supply, creator, and ETH/USD snapshot are emitted in `TokenCreated`. Use ERC-20 reads as verification. No off-chain metadata URI is required by this ABI; logos/socials need a protocol API or another explicitly linked source. ## Indexing checklist 1. Index creation and bind the launched token to its canonical market. 2. Preserve on-chain token/currency order exactly. 3. Replay logs in block, transaction, and log-index order. 4. Keep raw integers until decimals are applied. 5. Treat graduation as protocol state, not a generic price shortcut. ## Historical indexing notes Use block-scoped reads when initializing historical state. Do not mix `latest` reads into an old-block replay. Store launched-token identity separately from native pool ordering. ## Related Robinhood Chain launchpad integrations * [Printr launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/printr) * [ApeStore launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/apestore) * [DYOR.fun launchpad integration on Robinhood Chain](/almanac/robinhood-launchpads/dyorfun) For broader methodology, see [Bonding Curves Mathematics](/almanac/bonding-curves) and [Pricing Engine Deep Dive](/almanac/pricing-engine). # Understanding Trade Fees - Complete Fee Breakdown Source: https://docs.mobula.io/almanac/understanding-trade-fees Get the complete fee breakdown for DEX trades. Unlike Axiom, GMGN, Padre that only show gas fees, Mobula provides full analysis with gas, platform, and MEV fees. # Complete Fee Breakdown for DEX Trades **The Most Complete Fees Data in Web3** — Unlike trading terminals like Axiom, GMGN, Padre that only display gas fees and a basic sum, the Mobula API provides a **complete fee breakdown** with detailed gas, platform, and MEV analysis. Available via REST API and WebSocket streaming. ## Why Mobula's Fee Data is Different Most trading platforms and aggregators only show you **partial fee information**: **The problem**: When platforms only show gas fees + a total sum, you're missing critical information. The **total trading cost** is often **2-5x higher** than just gas fees when using aggregators. Mobula is the only API that breaks down **every single fee component**. ### What Makes Fee Analysis Essential The **total fees** on a trade consists of multiple components: * **Gas fees (`gasFeesUSD`)**: Network costs — usually the smallest part * **Platform fees (`platformFeesUSD`)**: Aggregator/UI fees — often 0.5-1% of trade value * **MEV fees (`mevFeesUSD`)**: Priority fees, Jito bundles, sandwich protection