Flashbots vs Public PGA: Cost, Privacy & Inclusion
Think of Flashbots as the lane you rely on for predictable backruns and a clean audit trail, while public PGAs stay in your toolbox for canary probes, price discovery, and emergency fallback. FRB logs which lane each bundle used, making it easy to justify your decisions during desk reviews.
Key differences
- Privacy: Private bundles reduce information leakage vs public mempool.
- Cost: Public PGAs can devolve into bidding; private can save gas.
- Inclusion: Measure empirically; keep conservative fallbacks.
When to prefer Flashbots/private relays
Use private routes when you need predictability, refund transparency, and minimal leakage. FRB integrates with Flashbots plus other relays so you can rotate automatically. Private is ideal for live capital once your simulation metrics look healthy.
- Define per-relay budgets and fallback rules.
- Log relay health in Ops Pulse so on-call engineers have context.
- Combine with the Execution Hub for playbooks.
Set budgets per relay—e.g., 70% Flashbots, 20% Builder0x69, 10% standby—and let FRB enforce those ratios. If a relay degrades, the dashboard records the timestamp, error codes, and who approved the temporary switch.
When public PGAs still help
Public auctions remain useful for price discovery, parity checks, and tiny canaries while a relay is degraded. Treat them as an escape hatch, not your default lane.
- Limit size (≤10% of session cap) and set aggressive stop-loss thresholds.
- Log every attempt so compliance knows why you deviated from private defaults.
- Revert to private bundles as soon as relays stabilize.
Recommended next steps
- Start with simulation and canary sizes.
- Use the Relay Status and WSS Test.
- Review Flashbots bundles explained.
- Document your decision in the Knowledge Base for audits.
Also compare relay coverage and inclusion statistics in /metrics/flashbots. Knowing your baseline lets you react faster when the market shifts.
Decision matrix
| Scenario | Recommended lane | Notes |
|---|---|---|
| High-value strategy, normal latency | Flashbots or trusted private relay | Log budgets; fall back only if relay health dips. |
| Relay degraded, need to test | Public PGA canary (≤10% cap) | Record reason and revert quickly. |
| New market rollout | Simulation → private canary | Keep public lane disabled until Ops approves. |
Template policy snippet
Need language for your SOC/NIST binder? Start here:
We route all production MEV bundles through private relays (Flashbots, Builder0x69) when available. Public PGAs are restricted to canary routes capped at 10% of session budget. Any public usage must be logged with bundle ID, reason, and approval. Endpoints and relay health are monitored via Ops Pulse, and variance triggers automatic failover.
Copy it, adapt it, and include links to Security and Refund so reviewers see the full picture.
FAQ
How do we prove we followed policy? Keep Ops Pulse exports and Knowledge Base entries showing which lane each bundle used and why. Include timestamps and approvals.
What if regulators ask for logs? Direct them to your telemetry notes and attach this comparison for context.
Is there ever a reason to prefer public auctions? Yes—when relays are degraded or you need on-chain price references. Just limit size and document the deviation.