Become a Velora market maker
Tell us the chains, pairs, expected liquidity, and chain-scoped endpoints you want to connect.
Test your RFQ API
Run Velora’s generic RFQ harness before onboarding.
Integration flow
- Expose one chain-scoped API surface for each chain you trade on. This can be a separate base URL per chain, or one service with chain-specific paths such as
/mm/base/tokensand/mm/mainnet/tokens. - Publish your supported tokens, tradable pairs, and bid/ask grid for each pair.
- Keep Velora’s cache fresh through polling or, preferably, a WebSocket stream.
- Receive
POST /firmonly when a user is ready to trade against your liquidity. - Return a signed AugustusRFQ order for the requested amount, priced consistently with your published grid.
- Keep enough balance on the maker wallet, and approve AugustusRFQ as the spender for the maker tokens, so the order can settle.
What Velora expects from your service
Your market-maker service needs to be deterministic enough for routing and strict enough for settlement:/tokenslists every asset you trade on the chain./pairslists the base/quote pairs Velora may route through./pricesreturns the current bid/ask grid Velora should cache./firmreturns the signed order when a user commits./blacklistlets you block users who request firm quotes without executing.
What you provide at onboarding
Before the integration can go live, Velora’s team needs:- A chain-scoped base URL for each chain you trade on, either as separate hosts or distinct paths on the same host.
- An optional WebSocket URL for price and blacklist updates.
- Authentication credentials, if you want Velora’s requests signed: a Domain string, an Access Key, and a Secret Key, as described in the authentication section of the spec.
- A funded maker wallet, either an EOA or an EIP-1271 contract, with allowance to the AugustusRFQ contract on each chain. Approve AugustusRFQ, not Augustus v6.2. Per-chain addresses are on Chains & contracts.
- The latest output from the generic RFQ test harness, or the commit and config you used to run it.
Reliability rules
Velora keeps a market maker enabled only while quotes remain executable and consistent with the published grid.| Situation | Result |
|---|---|
/prices fails or returns an error | Trading pauses until the endpoint recovers. |
/firm refuses an amount covered by the grid | Repeated refusals can disable the integration. |
| Firm pricing drifts from the cached grid | Velora treats it as a bad quote. |
| The signature fails EOA or EIP-1271 validation | The order cannot settle and counts against the integration. |
| The maker wallet has not approved AugustusRFQ | The order cannot settle. |
| The maker wallet lacks inventory | The order cannot settle. |
/prices or closing the WebSocket until you are ready to resume.
Related pages
- Market maker API specification — every endpoint you need to implement, with payloads.
- Testing your integration — validate your endpoints with the generic RFQ harness.
- Order structure and signing — the AugustusRFQ order format and EIP-712 signing.
- Chains & contracts — AugustusRFQ addresses per chain.
- OTC API overview — the taker-facing side of AugustusRFQ orders.
- AugustusRFQ security audit — the settlement contract’s audit history.