RFQ is a feature, not a product: Moby Market vs Hashflow

Request-for-quote is one of the cleanest ideas in institutional execution. Instead of routing through a public AMM and paying the slippage tax, you ask a set of professional market makers to quote your size privately, you pick the best quote, and you settle. RFQ has been a fixture of TradFi for decades; in DeFi it took Hashflow to popularise it.

Hashflow is good. It made RFQ feel native to crypto, integrated market makers who could honour the quotes they streamed, and gave EVM swappers a real alternative to AMM slippage on mid-sized trades. The question is whether RFQ alone is enough to be the execution stack for a serious desk, or whether it is one tile in a larger picture.

This post argues for the second framing. RFQ is a feature; an execution stack is RFQ plus algos plus privacy plus settlement plus cross-chain. Moby Market is built that way. Hashflow is not. The two protocols overlap in places and diverge in others, and the right choice depends on the shape of your flow.

What Hashflow actually does well

Hashflow’s core insight is that streamed quotes from committed market makers can beat aggregator routing on a wide range of EVM swap flows. The MMs post signed quotes that are valid for a short window; the swapper accepts a quote, the protocol settles. There is no slippage from AMM curve mechanics because the trade settles at the quoted price.

The model has real strengths. Slippage is bounded by the MM’s quote, not by pool depth. MMs compete on tightness because lazy quoting loses flow. The protocol surface is simple enough that wallet integration is trivial. For a desk doing repeated $200k–$2M swaps on Arbitrum or Polygon, Hashflow is a clean answer.

It is also worth saying that Hashflow’s MM integration story is mature. Many of the same firms that quote on Hashflow also quote on traditional venues, and the on-ramp for new MMs is short. That depth shows up in tighter spreads relative to younger RFQ networks.

Where the model starts to strain

The trouble starts when the trade gets large or the requirements get richer.

Quote depth degrades with size. RFQ depth is the MM’s risk appetite for the specific pair. At sizes that exceed the MM’s appetite, quotes widen, and at sizes beyond several MMs’ appetites combined, quotes either fail or quote at AMM-baseline prices. Hashflow handles this gracefully — the protocol does not lie about depth — but the desk still has to find another execution path.

No execution-algo semantics. A $50M unwind that the MMs cannot quote in one ticket needs to be sliced over time. Hashflow does not model that; you have to run the slicing externally and submit a stream of smaller quotes. That works, but it puts the orchestration burden on the desk and the protocol cannot do anything clever like randomising the slice schedule to defeat detection.

No on-chain privacy. The RFQ flow protects you from public-mempool exposure on the actual swap, but the quote stream is visible to the MMs and to anyone running an MM relay. A desk whose intent is itself alpha leaks information to the people quoting it. For most flow this is acceptable; for flow where the intent is the alpha, it is a problem.

EVM-first. Hashflow has expanded across chains but the centre of gravity is EVM. A desk that primarily executes on Solana has to use a different protocol or run a worse experience.

What Moby Market does differently

Moby Market keeps the RFQ surface — the OTCEscrow flow with quote-in, quote-out, and atomic settlement is essentially the same idea — and adds four other capabilities behind the same protocol:

• Native execution algorithms. When the trade does not fit one ticket, the protocol slices it. TWAPOrder and VWAPOrder are first-class structs in the moby-trading crate. The desk submits the parent and the protocol runs the children.
• On-chain ZK privacy. Amounts are Pedersen-committed; addresses can be stealth-derived; the desk can prove jurisdiction or accreditation without revealing identity. The intent itself can be privacy-constrained.
• Solana settlement. Sub-400ms confirmation and cheap per-transaction cost make execution algos economical that would be unaffordable on Ethereum.
• Cross-chain primitives. CrossChainOrder carries Wormhole and LayerZero metadata so the same protocol settles atomically across Solana, Ethereum, Arbitrum, and Base.

The trade-off is breadth versus depth. Hashflow does one thing very well; Moby Market does five things in a single execution surface. For a desk whose flow needs only the one thing, Hashflow is the simpler answer. For a desk that needs the other four, the simpler answer is to put everything in one protocol.

The size question

There is a useful rule of thumb. Below roughly $5M per ticket on EVM, Hashflow’s MM depth is good enough that RFQ alone solves the slippage problem. Above $5M, or anywhere on Solana, you start needing execution-algo semantics, and the marginal value of having TWAP and VWAP inside the protocol grows fast.

The threshold is not a hard line — it depends on the pair, the time of day, the MMs quoting, and the desk’s tolerance for visibility. But it is a useful organising principle. RFQ scales sub-linearly with size; execution algos scale linearly. There is a crossover point and most desks know roughly where their crossover sits.

The privacy question

Hashflow does not model privacy as a first-class concern. The quote stream is visible to participating MMs, the settlement is on-chain in clear text, and the desk’s wallet address is public for anyone who watches.

For routine swaps this is fine — the privacy surface required is the privacy that ordinary on-chain activity provides, which is to say, not much. For strategy-bearing flow it is not fine. A desk accumulating a large position over weeks does not want every fill linked to a wallet that other actors are watching. A market-maker rebalancing inventory does not want competitors reading the inventory off-chain.

Moby Market’s privacy primitives (Pedersen commitments, stealth addresses, anonymity-set pools, selective disclosure) are explicitly built for that case. Hashflow’s are not. If the privacy use case matters, the protocols are not interchangeable.

The cross-chain question

Hashflow handles some cross-chain via partner bridges. Moby Market has cross-chain settlement primitives baked into the order types — CrossChainOrder carries the Wormhole message hash, the optional LayerZero packet ID, and the bridge provider as protocol-level fields. The settlement is atomic from the desk’s perspective: the order either fills end-to-end or reverts end-to-end.

For a desk that primarily executes within one chain ecosystem, this does not matter. For a desk that routinely moves nine-figure positions between chains, the difference is the difference between a protocol-level guarantee and an off-chain orchestration script.

An honest summary

Hashflow is the better protocol for EVM RFQ at sizes the MM network can quote in a single ticket. It will fill faster, with tighter spreads, against a more mature MM base.

Moby Market is the better protocol when any of the following are true: the trade is large enough to need slicing inside the protocol; the chain is Solana; the desk needs on-chain privacy on amounts or addresses; the desk needs cross-chain atomic settlement; or the desk wants typed intent execution (TWAP, VWAP, intent-based solving) inside one protocol surface.

Both protocols are honest about what they are. Hashflow has never claimed to be a full execution stack; Moby Market is explicit that the RFQ surface is one of several primitives.

How most desks will end up using both

The realistic answer for many desks is that the two protocols are not in zero-sum competition. A desk might use Hashflow for routine sub-$5M EVM swap flow and Moby Market for any of: Solana flow, large unwinds, privacy-sensitive flow, and cross-chain settlement. The integration cost is small (the Moby Market TypeScript client and Hashflow’s SDK are similar surface areas) and the operational benefit is using the right protocol for the right trade.

The framing we would push back on is the “either / or” framing. Treating RFQ as a competitor category to execution stacks confuses a feature with a product. Pick the protocol that fits each trade, and accept that no single protocol is the best answer for every trade your desk does.

That posture probably costs Moby Market some marketing edge against Hashflow specifically, but it matches how serious desks actually think about execution.