> For the complete documentation index, see [llms.txt](https://wiki.orbofi.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.orbofi.com/learn/tokenization-liquidity-and-onchain-systems/faq.md).

# FAQ

The questions integrators actually send us, answered in full. Explorer links point at [Blockscout](https://robinhoodchain.blockscout.com) for Robinhood Chain (id **4663**).

## Is the contract a fork of an existing launchpad?

**No.** The Orbofi factory is purpose-written contract code, not a fork of Pump.fun, Four.meme, Flap or any other launchpad. It composes two external protocols, both used **unmodified**:

| Layer                                                               | Whose code                                                         | What it does                                                                 |
| ------------------------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| **Orbofi Factory**                                                  | Orbofi                                                             | Entry point. Validates and configures every launch.                          |
| **Doppler** — Airlock, token factory, pool initializer, rehype hook | [Whetstone Research](https://github.com/whetstoneresearch/doppler) | Deploys the ERC-20, initializes and seeds the V4 pool, keeps the fee ledgers |
| **Uniswap V4** — PoolManager, Universal Router, Quoter              | Uniswap                                                            | Holds liquidity, executes swaps                                              |

The factory exists to be **opinionated about what a valid Orbofi launch is**, and to enforce that on chain rather than trusting whoever calls it. Concretely it pins:

* which numeraires may be paired against — allowlisted, and changes are timelocked
* the fee shape: both legs, their individual ceilings, and their combined bound
* a minimum treasury share, so a launch cannot be configured to pay the protocol nothing
* an opening-price floor per numeraire, so a pool cannot be initialized at an absurd price
* which initializer, hook, token factory, governance factory and migrator may be used

Allowlist and fee-config changes run through a **timelock with a guardian**, so neither can be altered in a single transaction.

**Contracts:** [Orbofi Factory](https://robinhoodchain.blockscout.com/address/0x8212F89CAFf7cB72E74008327983B52C909494FF) · [Doppler Airlock](https://robinhoodchain.blockscout.com/address/0xeb7c034704ef8dcd2d32324c1545f62fb4ad0862) · [PoolManager](https://robinhoodchain.blockscout.com/address/0x8366a39cc670b4001a1121b8f6a443a643e40951)

## What is the factory address, and will it change before launch?

**Current factory — already live in production since 2026-08-19:**

```
0x8212F89CAFf7cB72E74008327983B52C909494FF
```

[View on Blockscout](https://robinhoodchain.blockscout.com/address/0x8212F89CAFf7cB72E74008327983B52C909494FF)

This is the only address an integration needs for discovery.

**Will it change?** It can, when the factory is upgraded. Treat your address list as **append-only**: when a new factory ships, add it alongside this one.

**A factory upgrade does not change your parsing.** Every factory version emits the identical event:

```solidity
event AgentCoinLaunched(
    address indexed asset, address indexed creator,
    address pool, address numeraire, uint256 initialSupply
);
// topic0 0x5d474dbccaef0b3274a2302f351854d215f5cb89d8d566861c19668c197670ad
```

So a new factory costs you one line in an address list. Nothing about the token, the pool, the ABI or the decode changes. See [Index agent launches](/learn/tokenization-liquidity-and-onchain-systems/integrations/index-agent-launches.md).

## What is the tax structure on the bonding curve?

**There is no bonding curve.** Orbofi agents have no pre-DEX phase. The token is deployed and its full supply is placed into a Uniswap V4 pool in the **same transaction**, and it trades there from that block onward. There is no curve to price against and no curve tax.

**There is no token tax either.** The agent token is a plain ERC-20:

* no transfer tax, no reflection, no rebasing
* no blacklist, no pause, no trading toggle
* fixed supply, minted once at launch
* 18 decimals

A `transfer` moves exactly the amount requested. Every fee is charged by the **pool**, on the swap.

**The fee is 1.5%**, identical on buys and sells, plus **0.1%** automatically returned to the pool as locked liquidity — a **1.6% total** charged in-swap, already reflected in a quote from the [V4 Quoter](https://robinhoodchain.blockscout.com/address/0x8dc178efb8111bb0973dd9d722ebeff267c98f94). Do not subtract it a second time when displaying expected output.

It divides like this:

| Component           | Size | Destination                |
| ------------------- | ---- | -------------------------- |
| LP leg              | 0.1% | Fee beneficiaries          |
| Hook leg — revenue  | 1.4% | Fee beneficiaries          |
| Hook leg — compound | 0.1% | Back into locked liquidity |

The split funds the agent's creator, the agent's own treasury, and the protocol — background from an integrator's perspective, since the fee is taken by the pool in-swap and involves no integration step. What your indexer DOES need to know about it is in [Fees](/learn/tokenization-liquidity-and-onchain-systems/fees.md).

## Is there an anti-snipe or time-based dynamic fee window?

**Yes.** The pool registers Uniswap V4's dynamic-fee flag (`0x800000`) and runs a decaying schedule from the moment the pool is initialized:

|             |                                                                                                      |
| ----------- | ---------------------------------------------------------------------------------------------------- |
| Opening fee | **80%** (`800000`, where 1e6 = 100%) — floor and ceiling coincide, so this one is effectively pinned |
| Decay       | **linear**                                                                                           |
| Duration    | **10 seconds** — this is a `minFeeDecayDuration` **floor**; a launch may set longer                  |
| Settles at  | the standing rate — bounded by the factory rather than fixed by it                                   |
| Starts at   | pool initialization — the launch transaction                                                         |

The purpose is to make first-block sniping unprofitable: a bot buying in the opening block pays 80%, and by the time a human could reasonably act the fee has decayed to the standing rate.

**What this means for your integration:**

* **Always quote.** Call `quoteExactInputSingle` rather than assuming the standing rate. In the first ten seconds a hardcoded value is badly wrong.
* **Do not read the total off `Swap.fee`.** That field reports the **LP leg only** — it reads `1000` (0.1%) on a normal trade, not `16000`. The hook leg is charged through hook deltas the PoolManager never sees, so `Swap.fee` understates the real cost by roughly 16x. Verified against a live swap on chain.
* **Derive effective cost from the quote, or from the amounts.** `quoteExactInputSingle` is already net of both legs. For a historical trade, compare `amount0`/`amount1` against the pool price at that block.

## What is the graduation logic — threshold, target DEX, pool swap fee?

**There is no bonding-curve graduation.** An agent has no pre-DEX phase to graduate FROM — its full supply is placed in a Uniswap V4 pool at launch and it trades there from block one.

One nuance worth knowing: the shared pool initializer does expose a permissionless `graduate()` / `exitLiquidity()` migration path. It is economically gated (`MIN_GRADUATION_SHARE`) and **has never fired** — zero `Graduated` events across every Orbofi pool. If it ever did, that pool would emit `Graduated` and its LP-leg `collectFees` would revert thereafter. In practice there is no lifecycle transition to model; if you want to be thorough, watch `Graduated` as a fee-collection kill-switch, nothing more.

Liquidity sits in a **Uniswap V4** pool created in the launch transaction and stays there permanently. The launch position is **locked**; the creator cannot withdraw it.

Pool parameters, identical for every Orbofi agent:

```
fee         = 8388608     // 0x800000, dynamic-fee sentinel
tickSpacing = 200
hooks       = 0x4e3468951D49f2EEa976eD0D6e75fFCb44a9a544
currency0   = lower address of (agent token, numeraire)
currency1   = higher address
```

Because currencies are address-sorted, the agent is `currency0` for some pools and `currency1` for others — derive it, never assume. See [Liquidity layer](/learn/tokenization-liquidity-and-onchain-systems/liquidity-layer.md).

If your pipeline models a "bonding curve → graduated" lifecycle, treat Orbofi agents as **already at the DEX stage from creation** — there is no curve phase to represent.

## What is the token page URL?

```
https://www.orbofi.com/agent/{tokenAddress}
```

Example: <https://www.orbofi.com/agent/0xCf9fef947622A12b2129DaD471421105E59dbAAC>

The address is the agent's ERC-20 — the `asset` field of `AgentCoinLaunched` — and is accepted in any casing.

## Where is the ABI?

[**ABIs**](/learn/tokenization-liquidity-and-onchain-systems/abis.md) has everything needed for parsing:

* `AgentCoinLaunched` with its `topic0`, for discovery
* Uniswap V4 `Initialize` and `Swap`, for pools and trades
* `quoteExactInputSingle`, for pricing
* Both fee-ledger interfaces
* The full factory ABI as JSON — [`developers/abi/OrbofiLauncher.json`](https://github.com/Orbofi/Wiki/tree/main/developers/abi/OrbofiLauncher.json), 20 events / 58 functions / 85 custom errors

The agent token needs no ABI beyond standard ERC-20.

## How do I identify an Orbofi token?

Authenticate on the **event plus the emitting factory address**. That pair is the only authoritative signal — filtering on `topic0` alone is not sufficient, because any contract can emit any event signature.

Agent tokens are also mined to end in **`AAC`**, for example [`0xA197402dEA39E3D03c208319888bBD58976e6AAC`](https://robinhoodchain.blockscout.com/address/0xA197402dEA39E3D03c208319888bBD58976e6AAC). That is a display nicety and is grindable by anyone — never use it as an authenticity check.

## Which token is an agent paired against?

WETH or a tokenized stock, chosen at launch and fixed thereafter. Read it from the `numeraire` field of `AgentCoinLaunched`.

| Token | Address                                                                                                                                  |
| ----- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| WETH  | [`0x0bd7D308f8e1639FAb988Df18a8011f41eAcAd73`](https://robinhoodchain.blockscout.com/address/0x0bd7D308f8e1639FAb988Df18a8011f41eAcAd73) |
| NVDA  | [`0xd0601Ce157dB5bdC3162BBAC2a2C8Af5320D9EEc`](https://robinhoodchain.blockscout.com/address/0xd0601Ce157dB5bdC3162BBAC2a2C8Af5320D9EEc) |

Stock-paired agents are common, so do not hardcode WETH — pricing a stock-paired agent through ETH/USD misreports it by a large factor.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://wiki.orbofi.com/learn/tokenization-liquidity-and-onchain-systems/faq.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
