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

# Build with FX

> Choose an integration path and bind it to a verified FX deployment.

FX exposes onchain launch and trading contracts, plus a read service for market and wallet views. An integration should keep market discovery, executable quotes, and transaction confirmation distinct.

<Note>
  FX's V6 revision 6 contracts are deployed on Arc mainnet, chain ID **5042**. Start with the [deployed contracts and manifest](/developers/contracts). The public app and market API are not hosted yet; [release status](/reference/release-status) records the current launch gate and official-token registration.
</Note>

## Choose your integration

<CardGroup cols={2}>
  <Card title="Quote and execute" icon="route" href="/developers/quote-and-settle">Construct an order, inspect simulated fees, and enforce settlement bounds.</Card>
  <Card title="Read markets and portfolios" icon="database" href="/developers/market-data">Discover launched tokens and consume consistent, paginated snapshots.</Card>
  <Card title="Understand the contracts" icon="diagram-project" href="/reference/architecture">Follow the factory, pools, hook, rewards, and revenue contracts.</Card>
  <Card title="Understand the product" icon="book-open" href="/how-fx-works">Learn the token and currency-market model before implementing it.</Card>
</CardGroup>

## Three kinds of truth

| Layer                              | Suitable for                                    | Does not establish                            |
| ---------------------------------- | ----------------------------------------------- | --------------------------------------------- |
| Market-data snapshot               | Catalogs, charts, balances, historical activity | The current executable result for an order    |
| Simulated execution quote          | Route comparison and a transaction review       | A reserved fill or future transaction success |
| Transaction receipt and settlement | The result of a submitted operation             | That an offchain index has already caught up  |

A successful transaction must not become a failed UI operation merely because the follow-up market read times out.

## Bind to a release

Use the [mainnet deployment manifest](/developers/contracts#release-manifest) as the source of contract identities. Pin its reviewed fingerprint independently of market-data responses.

The current wallet implementation validates the release and checks component bindings before preparing or sending an operation. Its integration boundary includes:

* The signing network and read client's network.
* Factory, registry, PoolManager, hook, router, quoter, and revenue components.
* Token membership and canonical pool keys from the appropriate factory.
* Asset addresses, decimal precision, and trade or launch capabilities.
* The intended recipient and active wallet account.

The same ticker can identify multiple unrelated tokens. The official FX token is a registered protocol identity, not whichever token happens to use the symbol FX.

## Preserve asset units

Contract amounts use unsigned integers in each asset's raw units. Keep them as BigInt or exact decimal strings.

For a six-decimal asset, 1.25 units becomes 1,250,000 raw units. An eighteen-decimal asset uses a different scale. Read the verified asset metadata instead of assigning one decimal count to every stablecoin.

Fee units also differ: FX hook rates use basis points, while native pool rates are reported in parts per million. Do not interchange their denominators.

## Launch integration

The factory's launch parameters define token identity and supply, starting valuation, builder allocation, market mode, quote asset or pair identity, fees, and a deadline.

Use the current release's factory preview and validation rules before constructing a transaction. A successful preview does not reserve admission, currency liquidity, or a future starting price.

Obtain canonical token pools from the factory after confirmation. Keep creator fees, holder rewards, builder vesting, and protocol revenue as separate accounting paths.

See [launch a token](/guides/launch) for the economic choices and [architecture](/reference/architecture) for contract responsibilities.

## Before enabling a signing interface

<Steps>
  <Step title="Verify the release">Load the approved manifest and matching ABIs. Confirm the network and immutable component relationships.</Step>
  <Step title="Separate reads from writes">Use snapshots for display and fresh contract simulation for a transaction review.</Step>
  <Step title="Bind the review">Keep the account, recipient, assets, route, amount, bounds, and deadline together. Invalidate the review when its signing context changes.</Step>
  <Step title="Track submission">Persist an in-flight operation before asking the wallet. Resolve ambiguous submissions and receipts before offering a duplicate action.</Step>
  <Step title="Refresh from confirmation">After success, request a market snapshot at or beyond the receipt block and preserve the confirmed transaction result while data catches up.</Step>
</Steps>