Cowrie Research

express-relay

4 min read

Express Relay

  • Name: Express Relay
  • URL: https://docs.pyth.network/express-relay
  • Category: protocol-side orderflow auction / MEV-recapture infrastructure / searcher-routing middleware
  • Summary: Express Relay is protocol-side orderflow-auction infrastructure, not just another Pyth product or generic searcher API. Integrated protocols put sensitive actions behind Express Relay permission keys, searchers bid offchain for priority, a governance-selected relayer runs the auction and forwards the winners, and the ExpressRelay contract only charges if execution succeeds before splitting the proceeds. The real reason to keep the note is the adapter layer: protocols expose opportunities in a shared format, searchers integrate once, and MEV capture shifts from validators toward the protocols that created the opportunity.
  • What it does:
    • Lets protocols require certain valuable operations to be accessed through Express Relay by defining protocol-specific permissionId values and combined permissionKey values checked in protocol code
    • Runs an offchain auction server that groups bids by permission key, ranks candidate bundles to maximize protocol revenue, and forwards winners plus fallback bids onchain through a relayer
    • Uses an onchain ExpressRelay contract that routes winning calls to target contracts and charges the bid amount only if the searcher’s transaction executes successfully
    • Shares auction revenue across system stakeholders, including the protocol that generated the opportunity and the relayer, with exact splits enforced in contracts and adjustable through governance
    • Normalizes heterogeneous protocol opportunities through the Opportunity Adapter so searchers can reason in common terms like tokens sold, tokens bought, calldata, value, executor identity, and bid instead of building a bespoke integration for every liquidation or RFQ flow
    • Gives searchers a single integration surface via HTTP / WebSocket APIs and SDKs, plus an opportunity server that broadcasts current and historical opportunities across integrated protocols
  • Key claims:
    • The main reusable primitive is not “better liquidation infra” in isolation; it is validator-to-protocol rent reassignment through permissioned application-level auctions. Express Relay explicitly says the auction has moved from the validator layer to the protocol layer.
    • The relayer / auctioneer is a major control surface. The docs say a relayer selected by governance runs the auction server and chooses the subset of bids that maximizes protocol revenue, so practical neutrality depends on offchain auction operations even though settlement ends onchain.
    • Express Relay is not just a first-price winner-take-all auction. The docs describe a sealed-bid-like system where multiple bids can win, fallback bids may also be forwarded, and losing bids remain private while winning bids become public only once submitted onchain.
    • The permission-key model matters analytically because the protocol defines what counts as one contested opportunity. That means auction scope, rent partitioning, and who competes with whom all depend on how integrated protocols encode their own position identifiers.
    • The Opportunity Adapter is one of the strongest reasons to keep this entry in the active corpus. It turns protocol-specific opportunity logic into a shared searcher interface and creates the hub-like network effect that could make Express Relay more than a single-protocol liquidation tool.
    • Despite the Pyth brand and oracle adjacency, the docs are explicit that Express Relay is oracle-agnostic. The more useful comparison class is Flashbots Auction, Timeboost, protocol liquidation bots, and other orderflow / priority-sale systems rather than oracle feeds alone.
    • The open question worth carrying forward is whether Express Relay actually decentralizes MEV capture or simply moves dependence from validators to a governance-chosen relayer, DAO-controlled revenue policy, and a shared opportunity-distribution hub.
  • Whitepaper: No canonical standalone Express Relay whitepaper surfaced in this pass. The strongest primary materials were the official Pyth docs for introduction, auction, opportunities, and permissioning plus the official repository README files; see ../whitepapers/express-relay-primary-sources-2026-05-11.md.
  • Sources:

Internal linkages

Governance / control risk

  • The real questions are who controls relayer selection, how legible bundle ranking and fallback forwarding really are, whether integrated protocols still meaningfully control their own permission-key design after they join the hub, and how much market power accumulates once searchers plug into one shared distribution layer.

  • Last reviewed: 2026-06-02 UTC

Graph View

Backlinks