Independent research

BTX RFQ Process: How Request-for-Quote Trading Works Before an Orderbook

A BTX RFQ is a structured request for a private quote: a buyer or seller states the size, side, timing, settlement preference, verification needs, and price logic they are willing to discuss, then the desk matches that interest against real counterparties before anyone is pushed into a transaction. That matters for early BTX liquidity because the market is not yet a deep, continuous public orderbook with tight spreads and visible depth at every size.

BTXOTC.com is an independent OTC research and intake site. It is not the official BTX protocol site, not a broker-dealer, not an exchange, and not financial advice. Official protocol facts should be verified from btx.dev and the BTX documentation. This guide explains the process discipline an OTC desk should use when collecting BTX buy or sell interest, especially while liquidity is still relationship-driven.

For a buyer-oriented version, see How to Buy BTX OTC. For sell-side context, see How to Sell BTX OTC. For risk controls, read the BTX OTC Safety Checklist and the desk overview at BTX OTC Desk.

Quick answer

The BTX RFQ process has five practical steps: intake, qualification, quote construction, negotiation, and settlement planning. Intake captures the side, approximate BTX amount, fiat or stablecoin budget, acceptable price reference, location, timeline, KYC or proof-of-funds boundaries, wallet readiness, and communication channel. Qualification filters obvious spam, fake balances, vague mandates, and counterparties who cannot explain how they will settle. Quote construction turns the request into a comparable term sheet. Negotiation records the status of each quote. Settlement planning only starts after the parties agree on size, price, proof, timing, and risk controls.

The goal is not to create pressure or fake urgency. The goal is to convert noisy market interest into auditable, structured demand that can later inform a marketplace or orderbook.

Why RFQ comes before an orderbook

A public orderbook works best when there is enough active liquidity for bids and asks to update continuously. In a young or specialized market, an orderbook can create a false sense of precision: one visible quote may not represent executable size, the spread can look arbitrary, and larger trades can move the market simply by appearing on screen.

BTX is especially likely to have early liquidity shaped by miners, infrastructure operators, long-term protocol believers, and private buyers rather than by anonymous retail flow. The official BTX site positions the network as “The Post-Quantum AI Blockchain” and describes a computational settlement system built around machine-verifiable rules, MatMul proof-of-work, post-quantum signatures, and shielded settlement primitives (BTX homepage). The mining page frames BTX mining for operators who already think in power, cooling, and dense-compute capacity (Mine BTX). Those participants often think in blocks of inventory, operating cost, treasury policy, and settlement risk, not in tiny screen orders.

RFQ fits that environment. It lets the desk ask useful questions before a quote is treated as real:

• Is the buyer looking for a one-time allocation, recurring accumulation, or strategic position?
• Is the seller a miner, early holder, treasury, brokered mandate, or reseller?
• Is the quoted size immediately deliverable, staged over time, or conditional on future mining output?
• Does the counterparty understand wallet, chain, confirmation, and operational settlement details?
• Is the price fixed, index-linked, negotiated as a range, or tied to a comparable market reference?

A later orderbook can still be useful, but the RFQ phase discovers the field schema, exception cases, status model, and trust boundaries first.

The core BTX RFQ data fields

A good BTX RFQ should be structured enough that two requests can be compared without rereading a chat history. The exact product can evolve, but the first version should capture these fields.

1. Side

Side is the simplest field: buy BTX, sell BTX, or mining supply. Mining supply deserves its own label because a miner may not be selling a current wallet balance; they may be discussing expected production, forward flow, or recurring inventory. That creates different settlement and delivery risk than a holder selling already-controlled coins.

2. Size and minimum fill

The RFQ should separate target size from minimum acceptable fill. A buyer might want 50,000 BTX but accept staged fills of 5,000 BTX. A seller might have 20,000 BTX available but only want to transact if at least 10,000 BTX clears. Without target and minimum fields, the desk cannot distinguish serious block interest from casual price discovery.

3. Price logic

Early RFQs should not pretend there is a perfect public mark if the market is thin. Capture price logic as a text and category field: fixed price, quote range, discount or premium to a reference, best-efforts price discovery, or request for indicative market color. The related BTX Price Quality guide should handle how to label stale, indicative, firm, and executable prices.

4. Settlement asset and route

