FRB Playbook: From Demo to First Live Bundle (Step-by-Step)

Answer first — Going from FRB's demo mode to a real live bundle is not a mystery; it's a discipline. The full onboarding fits in five gated steps: (1) verify the signed Windows installer with SHA-256 and Authenticode before opening it, (2) pair the desktop agent with /app using the 6-character PIN so your machine appears in the dashboard, (3) attach a private RPC and a Flashbots-compatible relay endpoint, (4) run the simulator against current mainnet state until it produces three clean profitable simulations in a row on the same strategy, then (5) send your first capped live bundle — small size, strict budget, public fallback off. The whole point of this progression is that nothing you do in step N can blow up something you did in step N-1. If you follow it in order you can't accidentally lose money to a configuration mistake — only to genuine market risk.

What "first live bundle" actually means

The FRB demo runs the same code path as live trading except that the relay submission step is replaced with a no-op log entry. So when you switch to live, two things are new in your system:

1. A signed transaction is being broadcast to a real builder relay.
2. Real ETH leaves your wallet on success — and on revert, real gas is burned.

Everything else (mempool ingestion, simulation, strategy logic, fee modelling, fallback handling) was already running in demo. This means most failure modes have already had a chance to surface harmlessly. The remaining ones are: wrong relay configuration, wrong wallet permission scope, wrong size.

This playbook is structured to catch each of those before any capital is at risk.

Step 1 — Verify the installer before opening it

Before clicking the FRB installer, do two checks:

• SHA-256. Open PowerShell in the folder containing the downloaded .exe and run Get-FileHash <filename> -Algorithm SHA256. Compare the resulting hash against the value published on the Releases page. If they don't match, do not run the file — re-download from a fresh tab or report the mismatch to support.
• Authenticode signature. Right-click the .exe → Properties → Digital Signatures tab. Verify the signature is from "FRB Labs Ltd" and that the certificate chain validates. If Windows shows "This digital signature is not valid," stop and report.

These two checks catch supply-chain tampering. They take 60 seconds. Skip them and you are trusting that nothing between the FRB build server and your hard drive has touched the file. See Windows setup: Verify SHA-256 & start with simulation for a worked walkthrough.

Step 2 — Pair the agent with the dashboard

Install, launch, and the desktop agent shows a 6-character PIN. Open /app in your browser, click "Add bot," paste the PIN. The agent appears in the dashboard with its hostname, IP region, and uptime.

What this pairing actually does:

• Establishes an authenticated bidirectional channel between the desktop agent and the web dashboard.
• Lets the dashboard send strategy configs and read telemetry (uptime, recent bundle outcomes, latency snapshots) — but not read the private key, which never leaves the machine.

Pair before you import a key. If anything is wrong with the pairing flow, you'll see it immediately on a clean install with no funds in scope.

Step 3 — Attach RPC and relay endpoints

The agent ships with default public endpoints that are fine for demo. For live execution, replace them.

• RPC — your read source. A commercial private RPC (QuickNode, Alchemy, Chainstack, etc.) at sub-100 ms p95 is the rational floor. See the Best Ethereum private RPCs guide for the user-protection vs searcher-side distinction.
• Relay — your bundle submission target. For Ethereum mainnet, the modern default is fan-out across Flashbots, Titan, beaverbuild, and rsync-builder simultaneously. FRB does this fan-out automatically once the relay set is configured.

Run the WSS Latency Test (Tools → WSS latency test) from the dashboard to confirm your RPC endpoint is healthy from your actual deployment region before continuing.

Step 4 — Simulate until three clean wins in a row

Switch the strategy from demo to live-paper mode (FRB calls this "simulation mode" — same code path as live, but the relay step is a no-op log).

Run it for whatever real-time window covers a normal range of opportunities for your target strategy: 30 minutes for a high-frequency Ethereum backrun strategy, an hour for a slower path. What you're looking for in the log:

• Three consecutive simulation wins on the same strategy with realised-against-simulated PnL gap < 5%.
• No relay errors (timeouts, malformed bundle responses, builder rejection).
• No revert reasons appearing that you don't recognise.

If you see consistent simulated revert reasons, you have a model bug — fix it before live. If you see realised-vs-simulated drift, your fee model is stale — see private bundle debugging.

Do not move to step 5 until this gate is clean. Most "FRB lost me money on day one" stories trace back to skipping this step.

Step 5 — First live bundle, capped

Now switch the strategy to Live mode and configure these caps before pressing start:

• Per-trade gas budget. Set this to roughly 1× the median gas your simulator showed. If real gas is materially higher than simulated, the strategy stops itself rather than burning the budget.
• Per-session ETH budget. Total ETH you're willing to put through the strategy in this session. A reasonable first-session value is the smaller of (your average winning trade × 5) or (~$200 USD).
• Slippage cap. Tight — 0.5% for most pairs, lower for stablecoin routes.
• Public mempool fallback OFF. First live bundle should be private-only; you want to see what the searcher path actually does without a fallback masking failures.
• Reverting-tx-allowed flag. Off unless your strategy genuinely needs a probe-and-retry shape.

Press start. Watch Ops Pulse and the bundle log. The first live bundle either lands or doesn't — both outcomes are informative. A clean land tells you the relay path is working. A non-inclusion tells you to compare the simulated win rate against the live inclusion rate; a 30%+ gap suggests latency or fee-model issues, not strategy issues.

What "graduating" looks like

After ~50 live bundles in capped mode, you have enough data to see whether the strategy is converging on its simulated PnL. If yes, raise the per-trade and per-session caps in 25% increments per day. If no, go back to step 4 — the model has drifted from reality and forcing it through with bigger size only loses faster.

Common first-bundle gotchas

• Wallet still on testnet. RPC is mainnet, wallet is on Sepolia. The first send will fail nonsensically. Verify chainId in the dashboard matches your RPC.
• Funded with the wrong asset for gas. Make sure the wallet has enough ETH for L1 / Mainnet, or the right native token for whatever chain you're targeting.
• Relay rate-limiting. Free-tier relay accounts throttle. The first bundle goes through; bundle 50 starts hitting 429s. Pay for a tier above what you think you need.
• Authenticode warning ignored. If Windows showed an unverified-signer warning at install time and you clicked through, you are not running the FRB build you think you are. Reinstall from a fresh download.

Where to go from here

• Flashbots bundles explained — the underlying mechanics.
• Inclusion probability 101 — how to read your inclusion rate honestly.
• Slippage / budget caps / risk guards — tightening the safety harness.