MEV Bot Onboarding Checklist: The First 7 Days Before Scaling Live Execution

Answer first - The first seven days with a MEV bot should be a controlled onboarding period: verify the build, separate wallets, configure limited settings, run simulation, review logs, and only then test capped live execution. Do not treat installation as a reason to scale. The goal of week one is evidence: clean logs, understood costs, working limits, and a clear stop plan.

This checklist is written for FRB users, but it also works as a general onboarding framework for any non-custodial MEV trading assistant.

Day 1: Verify before you run

Before opening the installer:

• Download only from the official Download page.
• Check release information on Releases.
• Verify the build through Trust Verification.
• Read the Risk Disclosure.
• Confirm you are using a dedicated machine or clean user profile.

Do not skip verification because a setup guide says the tool is easy. Ease of install and safety are different questions.

Day 2: Separate wallets and budgets

Set up wallet roles:

Set limits before connecting any strategy:

• Maximum route size.
• Maximum daily exposure.
• Maximum slippage.
• Maximum gas or tip budget.
• Allowed chains.
• Allowed routers or contracts.

Limits are not decoration. They are the guardrails that make a mistake survivable.

Day 3: Configure infrastructure

MEV execution depends on state freshness. Review:

• RPC endpoint latency.
• WSS stability where relevant.
• Relay or private-bundle route.
• Region selection.
• Reconnect behavior.
• Logging and alerting.

Use related guides:

• Best WSS Endpoints by Chain
• Best MEV Relays by Chain
• Mempool Scanning 101

If your infrastructure is unstable in simulation, it will not become safer under live pressure.

Day 4: Run simulation mode

Keep live execution off. Run Simulation Mode long enough to capture ordinary and volatile periods.

Review:

• Which routes are skipped and why.
• Whether gross and net calculations make sense.
• Whether slippage estimates are realistic.
• Whether gas or tips make routes uneconomic.
• Whether any contract or wallet permission is missing.
• Whether logs are understandable without guessing.

If you cannot explain the logs, do not go live.

Day 5: Fix configuration mistakes

Common findings:

• Wrong chain or RPC endpoint.
• Too much route size for available liquidity.
• Slippage cap too loose or too tight.
• Budget cap too high for the test wallet.
• Router allowlist too broad.
• Strategy enabled on a chain you did not intend.

Fix one thing at a time and rerun simulation. Bulk changes make logs harder to trust.

Day 6: Capped live canary

Only move to live if days 1-5 are clean. The first live run should be small and capped:

• Use the dedicated trading wallet.
• Keep route size small.
• Keep daily exposure low.
• Disable public fallback unless you understand the trade-off.
• Watch logs during the run.
• Stop if realized behavior diverges from simulation.

The goal is measurement, not scale.

Day 7: Review and decide

At the end of the first week, review:

• Net outcomes after all costs.
• Failed and skipped route reasons.
• RPC and relay stability.
• Slippage behavior.
• Any wallet-approval changes.
• Any support questions.
• Whether the strategy should remain in simulation.

The correct decision may be "do not scale yet." That is a valid outcome.

What beginners should avoid

Beginners should avoid:

• Main wallet usage.
• Unlimited approvals.
• Multiple live strategies at once.
• High-slippage routes.
• Unsupported chains.
• Scaling after one good session.
• Any workflow that asks for a seed phrase.

Start with one chain, one strategy, and one dedicated wallet.

What a Clean Log Actually Looks Like

Before going live, your simulation logs should pass a specific standard. Many operators go live too early because they can't distinguish between noisy-but-acceptable logs and genuinely problematic logs.

Acceptable in simulation logs:

• Routes skipped due to spread below minimum threshold (expected — not every opportunity is worth taking)
• Occasional slippage calculation mismatches of 5–10% (simulation approximates, not exact)
• "No path found" rejections for pairs not in your allowlist (expected by design)

Not acceptable — investigate before going live:

• Routes where simulated net PnL is negative but the execution decision was "proceed" (misconfigured profitability filter)
• Repeated "wallet approval missing" or "allowance insufficient" errors (will cause live failures)
• Unexplained gaps in log output (potential connection drops that won't be obvious in live execution)
• Any revert reason that reads "execution reverted" without a parseable reason code (unknown contract behavior)
• Consistent gas estimate errors > 30% vs. actual (indicates your gas calculator is not calibrated for this chain)

Log review timeline:

• Day 4 (initial simulation): read every log entry manually for the first 2 hours
• Day 4 continued: review summary statistics (skip rate, rejection reason distribution, simulated PnL distribution)
• Day 5: after configuration fixes, re-read first 30 minutes of logs manually to confirm fixes took effect
• Day 6 (canary): monitor actively during the session — don't walk away from the first live run

When Day 7 Says "Not Ready"

The correct outcome of the first week is sometimes "do not scale yet." This is not a failure. Common reasons and responses:

Simulation shows too many opportunities but live shows far fewer: Your simulation is missing competition modeling. Real execution will capture fewer opportunities than simulation suggests. Reduce your expected frequency by 40–60% and check whether the strategy is still worth running at reduced frequency.

Inclusion rate in canary is 30%+ below simulation: Your latency stack is insufficient for the strategy's competitive window. Either switch to a lower-competition chain/strategy, or improve your infrastructure (dedicated RPC endpoint, co-located execution).

Simulated PnL looks good but canary net PnL is negative: Gas cost calibration is off for live conditions. Simulation gas estimates may not match live fee market accurately. Review gas cap settings and expected gas per route type.

Logs are clean but you can't explain every decision: This is a knowledge gap, not a configuration problem. Stay in simulation longer and use the time to understand every decision pathway. You can't make good live decisions about a system you can't explain.

The checklist is a minimum bar, not a guarantee of success. A passed checklist means you've done the minimum due diligence, not that the strategy will be profitable.

Internal Links for the First Week

• Download FRB
• Trust Verification
• Security Model
• Simulation Mode
• FRB Pricing
• Risk Disclosure
• Base Playbook: First Private Bundle
• Backtesting vs Paper Trading vs Simulation
• Risk Management for MEV Bots

Download and verify the build, then run simulation before any live execution.

This checklist is educational. MEV strategies involve financial and execution risks, including latency, liquidity, slippage, gas, smart-contract, and market risks. Use limits and review the Risk Disclosure.