Battle Phases

The six phases of a Battle Mode run — Setup, Exploit, Discovery, Fix, Retest, Complete.

Overview

Every Battle Mode run progresses through six phases. Each phase has a specific goal, produces specific output, and hands off concrete artifacts to the next phase. The phases run in order; you don't configure them individually.

See Battle Mode Overview for when to use Battle Mode at all, and Reading Results for how to interpret the scoreboard at the end.

The pipeline

 ┌─────────┐    ┌──────────┐   ┌───────────┐    ┌─────────┐   ┌─────────┐    ┌──────────┐
 │ 1 Setup │──▶ │ 2 Exploit│──▶ │3 Discovery│──▶  │  4 Fix  │──▶│ 5 Retest │──▶ │6 Complete│
 └─────────┘    └──────────┘   └───────────┘    └─────────┘   └────┬────┘    └──────────┘
                    │               │              ▲                  │
                    └───────────────┴──────────────┘                 │
                         Exploited findings                           │
                                                         Bypassed ───
                                                       (back to backlog)

Phases 2 and 3 both feed Exploited findings into Phase 4. Phase 5's Bypassed verdicts drop findings back into the Active backlog rather than shipping them in Phase 6's PR.

Phase 1 — Setup

Cygent prepares the sandbox and maps the attack surface.

Cygent clones the target repo into an isolated sandbox, runs the configured build command (forge build for Foundry projects, or your custom command), and deploys your contracts using the provided deployment inputs. In parallel, it reads the CARA finding list for the project and builds an initial attack surface map — which contracts are in scope, which functions are privileged, which state variables are financially critical.

Output: a sandbox with deployed contracts ready for attack, and a baseline attack-surface report shown on the battle's page. If anything goes wrong here — build fails, deployment fails, finding list missing — the battle stops before any attacks run and surfaces the configuration issue.

Phase 2 — Attack

Red Team writes exploit PoCs for each known finding.

The Red Team agents iterate through the CARA findings in scope for the battle. For each finding, they attempt to write a concrete exploit test — real Foundry (or equivalent) test code that triggers the vulnerability against the deployed contracts. The exploit isn't pseudo-code or prose; it's calldata the sandbox executes.

When an exploit lands — funds drained, unauthorized state change, admin takeover — that finding is marked Exploited. When Red Team cannot land an exploit for a finding (usually because the finding turns out not to be practically exploitable), the finding is marked accordingly and carried forward without a PoC.

Output: per-finding status (Exploited / not exploitable in this environment), plus the full exploit code for every Exploited finding. You can inspect each exploit by clicking into the finding on the battle page.

Phase 3 — Discovery

Red Team searches for new vulnerabilities beyond the known findings.

Having worked through CARA's finding list, the Red Team now goes hunting on its own. It looks for attack patterns CARA didn't flag — composite vulnerabilities that chain across multiple contracts, edge cases in state transitions, untested invariants, oracle-dependent attacks that weren't in the original scope. Anything it successfully exploits becomes a new candidate finding.

New exploits discovered here go through CARA triage before being added to the project's finding list. This prevents Discovery from polluting the backlog with false positives — the new finding has to pass the same quality bar as any other CARA finding.

Output: zero or more new findings, each with a working exploit PoC attached. These typically matter more than the Phase 2 findings because they were caught in addition to what the audit found — the value Battle Mode adds over a static audit.

Phase 4 — Fix

Blue Team attempts fixes for each Exploited finding. Up to 3 tries per finding.

For every finding marked Exploited in Phase 2 or Phase 3, the Blue Team agents try to patch the vulnerability. Each attempt is a proposed code change that Cygent applies in the sandbox, rebuilds, and tests against the exact exploit the Red Team used. If the exploit no longer lands after the patch, the fix is a candidate. If the exploit still lands, the attempt failed and Blue Team tries a different approach.

Each finding gets up to 3 attempts. If no attempt closes the exploit in those tries, the finding is marked as Unfixed and carried forward without a patch. This is rare but real — some findings genuinely require architectural changes that a patch loop can't produce.

Output: a candidate fix for each Exploited finding (or an Unfixed status if all 3 attempts failed). The candidate fixes are the starting point for Phase 5 — they've survived the original exploit, but they haven't survived a fresh attack yet.

Phase 5 — Retest

Red Team tries to bypass each candidate fix with a new exploit. Surviving fixes are Defended.

This is the phase that turns a candidate fix into a verified one. Red Team takes each candidate patch from Phase 4 and attempts to write a new exploit — one that bypasses the fix. The goal is to catch fixes that only close the specific instance of the bug but leave the underlying class of vulnerability open.

If Red Team can't produce a new exploit that lands, the fix is marked Defended. If Red Team can, the fix is marked Bypassed and the finding goes back to open.

Output: a final status for every fix — Defended or Bypassed. This is the real verdict. Only Defended fixes make it into the Phase 6 PR.

Phase 6 — Complete

Results compiled. PR created with verified fixes. Scoreboard finalized.

Cygent compiles the final battle state: the scoreboard counts (Exploited / Fixed / Bypassed), the per-finding outcomes, and a PR on the target repo containing only the Defended fixes. Bypassed and Unfixed findings are left in the finding backlog as Active for human follow-up.

A post-battle summary is posted to the default review channel and to the battle's page. A CSV export is available for audit-trail and compliance purposes.

Output:

• A PR on GitHub with verified fixes, ready to review and merge.
• A scoreboard on the dashboard with Exploited / Fixed / Bypassed counts.
• Per-finding detail pages with exploit code, fix diff, and retest results.
• A CSV export.

Phase handoffs

Timing and duration

Battles run asynchronously. Typical runtimes depend on the codebase size, the number of findings in scope, and sandbox type.

The battle page streams progress in real time — you don't need to sit on it.

Related