Buyers need to say whether they intend to settle in fiat, stablecoin, or another asset. Sellers need to say what settlement assets they can accept. The route matters for compliance, timing, bank risk, and proof requirements. Even when two parties agree on BTX price, the transaction is not actually comparable if one quote assumes same-day stablecoin settlement and another assumes slow fiat rails.

5. Jurisdiction and eligibility constraints

OTC is not just a wallet-to-wallet workflow. Counterparties may have jurisdiction restrictions, entity constraints, sanctions-screening requirements, tax documentation needs, or internal policies that prohibit certain settlement methods. An RFQ should collect enough high-level information to avoid matching parties who cannot legally or operationally trade with each other.

6. Verification level

The RFQ should state what proof is available and what proof is required. Examples include proof of funds, proof of BTX control, signed message, transaction history, entity documentation, counterparty references, or proof that the seller controls mining output. The official BTX docs include wallet-management and transaction references for node operators (Wallet Management and Transaction RPCs), but an OTC process should avoid giving unsafe wallet instructions inside chat. Verification should be deliberate, documented, and scoped.

7. Timing and expiry

Every quote needs a clock. RFQs should include desired trade date, quote-valid-until time, settlement window, and whether partial fills remain open after a first match. A quote with no expiry becomes stale market debris. A quote with a clear expiry can be archived cleanly.

8. Contact, mandate, and communication channel

The desk should know whether it is speaking with principal capital, an agent, a miner, a treasury operator, or a referrer. The RFQ should also record preferred communication channel, backup contact, and whether the counterparty permits the desk to share anonymized terms with potential matches.

Qualification: turning interest into a usable quote

Most early market interest is not ready for matching. Some people ask “what price?” without size. Others claim to represent supply they cannot prove. Some buyers want a quote but have not decided on budget, settlement rail, or timeline. Qualification is the process of turning that into a useful request, or declining to move it forward.

A disciplined BTX RFQ desk should qualify requests with three questions:

1. Is the side real? The person should be able to explain whether they are buying, selling, mining, brokering, or just researching.
2. Is the size actionable? “Any amount” is less useful than a target range and minimum fill.
3. Is settlement plausible? The party should understand how they intend to pay or deliver, what proofs they can provide, and what timing they expect.

The qualification step is also where official-affiliation confusion must be removed. If someone believes BTXOTC.com is the official BTX protocol team, the desk should correct that immediately. Protocol claims belong to official sources such as btx.dev and the BTX specs. OTC commentary belongs to this independent site.

Quote construction: what the desk should send back

A quote response should be more than a price. A usable quote package should contain:

• Side: buy or sell.
• Size: target amount and minimum fill.
• Price: fixed number, range, or indicative level.
• Fee or spread: how the desk is compensated, if applicable.
• Settlement asset: fiat, stablecoin, or other route.
• Settlement sequence: simultaneous, staged, escrow-assisted, or other structure.
• Proof requirements: proof of funds, proof of coin control, entity review, or other checks.
• Expiry: exact time the quote stops being valid.
• Status: indicative, firm subject to verification, matched, in negotiation, expired, cancelled, or settled.

This structure prevents the most common OTC failure: treating a casual chat price as if it were a binding quote. A buyer asking for “10k BTX around market” is not the same as a verified buyer with settlement funds ready, a named expiry, and accepted proof requirements.

Negotiation and status flow

The status model should be explicit from the first version of the product. A simple BTX RFQ status flow can look like this:

1. New — request submitted but not reviewed.
2. Needs clarification — missing size, side, route, proof, mandate, or timeline.
3. Qualified — request is coherent enough for matching.
4. Indicative quote — desk has shared non-binding market color.
5. Firm quote pending verification — price and size are proposed, but proof or counterparty checks remain open.
6. In negotiation — counterparties are adjusting price, size, route, or settlement sequence.
7. Matched — buyer and seller have accepted core terms.
8. Settlement planning — proofs, wallets, timing, and transaction sequence are being finalized.
9. Settled — transaction completed and records archived.
10. Expired, cancelled, or rejected — quote is no longer active.

The important part is that “matched” and “settled” are not the same thing. A match says the economic terms line up. Settlement says the operational transaction completed. Keeping those statuses separate reduces pressure, mistakes, and disputes.

