# Omniston API v1beta8 `v1beta8` makes cross-chain settlement explicit in the API model. It uses `RFQ`, `Quote`, `Order`, `Execution`, `Input position`, and `Output position` to describe the swap lifecycle. Instead of treating cross-chain settlement as a special case of trade tracking, `v1beta8` separates source and destination blockchains, swap and order settlement, and execution-level state. The core goal remains the same: get a competitive quote and settle. What changed is the protocol model around that flow. The lifecycle is now described more explicitly as **RFQ → Quote → swap or order settlement → executions and positions for orders**, with clearer branching for **intrachain settlement** and **HTLC-based cross-chain settlement**. This helps clients branch earlier by settlement mode, flow type, and fee semantics. The same terminology is now used across user-facing swaps, resolver operations, partner fees, and support runbooks. ## What changed at a glance * The package namespace is `stonfi.omni.v1beta8`. * Cross-chain settlement is now represented directly in the lifecycle. * `RFQ`, `Quote`, `Order`, `Execution`, and position concepts are defined explicitly. * Swap settlement and order settlement are separate branches. * Intrachain and HTLC-based cross-chain flows use different data shapes. * Partner fees use **integrator** terminology and **pips**. * `ChainAddress` and `AssetId` are separate concepts and should not share one validation path. ## Who this is for * **Backend and low-level clients** integrating with WebSocket or gRPC directly. * **Resolver operators** reasoning about quotes, reservations, and execution phases. * **SDK users** who want the protocol vocabulary behind SDK concepts. Practical SDK migration steps live in SDK-focused docs. ## Terminology * **Input asset / output asset** and **input / output amounts** use the trader's perspective: what the trader sends and receives. * **Source blockchain** and **destination blockchain** describe where the **Input asset** is provided and where the **Output asset** is delivered. For intrachain swaps, they are the same blockchain. For cross-chain swaps, they differ. * **Swap settlement** and **order settlement** are the two main settlement branches in quote data: immediate routing for swap settlement, and an order with **Executions** for order settlement. * **Input position** / **Output position** are protocol positions tied to an **Execution** in order settlement. **Output position** fields are used for HTLC-based cross-chain settlement and are not included in simple intrachain cases. * **`ChainAddress`** and **`AssetId`** (`stonfi.common.v1`) are separate types. Addresses identify wallets, contracts, and positions. Asset IDs identify assets. Validation and storage should treat them differently. * **Integrator fees** use `integrator_address`, `integrator_fee_pips` on the RFQ, and fee amounts in units on the quote: `integrator_fee_units` and `protocol_fee_units`. One pip is 0.0001%. This replaces the older referrer and bps terminology. * **Gasless quotes** may not include `gas_budget` and `estimated_gas_consumption`. Client code should not require these fields for every quote. ## Supported chains Each supported blockchain has a fixed `chain_id` that identifies the chain where the input asset is provided or the output asset is delivered. Supported chains and `chain_id` values: {% hint style="info" %} **`chain_id` values** * `1` — Arbitrum (`arbitrum`) * `2` — Avalanche C-Chain (`avalanche`) * `3` — Base (`base`) * `4` — BNB Chain (`bnb`) * `5` — Ethereum (`ethereum`) * `6` — Polygon (`polygon`) * `50` — TON (`ton`) {% endhint %} How to use this map: * In SDK code, you usually select the chain by name in `chain.$case`. Those names map directly to the `chain_id` values above. * EVM chains use EIP-55 addresses and support `native`, `erc20`, and `erc1155` assets. * TON uses a valid TON address string and supports `native` and `jetton` assets. * The source-side `AssetId` and source-side `ChainAddress` must use the same chain. * The destination-side `AssetId` and destination-side `ChainAddress` must use the same chain. * Intrachain swaps use the same chain on both sides. Cross-chain swaps use different chains. * Example: a `base` input asset must be paired with a `base` source address. A `ton` output asset must be paired with a `ton` destination address. These terms are used across the docs, SDK examples, and resolver-facing APIs. Use them when naming internal fields, logs, dashboards, and support materials. For the full list of changes, see [Migration guide: `v1beta7` → `v1beta8`](/developer-section/omniston/v1beta7-to-v1beta8-migration-guide.md). For the canonical term list, see [Glossary](/developer-section/omniston/glossary.md). ## SDK Recommended SDK docs: * [Omniston SDK](/developer-section/omniston/sdk.md) * [Node.js SDK](/developer-section/omniston/sdk/nodejs.md) * [React SDK](/developer-section/omniston/sdk/react.md) * [React SDK migration v0.7 → v0.8](/developer-section/omniston/sdk/migration-v0.7-to-v0.8.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.ston.fi/developer-section/omniston/v1beta8.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.