Connect your desk. Keep your edge.

The maker integration wraps your existing pricing service. You retain pricing discretion, inventory, signing authority, exposure decisions and the ability to decline. OTConChain supplies the proposed private client workflow, validates responses and prepares the client’s selected native fill.

Quickstart

1. Nominate a technical owner and an OTC/risk owner. Submit the maker application.
2. Agree a sandbox chain, approved token addresses/decimals, client wallet mode and settlement proxy.
3. Implement the proposed maker-owned quote endpoint with the v1 adapter contract.
4. Provide public inventory/signer addresses and evidence of signer authorization. Keep private keys in your environment.
5. Run the downloadable local conformance kit against the reference scenarios.
6. Agree credentials through a secure channel, connect the actual sandbox and complete joint acceptance.

Request and response

OTConChain calls your approved server-side endpoint, proposed as POST /rfqs/v1/quote. Each request contains requestId, chainId, exact token addresses, sellAmount, taker, executor, requested validity and a versioned auction envelope. Only required trade terms need to leave the client workflow; internal mandates can remain private.

Return firm, indicative or declined. A firm response contains requestId, quoteId, exact native EIP-712 domain, full native order and signature. An indicative amount is not executable. A timeout or decline must never fall back to a fabricated offer.

{
  "requestId": "local-example-001",
  "chainId": 1337,
  "sellToken": "0x2222222222222222222222222222222222222222",
  "buyToken": "0x3333333333333333333333333333333333333333",
  "sellAmount": "10000000000000000000",
  "taker": "0x099e6e0073d12DF35Dc937666A0Da7613f022Bac",
  "executor": "0x099e6e0073d12DF35Dc937666A0Da7613f022Bac",
  "requestedValiditySeconds": 300,
  "auction": {
    "auctionId": "auction-local-001",
    "opensAt": 1791971990,
    "closesAt": 1791972030,
    "minimumQuoteExpiry": 1791972060,
    "rulesVersion": "1.0.0-draft"
  }
}

Signing and inventory

For a client selling WETH for USDC, WETH is takerToken and USDC is makerToken. The client is taker; your inventory owner is maker. Native makerAmount is the output you offer, not the client’s lower minimum.

Use EIP-712 signature type 2. Sign with the maker EOA or an EOA registered by the maker through registerAllowedOrderSigner. Confirm authority at the chosen deployment. The pinned native signature path is not arbitrary ERC-1271 support. A contract inventory wallet may authorize an EOA only through its own verified execution process.

Your wallet separately approves the verified Exchange Proxy to spend the buy token. A signature does not escrow or reserve that inventory. Limit balances/allowances and account for aggregate exposure across every still-executable quote, including replaced offers.

Transport profile

The draft v1 profile is HTTPS with per-maker scoped bearer credentials held server-side, bounded request timestamps, unique request IDs and idempotent retry behavior. A request may be retried only with identical terms. Authentication credentials must travel through the agreed secure channel, never a public form or URL.

The downloadable interface is a proposal, not an operating public API. Freeze actual token issuance/rotation, replay window, request limits and response deadline in the joint environment sheet. mTLS or HMAC can be negotiated through a versioned adapter profile; do not silently substitute authentication methods.

Cancellation and stop controls

Replacing a quote and salt creates a distinct signed order. Hiding it, returning withdrawn or stopping your endpoint does not invalidate the old order. Cancellation becomes effective through the relevant protocol transaction and chain observation. Signer revocation can affect all outstanding orders relying on that signer.

Agree whether replacement requires cancellation, waiting for expiry or explicitly reserving concurrent exposure. Keep an incident owner, stop procedure and outstanding-order register.

Your six-item delivery packet

Joint acceptance includes firm success, indicative response, decline, timeout, reused request ID, changed payload, late response, expiry, wrong executor, cancellation, insufficient inventory/allowance, duplicate fill and signer revocation. Run against your own implementation; local emulator success is not desk connectivity.

Pilot collaboration

The Desk & Terminal Pilot adds a terminal handoff and partner-side contract around this maker interface. Read the specific scope and acceptance for desk/terminal responsibilities, EOA authority, single-maker disclosure, environment setup and connection-day evidence. Native signing types remain unchanged.