Settlement planning: where RFQ becomes operational

Settlement planning should begin only after the quote is qualified and the counterparties understand the risk controls. The plan should cover wallet readiness, payment route, confirmations, staged delivery, dispute handling, and what happens if either party misses the timing window.

BTX’s official documentation includes topics that matter to technically sophisticated counterparties: running a node, managing wallets, transaction RPCs, shielded pool RPCs, post-quantum cryptography, and network monitoring (Running a Node, Wallet Management, Shielded Pool RPCs, Post-Quantum Cryptography). An OTC desk should cite those sources for protocol facts, but it should not blur them into official endorsement.

For larger trades, staged settlement may be safer than one-shot settlement. For example, the parties may split a fill into tranches, verify each leg, and continue only after the prior leg clears. Escrow can help in some markets, but fake escrow is also a common risk. Any escrow claim should be independently verified, documented, and accepted by both sides before funds or coins move.

Why this data helps the future marketplace

The RFQ process is not just manual operations. It is product discovery. If the same fields appear in every serious request, those fields should become the marketplace schema. If the same objections appear in every negotiation, those objections should become education, filters, warnings, or automated checks.

Over time, the desk should learn:

• Common RFQ sizes for buyers and sellers.
• Whether miners prefer spot sales, forward flow, or recurring treasury programs.
• Which settlement assets create the least friction.
• Which proof requirements counterparties accept without slowing the deal too much.
• What quote statuses create confusion.
• Where public price references are trusted or distrusted.
• Which internal links and guides reduce repeated support questions.

That learning loop is why a manual RFQ layer can be more useful than launching a premature exchange interface. It creates real market data before making the interface look automated.

Safety notes for BTX RFQs

A BTX RFQ should never ask a user to expose seed phrases, private keys, or unnecessary wallet internals. Proof of control should be scoped and reviewed carefully. Counterparties should be skeptical of screenshots, rushed settlement instructions, last-minute wallet changes, and third parties who appear only after terms are agreed.

A serious desk should also maintain an audit trail: initial request, clarifying questions, quote terms, counterparty identity level, proof status, expiry, negotiation changes, and final outcome. The audit trail protects both sides if a quote expires, a party changes terms, or a settlement issue appears later.

For a broader checklist, use BTX OTC Safety and BTX OTC Safety Checklist. For mining-specific liquidity questions, see BTX Miner Liquidity and BTX Mining Economics.

Example BTX RFQ intake template

A practical intake form can start with this structure:

• Side: buy BTX, sell BTX, or mining supply.
• Target size: amount of BTX.
• Minimum fill: smallest acceptable transaction.
• Price logic: fixed, range, reference-based, or request for market color.
• Settlement asset: fiat, stablecoin, or other.
• Settlement timing: desired date and expiry.
• Jurisdiction: country or entity constraints at a high level.
• Verification offered: proof of funds, proof of BTX control, mining proof, entity documentation.
• Verification required: what the counterparty expects before proceeding.
• Communication: email, Telegram, or other channel.
• Notes: mandate, recurring interest, restrictions, or special settlement needs.

The form should route buyers to Submit buy interest, sellers to Submit sell interest, and ambiguous requests to Contact BTX OTC. Every submission should be treated as an expression of interest until reviewed.

FAQ

What does BTX RFQ mean?

BTX RFQ means “BTX request for quote.” It is a structured way for a buyer or seller to ask for executable or indicative OTC terms before there is a deep public orderbook.

Is a BTX RFQ the same as an order?

No. An RFQ is usually an expression of interest or quote request. It becomes closer to an order only after size, price, proof requirements, settlement route, expiry, and counterparty acceptance are agreed.

Why not just launch a BTX orderbook immediately?

A premature orderbook can display thin or misleading liquidity. RFQ lets the desk understand real buyer and seller needs, verification requirements, settlement routes, and repeated negotiation patterns before automating the market.

Is BTXOTC.com official?

No. BTXOTC.com is independent and should not be confused with the official BTX protocol site. Use btx.dev and the BTX docs for official protocol information.

What should I prepare before submitting a BTX RFQ?

Prepare your side, target size, minimum fill, price logic, settlement asset, timing, jurisdiction constraints, and what verification you can provide or require. Do not share private keys or seed phrases.