Private Bug Bounty Triage: Validating and Reproducing Web3 Findings

Private audit and bounty workflows do not need louder claims. They need triage discipline first, then deterministic evidence: a test that sets up the vulnerable state, triggers the bug, and proves the impact with state changes the reviewer can verify.

What This Work Was

I recently worked on private Web3 bug bounty triage support where the task was focused: validate findings, reason about severity, and then turn the validated issues into clean, reproducible PoCs.

This was not public contest writing, and it was not a marketing writeup. The job was to support private bounty workflows across multiple protocols, mostly in Move-based ecosystems. The protocol names, exact bug titles, links, and code are private. The workflow is not.

The work covered different protocol surfaces: cryptography, staking, lending, perpetuals, infrastructure, authorization, accounting, liquidation, rate limits, asset migration, validator rewards, and epoch-based subsidy logic. The common requirement was the same every time: triage the claim, then prove the validated bug in code, not prose.

Why Triage Needs Reproduction

Triage is not just reading a report and assigning a label. A validated finding is still incomplete until someone can reproduce it. A good reproduction artifact removes ambiguity for everyone involved:

• The audit lead can confirm the finding is real, scoped correctly, and not a duplicate.
• The protocol team can see the exact broken state transition.
• The bounty reviewer can verify impact without guessing intent.
• The patch author can convert the PoC into a regression test.

That is the real value. The PoC written after triage is not just "exploit code." It is an executable argument.

My Standard For Bounty-Grade Triage

For private bounty work, I use a simple bar. If the triage artifact does not pass this bar, it is not ready.

1. One command reproduces the issue. The reviewer should not need to reverse-engineer the setup.
2. Assumptions are explicit. If the reproduction depends on a signer set, pool state, epoch, oracle value, balance, or threshold, the test says so.
3. Preconditions are asserted before the exploit path. The test proves the starting state is the vulnerable state.
4. The trigger is minimal. The exploit path should contain only what is needed to demonstrate the bug.
5. Impact is checked through state. Balance deltas, supply changes, frozen flags, health factors, reward counters, and used-hash maps are stronger than comments.
6. The output is reviewer-friendly. File path, command, expected result, and short TLDR are included.

The Workflow

1. Triage The Claim Into An Invariant

Before writing the PoC, I reduce the issue to one broken invariant. Examples of invariant shapes:

• Old authorization evidence must not become valid under a newer policy.
• A deposit must mint a non-zero redeemable claim when value is accepted.
• An unhealthy debt position must remain liquidatable through the intended path.
• A frozen account must not become transferable through an unrelated migration path.
• Epoch-based rewards must not be skipped because processing was delayed.

This keeps the reproduction focused. The test is not trying to explain the whole protocol. It is proving one violated property that survived triage.

2. Build The Smallest Realistic State

The best PoCs avoid both extremes: they are not toy examples detached from the protocol, and they are not full integration tests with unnecessary moving parts. I build the smallest state that still looks like the protocol's real execution path.

In Move, that usually means using the protocol's own test helpers, scenario runner, shared objects, capabilities, and coin types instead of faking internals. If the exploit only works through a public entry point, the PoC should use that entry point.

3. Prove The Before State

A strong triage artifact does not jump straight into the exploit. It first proves the important preconditions: balances, signer policy, threshold, pool supply, debt amount, health factor, epoch number, frozen flag, or whatever state the vulnerability depends on.

This prevents a common review failure: a test passes, but nobody can tell whether it passed for the reason claimed.

4. Write The PoC, Then Measure Impact

After triage, the PoC has one job: trigger the validated bug and assert the impact directly. If assets moved, the test checks the balances. If shares were not minted, the test checks supply and user claim value. If a liquidation path is broken, the test proves the position is unhealthy and the intended liquidation route cannot complete. If an epoch was skipped, the test compares what was owed against what was paid.

The goal is to make the finding hard to argue with.

Where Tooling Fits

I used AI as a speed layer, not as the authority.

AI is useful for speeding up codebase navigation, finding helper APIs, drafting test scaffolds, and generating candidate state setups. It is not a substitute for understanding the protocol invariant. The final authority is the compiler, the test runner, and the state assertions inside the reproduction.

In practice, the useful loop looks like this:

• Use AI to map the relevant modules and test helpers faster.
• Manually decide the invariant, severity reasoning, and impact proof.
• Use AI to draft the first test skeleton.
• Run, debug, simplify, and tighten the assertions.
• Only ship once the PoC is deterministic and readable.

That is the part protocol owners should care about: not whether AI touched the workflow, but whether the delivered artifact is precise, reproducible, and useful for remediation.

What I Delivered

For each private finding, the output was intentionally practical:

• triage notes around scope, severity, and impact,
• unit-test PoC code written in the repository's existing style,
• the exact file path where the test should be added,
• the exact command to run,
• expected test output,
• a short explanation of what state changed and why it proves impact,
• enough detail for the artifact to become a regression test after the fix.

That last point matters. A good bounty PoC should not die after triage. It should become part of the protocol's long-term test suite.

What Protocol Owners Get

If you are a protocol owner, this is what this kind of work gives you:

• Faster verification: less back-and-forth with reviewers because the reproduction is executable.
• Cleaner fixes: engineers can patch against a concrete failing behavior.
• Better regression coverage: the PoC can be kept as a test to prevent the same bug class from returning.
• Sharper severity discussions: impact is shown through state transitions instead of debated abstractly.

For audit firms and bounty teams, the value is also direct: less reviewer time wasted on vague reports, stronger evidence packages, and cleaner handoff to the protocol team.

The Bar

A serious triage reproduction should answer four questions:

1. What exact state makes the bug possible?
2. What exact action triggers it?
3. What exact state change proves impact?
4. What exact command lets another reviewer reproduce it?

If a reproduction answers those four questions, it becomes more than a demo. It becomes evidence.

Private details stay private. The standard does not: validated findings deserve deterministic reproduction tests, state-level impact checks, and steps that survive reviewer scrutiny.