Skip to Content
HyperQuote is live on HyperEVM — Start trading →
RiskRelay Dependency

Relay Dependency

HyperQuote uses an off-chain WebSocket relay to coordinate RFQ broadcasts and quote delivery between takers and makers. While the relay does not custody funds or execute trades, it is a critical piece of infrastructure whose availability directly affects the ability to trade.

Single Point of Failure

The relay is a centralized service operated by the protocol team. If the relay goes offline, the following capabilities are affected:

CapabilityImpact When Relay Is Down
RFQ broadcastingTakers cannot send RFQs to makers
Quote deliveryMakers cannot send quotes to takers
Real-time matchingNo new matches between takers and makers
On-chain settlementUnaffected — previously signed quotes can still be submitted
Existing positionsUnaffected — options positions and collateral remain on-chain
Keeper settlementUnaffected — keepers can still settle options on-chain

The relay is not involved in settlement. Once a taker has a signed quote from a maker, the settlement transaction can be submitted directly to the HyperEVM blockchain without the relay. Relay downtime blocks new quote discovery but does not affect the ability to execute already-received quotes.

Censorship Risk

Because the relay is centralized, it has the technical ability to:

  • Filter RFQs — Refuse to broadcast certain RFQ requests.
  • Filter quotes — Refuse to forward certain maker quotes to takers.
  • Selective service — Provide faster or slower relay service to different participants.
  • Data collection — Observe all RFQ and quote traffic flowing through the relay.

In a permissionless ideal, no single party would have this power. The centralized relay is a pragmatic design choice for performance (low latency, real-time WebSocket delivery) that comes with a trust trade-off.

Data Loss

The relay processes real-time messages and may not persist all historical data. Risks include:

  • Message loss — In rare cases (relay restart, network partition), an RFQ or quote message may be lost in transit and never delivered to the intended recipient.
  • No replay — Lost messages are not automatically retried. The taker must resubmit the RFQ if no quotes are received.
  • Historical data — The relay does not guarantee long-term storage of historical RFQ and quote data. On-chain settlement events are the authoritative record.

No Fund Risk

The relay never holds, transfers, or has access to user funds:

  • Users do not approve the relay to transfer tokens.
  • The relay does not have any private keys that can sign settlement transactions.
  • Quote signatures are generated by makers using their own keys, not by the relay.
  • The relay cannot forge, modify, or replay signed quotes (EIP-712 signatures would be invalid).

Even if the relay is fully compromised (e.g., an attacker gains control of the relay server), user funds on-chain remain safe. The worst an attacker could do is disrupt service (preventing new quotes from being matched) or observe trade flow data.

Mitigation

Protocol-Level Mitigations

  • Stateless settlement — The on-chain contracts do not depend on the relay. Any signed quote can be submitted by anyone directly to the blockchain.
  • No fund custody — The relay never touches user funds.
  • Decentralization roadmap — Future protocol versions may implement a decentralized relay network to eliminate the single point of failure.

User-Level Mitigations

  1. Do not depend solely on HyperQuote — Maintain access to alternative trading venues (AMMs, HyperCore) for situations where the relay is unavailable.
  2. Monitor relay status — If you are unable to receive quotes, check the relay connection status in the UI before assuming there is a market liquidity issue.
  3. Cache quotes — Makers should cache signed quotes locally. If the relay drops a connection, previously generated quotes may still be valid and can be submitted out-of-band if the taker has the signed data.
  4. Use the API directly — Programmatic traders can connect to the relay WebSocket endpoint directly, with their own reconnection logic, rather than depending solely on the UI.
Last updated on