> ## Documentation Index
> Fetch the complete documentation index at: https://docs.o1.exchange/llms.txt
> Use this file to discover all available pages before exploring further.

# Direct contract integration

> Read current launch configuration, build safe launch transactions, trade through Uniswap v4, and consume canonical launch events.

This page intentionally uses exact contract fields for developers. For a plain-language product flow, start with [How it works](/launchpad/how-it-works).

Direct integrations should discover the active chain, read current factory state, build an unsigned transaction, and let the user's wallet sign it. Never hardcode a mutable configuration version or creation fee.

## Integration sequence

<Steps>
  <Step title="Select the active factory">
    Use only the current Base or Robinhood factory from [Production contracts](/launchpad/reference/production-contracts).
  </Step>

  <Step title="Read launch configuration">
    Read `configVersion`, `launchSupply`, `tickSpacing`, `feeDefaults`, `bands`, and `quotes(selectedQuote)` at one recent block.
  </Step>

  <Step title="Validate parameters">
    Apply the hard limits in [Limits and validation](/launchpad/reference/limits), confirm the quote remains registered, and calculate the pool supply after allocations.
  </Step>

  <Step title="Build payment">
    For native quote, set transaction value to the exact creation fee. For ERC-20 quote, ensure the factory allowance covers the exact creation fee.
  </Step>

  <Step title="Commit to the configuration">
    Set `expectedConfigVersion` to the fresh read and choose a short chain-time deadline. The o1 Launchpad interface uses the latest block timestamp plus 30 minutes.
  </Step>

  <Step title="Simulate, sign, and confirm">
    Simulate `createLaunch`, present all recipients and economics to the user, then request a wallet signature and wait for a successful receipt.
  </Step>

  <Step title="Parse canonical events">
    Read `Launched` for token and pool ID, then index the other factory, hook, PoolManager, escrow, vesting, and announcement events from the same transaction.
  </Step>
</Steps>

## Read the current snapshot with viem

The example below reads Base. For Robinhood, use a Robinhood Chain client and the current Robinhood factory and quote addresses from [Production contracts](/launchpad/reference/production-contracts).

```ts theme={null} theme={null}
import { createPublicClient, http, parseAbi, zeroAddress } from "viem";
import { base } from "viem/chains";

const FACTORY = "0xa52ad458cE0282a971ecC71C051A32f28946bb9F";
const factoryReads = parseAbi([
  "function configVersion() view returns (uint64)",
  "function launchSupply() view returns (uint256)",
  "function tickSpacing() view returns (int24)",
  "function quotes(address) view returns (bool registered,uint8 decimals,int24 startTickToken0Frame,uint256 creationFee)",
  "function feeDefaults() view returns (uint16 baseFeeBps,uint16 creatorBps,uint16 platformBps,uint16 referrerBps,uint16 antiSnipeStartTotalBps,uint32 antiSnipeWindowSeconds,address platformTreasury)",
]);

const client = createPublicClient({ chain: base, transport: http() });
const [version, supply, spacing, nativeQuote, fees] = await Promise.all([
  client.readContract({ address: FACTORY, abi: factoryReads, functionName: "configVersion" }),
  client.readContract({ address: FACTORY, abi: factoryReads, functionName: "launchSupply" }),
  client.readContract({ address: FACTORY, abi: factoryReads, functionName: "tickSpacing" }),
  client.readContract({ address: FACTORY, abi: factoryReads, functionName: "quotes", args: [zeroAddress] }),
  client.readContract({ address: FACTORY, abi: factoryReads, functionName: "feeDefaults" }),
]);
```

For a transaction integration, obtain the complete verified factory ABI from the chain explorer. `LaunchParams` contains nested vesting arrays, so a partial handwritten write ABI is easy to get wrong.

`startTickToken0Frame` is the factory's internal opening-price encoding for a registered quote. The factory handles token ordering and tick spacing when it creates the pool; a launch transaction selects the quote and does not submit a starting tick.

## `LaunchParams`

| Field                                       | Meaning                                                 |
| ------------------------------------------- | ------------------------------------------------------- |
| `name`, `symbol`                            | Token identity                                          |
| `contractURI`                               | Pinned token metadata URI                               |
| `salt`                                      | User salt, scoped by factory to the caller              |
| `quote`                                     | Registered quote address; zero address means native ETH |
| `allocationRecipients`, `allocationAmounts` | Parallel immediate allocation arrays                    |
| `vestedAllocations`                         | Beneficiary, amount, and cumulative staircase steps     |
| `expectedConfigVersion`                     | Exact fresh factory version                             |
| `deadline`                                  | Latest allowed chain timestamp                          |
| `roleMode`                                  | `0` for immutable metadata, `1` for metadata authority  |
| `metadataKeys`, `metadataValues`            | Parallel on-chain metadata arrays                       |

## Trading integration

Launch pools are ordinary Uniswap v4 pools with a required hook. Use the listed v4 Quoter for price discovery and the Universal Router plus Permit2 for execution. Preserve the exact pool key: sorted currencies, LP fee `0`, launch tick spacing, and the active hook address.

`tickSpacing` is part of the exact Uniswap pool identifier and controls valid liquidity range boundaries. The current value `200` represents about 2.02% between allowed boundaries; it does not make swap prices move in fixed 2.02% increments.

Use exact-input during the anti-snipe window. Encode optional hook data as the referrer address followed by a `bytes32` comment. Simulate at current timestamp and include slippage and deadline protection.

## Failure handling

Treat `StaleConfig` and `LaunchExpired` as refresh-and-rebuild errors. Treat quote removal, fee mismatch, allocation validation, salt reuse, immutability, and single-sided failures as blocking errors that require changed inputs or configuration. Do not silently fall back to another factory or quote.