express-relay-primary-sources-2026-05-11

Express Relay primary sources

Collected: 2026-05-11 UTC

Primary sources reviewed

• https://docs.pyth.network/express-relay
  • Official introduction page.
  • Used to confirm Express Relay’s positioning as a priority-auction system for protocol developers and searchers, plus the integration surface around protocol-side and searcher-side adoption.
• https://docs.pyth.network/express-relay/how-express-relay-works
  • Official mechanism overview.
  • Used to confirm the liquidation example, the shift from validator tips toward protocol-level auctions, the participant set, and the claim that auction profits are shared back with the integrated protocol and other system participants.
• https://docs.pyth.network/express-relay/how-express-relay-works/auction
  • Official auction-design page.
  • Used to confirm that the auction is run offchain at the auction server, that bids compete by permission key, that a governance-selected relayer serves as auctioneer, that the auctioneer forwards a revenue-maximizing subset of bids, and that payment is extracted only for bids that execute successfully onchain.
• https://docs.pyth.network/express-relay/how-express-relay-works/opportunities
  • Official opportunities page.
  • Used to confirm the protocol-level framing of opportunities, the claim that Express Relay is oracle-agnostic, the Opportunity Adapter abstraction, Permit2 usage, searcher-specific adapter contracts, and the opportunity-server role as a shared distribution layer for current and historical opportunities.
• https://docs.pyth.network/express-relay/how-express-relay-works/permissioning
  • Official permissioning page.
  • Used to confirm the distinction between permissionId and permissionKey, and to anchor the analytical point that protocols define the scope of competition by how they identify contested positions.
• https://docs.pyth.network/express-relay/integrate-as-searcher
  • Official searcher-integration page.
  • Used to confirm the integrate-once story around APIs, SDKs, subscriptions, bidding, and execution across current and future protocols.
• https://github.com/pyth-network/per
  • Official repository.
  • Used to confirm that Express Relay is shipped as a multi-service system rather than only a hosted docs surface.
• https://raw.githubusercontent.com/pyth-network/per/main/README.md
  • Repository README.
  • Used to confirm the major codebase split across offchain server, contracts, and SDKs plus the multi-service development environment.
• https://raw.githubusercontent.com/pyth-network/per/main/auction-server/README.md
  • Auction-server README.
  • Used to confirm the practical auction mechanics: grouping bids by permission key, bundle selection, fallback behavior, privacy of losing bids, replay / network-risk caveats, and the relayer’s operational responsibilities.

Notes

• Express Relay cleared the bar because it is not just another searcher API or liquidation toolkit; it separates protocol-side permissioning, offchain auctioneering, opportunity normalization, onchain routing/payment extraction, and governance-controlled revenue-sharing policy.
• The strongest reusable insight is that “MEV recapture” can be implemented at the application layer rather than the sequencer or validator layer. Express Relay explicitly describes a move from validator-level competition to protocol-level competition.
• The relayer / auctioneer remains a real power center. Governance chooses the relayer, the relayer runs the offchain auction server, and auction quality depends on infrastructure reliability, private bid handling, bundle selection, and RPC freshness.
• The Opportunity Adapter is what makes the project analytically sticky. It turns many bespoke protocol integrations into one shared searcher interface, which means Express Relay is partly a middleware distribution network rather than only an auction contract.
• This entry should be compared later against Flashbots Auction, MEV-Share, Timeboost, protocol liquidation bots, and orderflow-selling designs like Oval so validator capture, protocol capture, and middleware capture do not get flattened together.