> ## Documentation Index
> Fetch the complete documentation index at: https://digraphsas-docs-cli.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# OTC API reference
> The OTC API settles direct trades between known counterparties: a maker signs an AugustusRFQ order off-chain, and the taker it names fills it on-chain.
An OTC trade on Velora is a deal between two parties who already know each other. The **maker** signs an [AugustusRFQ](/resources/chains-and-contracts) order off-chain and posts it to the REST API; the **taker** fills it on-chain. The `taker` field decides who that can be: name an address for a private, P2P trade, or leave the zero address to let anyone fill. To start, tag your app with any `partner` string.
* Name the `taker` and the order is fillable by exactly one address: bilateral OTC rather than a public order.
* The maker sets price, size, token pair, and `expiry` directly; nothing is exposed as a public order before it settles.
* Offering is gasless. The maker only signs (EIP-712) and posts, and the taker pays gas on the fill.
* A taker can fill less than the full `makerAmount`; the order stays live for the remainder until `expiry`.
* The fill resolves on-chain through AugustusRFQ, so the outcome is auditable and non-custodial.
Want an **open, target-price order** any solver can fill, gasless and MEV-protected? That's a Delta limit order, not OTC. Call [`GET /v2/quote`](/api-reference/delta/quote) and submit with `type=LIMIT` via [`POST /v2/delta/orders`](/api-reference/delta/overview). This RFQ surface is specifically for **bilateral OTC/P2P settlement** against a known counterparty.
## Lifecycle
The maker approves the **AugustusRFQ** contract to pull the `makerAsset` they're selling. AugustusRFQ is its own contract, separate from the Augustus v6.2 router. Native ETH must be wrapped first.
The maker builds the order (`nonceAndMeta`, `expiry`, `makerAsset`, `takerAsset`, `makerAmount`, `takerAmount`, `maker`, `taker`) and signs the EIP-712 typed data. The domain is `name: "AUGUSTUS RFQ"`, `version: "1"`, `chainId`, and `verifyingContract` set to the AugustusRFQ address.
`POST /ft/p2p/{chainId}/` with the signed order and `signature`. The server returns the stored order with its `orderHash` and `state`. Size against `GET /ft/fillablebalance/{chainId}/{address}` first; it returns the lesser of the maker's balance, allowance, and unreserved amount.
Hand the signed order to the taker over any off-chain channel: your backend, the API listing endpoints, or directly.
The taker approves AugustusRFQ for the `takerAsset`, then calls `AugustusRFQ.fillOrder` on-chain. The contract verifies the signature and the named taker, then settles atomically. This is an on-chain transaction, not a REST call. The fill reverts if the order is expired, already filled, or the caller isn't the named taker.
## Endpoints
| Method | Path | Purpose |
| ------ | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| `POST` | [`/ft/p2p/{chainId}/`](/api-reference/rfq/orders-submit) | Post a signed maker order — body carries the order fields plus `signature` and optional `permitMakerAsset` |
| `GET` | [`/ft/order/{orderHash}`](/api-reference/rfq/orders-get-by-hash) | Fetch a single order by hash |
| `GET` | [`/ft/p2p/{chainId}/maker/{address}`](/api-reference/rfq/orders-list-maker) | List a maker's orders — `limit`, `offset`, `orderBy`, `hideSmallBalances` |
| `GET` | [`/ft/p2p/{chainId}/taker/{address}`](/api-reference/rfq/orders-list-taker) | List orders addressed to a taker |
| `GET` | [`/ft/fillablebalance/{chainId}/{address}`](/api-reference/rfq/fillable-balance) | Maker's fillable balance for order sizing, optionally scoped to a token |
Everything lives under `https://api.velora.xyz`. Filling and cancelling are on-chain calls to AugustusRFQ, not REST endpoints (see [Filling an order](#filling-an-order) and [Cancelling an order](#cancelling-an-order)). AugustusRFQ is deployed on Ethereum, Arbitrum, Avalanche, Base, BSC, Gnosis, Optimism, and Polygon; see [Chains & contracts](/resources/chains-and-contracts) for per-chain addresses and availability.
## Filling an order
Once the maker has posted an order, the named taker can fill it programmatically or through a Velora interface; both settle through the same `AugustusRFQ.fillOrder` call on-chain.
* For bots, backends, and market-maker systems: approve AugustusRFQ for the `takerAsset`, then call `fillOrder` directly, or use [`sdk.otcOrders.fillOTCOrder({ order, signature })`](/sdk/products/otc), which encodes and submits the transaction for you.
* From the Velora app: every order has a shareable fill link keyed on its `orderHash`. Hand it to the counterparty and they approve and fill from the web app:
```text theme={null}
https://app.velora.xyz/#/FT/OTC/{orderHash}
```
* Inside the [Velora Widget](/widget/overview): the same OTC fill flow runs embedded, so partners can offer it in-app without sending users to `app.velora.xyz`.
Whichever path the taker uses, the same on-chain checks apply: expired, already-filled, or wrong-taker fills revert.
## Cancelling an order
There is no cancel endpoint. A maker cancels by sending a transaction to the AugustusRFQ contract (the same contract that verifies fills), so cancellation costs gas. This is the one place the OTC flow differs sharply from Delta, where cancellation is a gasless signed message to the relayer.
AugustusRFQ exposes two methods, both taking the order's `orderHash` (the EIP-712 hash returned when the order was posted):
| Method | Signature | Use |
| -------------- | ------------------------------------- | --------------------------------------------------------- |
| `cancelOrder` | `cancelOrder(bytes32 orderHash)` | Cancel a single order |
| `cancelOrders` | `cancelOrders(bytes32[] orderHashes)` | Cancel many in one transaction — cheaper than one tx each |
Cancelling marks the hash as cancelled on-chain, so any later `fillOrder` against it reverts. Send it from the maker wallet. Once the transaction is indexed, the order's `state` flips to `CANCELLED` and its `transactionHash` is populated. From the SDK, use [`sdk.otcOrders.cancelOTCOrder(orderHash)`](/sdk/products/otc).
Letting an order lapse past its `expiry` makes it unfillable with no transaction and no gas. For short-lived orders, a tight `expiry` is often cheaper than an explicit cancel.
## Order states
An order reports one of six states: `DRAFT`, `PENDING`, `FULFILLED`, `CANCELLED`, `SUSPENDED` (the maker's balance or allowance dropped below the order), and `EXPIRED`. Always re-check `expiry` against the current block before filling.
## SDK shortcut
Every step is wrapped by [`sdk.otcOrders.*`](/sdk/products/otc): maker approvals, build → sign → post (`submitOTCOrder`), taker approval and `fillOTCOrder`, plus `getOTCOrders` and `cancelOTCOrder`. For a copy-paste maker/taker walkthrough see [SDK → OTC](/sdk/products/otc).
## Related pages
* [OTC, conceptually](/overview/product-stack/otc) — when the counterparty matters as much as the price.
* [Market making on Velora](/resources/market-makers) — quoting into Velora with firm quotes settled through AugustusRFQ.
* [Delta V2 overview](/api-reference/delta/overview) — open, gasless, MEV-protected limit orders (`type=LIMIT`).
* [SDK → OTC](/sdk/products/otc) — maker and taker flows in TypeScript.
* [Chains & contracts](/resources/chains-and-contracts) — AugustusRFQ deployment addresses.
* [AugustusRFQ security audit](/resources/security/audits/augustus-rfq) — the settlement contract's audit history.
* [Troubleshooting](/api-reference/troubleshooting) — failure modes by symptom, cause, and fix.