Getting started with Recon Pro cloud fuzzing

Recon Pro makes it easy to run invariant tests in the cloud with Echidna, Medusa, Halmos, and Foundry. This guide walks you through your first cloud fuzzing campaign.

Why cloud fuzzing?

Running fuzzers locally has limitations:

• CPU bound: your laptop can only run so many tests per second
• Time limited: you probably can't leave your laptop running for 48 hours
• Single machine: can't parallelize across multiple cores/machines

Recon Pro solves all of these. Upload your tests, select your fuzzers, and let the cloud do the heavy lifting. Over 12,500 cloud fuzzing runs have been completed on the platform.

What you need before starting

Before launching your first cloud fuzzing campaign, make sure you have the following in place.

You need a Solidity project that compiles with Foundry. Run forge build locally and confirm it succeeds. Recon Pro uses Foundry under the hood for compilation, so if your project builds locally, it'll build in the cloud.

You need at least one invariant property. This can be as simple as a solvency check — a function that returns true if total assets are greater than or equal to total liabilities. Even a single well-chosen property can catch critical bugs. You can always add more properties later as you learn what to test for.

Your test setup should use the Chimera framework for cross-fuzzer compatibility, or a standard Foundry fuzz test. If you're starting from scratch, the Recon VS Code extension generates the full Chimera scaffolding automatically (handlers, properties, and configuration files). If you already have Foundry-based invariant tests, those work too.

You need a GitHub repository. Recon Pro integrates directly with GitHub to clone your code, install dependencies, and run campaigns. Private repositories are fully supported.

You don't need any special infrastructure. No Docker setup, no cloud configuration, no fuzzer installation. Recon Pro handles compilation, dependency resolution, and fuzzer orchestration entirely on the platform side.

Step 1: set up your project

If you're starting fresh, the fastest way is with the Recon VS Code Extension:

1. Install from the VS Code Marketplace
2. Open your Solidity project
3. Run the "Recon: Initialize" command
4. The extension scaffolds the entire fuzzing setup using Chimera

If you already have a Chimera-based testing setup, you're ready to go.

Step 2: log in to Recon Pro

Navigate to getrecon.xyz/dashboard and connect your account. You'll see your dashboard with options for:

• Running new fuzzing jobs
• Viewing results from previous campaigns
• Managing your repositories

Step 3: connect your repository

Recon Pro integrates with GitHub. Connect your repository and select the branch you want to fuzz. The platform will:

• Clone your repo
• Install dependencies
• Compile your contracts
• Prepare the fuzzing environment

Step 4: configure your campaign

Select your fuzzers and parameters:

• Fuzzer: choose Echidna, Medusa, or both
• Duration: how long to run (longer = more coverage)
• Workers: number of parallel fuzzing workers

Each fuzzer has distinct strengths. Echidna is thorough with corpus-based exploration and has mature shrinking. When it finds a violation, it reduces the call sequence to the minimal reproduction, which makes debugging easier. Medusa is faster with parallel execution and tends to find bugs quickly by exploring more sequences per second. Running both fuzzers on the same test suite gives the best overall coverage because they explore the state space differently.

Duration matters more than you might expect. A 10-minute campaign catches obvious bugs: missing access controls, basic arithmetic errors, properties that fail on simple inputs. A 1-hour campaign catches subtle interactions between functions, where the bug only appears after a specific sequence of 5 or more calls. Campaigns of 8 hours or longer catch deep state-dependent issues where the bug requires the system to reach a very specific state through a long chain of operations.

Workers control how many parallel fuzzing instances run simultaneously. More workers means more sequences explored per unit of time, which translates to faster coverage growth. The default worker count is usually sufficient for initial runs, but increasing it for longer campaigns helps explore the state space more thoroughly.

For your first run, we recommend Medusa with default settings. It's fast and gives good results quickly.

Step 5: launch and monitor

Hit "Start" and monitor progress in real-time. The dashboard shows:

• Live coverage metrics
• Any property violations found
• Transaction sequences that triggered violations
• Corpus growth over time

Step 6: analyze results

When the campaign completes, you get:

• Full report: summary of coverage achieved and properties tested
• Violations: any invariant violations with reproduction steps
• Shareable links: share results with your team via Recon's sharing feature

If violations are found, the platform shows the exact transaction sequence that triggered the failure, making it easy to understand and fix the bug.

Understanding the output

Knowing how to read fuzzing results is essential to getting value from a campaign.

The coverage report shows which functions and code branches the fuzzer reached during the campaign. High coverage means the fuzzer exercised most of your protocol's logic. Low coverage on a specific function usually means the handler's preconditions are too restrictive, or the function requires state that the fuzzer has difficulty reaching. Use coverage data to refine your handlers and improve future campaigns.

Property violations are the most actionable output. Each violation includes the exact call sequence that triggered the failure: the function names, their arguments, and the order in which they were called. This sequence is a concrete reproduction of the bug. You can copy it directly into a Foundry test and replay it locally to step through the execution and find the root cause.

If no violations are found, that doesn't mean the code is bug-free. It means the properties you defined held for all the sequences the fuzzer tested during the campaign duration. The correct response is to add more properties that test different aspects of your protocol and run longer campaigns. Absence of violations with high coverage and strong properties is meaningful evidence of correctness, but it isn't a proof.

The corpus (the set of saved test inputs that achieved new coverage) is preserved between runs. When you start a new campaign, it can build on the corpus from prior runs, reaching deeper states faster instead of re-exploring ground it has already covered. This makes repeated fuzzing campaigns progressively more effective.

Shareable reports let you send results to your team or external auditors. The report includes coverage data, property status, and any violation sequences. This is useful for coordinating between developers and security reviewers, or for documenting the testing that was performed before a deployment.

Tips for effective cloud fuzzing

1. Start with simple properties. Begin with solvency and basic accounting invariants.
2. Increase duration gradually. Start with short runs to validate your setup, then increase.
3. Use both fuzzers. Echidna and Medusa find different things. Run both.
4. Iterate on findings. Each violation teaches you about your system. Add new properties based on what you learn.
5. Run on every PR. Set up recurring fuzzing in your CI/CD pipeline for continuous security.

Integrating with CI/CD

The highest-value use of cloud fuzzing is making it continuous rather than one-off.

Recon Pro supports running fuzzing campaigns automatically through GitHub integration. When a pull request is opened, a short fuzzing campaign (5 to 10 minutes) can run against the changed code. This catches obvious regressions immediately — if a code change breaks a property that previously held, you find out before the PR is merged, not after deployment.

Longer campaigns can be triggered on merges to main or on a nightly schedule. These deeper runs (1 to 8 hours) explore more of the state space and catch subtle bugs that short campaigns miss. The combination of fast PR checks and deep nightly runs gives you both quick feedback and thorough coverage.

Results from CI-triggered campaigns appear directly in the pull request context, so there's no need to check a separate dashboard or wait for someone to run tests manually. If a property breaks, the violation and its reproduction sequence are immediately visible to the developer who authored the change.

This approach transforms fuzzing from a one-time audit activity into continuous security testing. Every code change is automatically validated against your invariant properties. Over time, as you add more properties based on past findings, the safety net grows stronger. New code is held to the same standard as existing code, and regressions are caught before they reach production.

What's next?

Once you're comfortable with the basics:

• Read our book for advanced invariant testing patterns
• Join our Discord community to discuss strategies with other fuzzing engineers
• Check out our bootcamp videos for in-depth tutorials

Cloud fuzzing with Recon Pro has helped teams find critical bugs, prevent $20M+ in potential losses, and ship with confidence. Get started today.