Exploit Proofs
An exploit proof is Shepherd's primary deliverable. This page explains what they contain, how to interpret them, and how to use them.
What is an Exploit Proof?
An exploit proof is a validated demonstration that a specific vulnerability is exploitable under real onchain conditions.
Each exploit proof is produced by running an actual attack sequence against your protocol's digital twin and capturing the results.
What is in an Exploit Proof?
Hypothesis
The vulnerability claim was tested
Verdict
Confirmed, disproven, or inconclusive
Transaction sequence
The exact calls made, in order, with parameters
State diffs
Balance and storage changes at each step
Call traces
Full execution path through your contracts
Execution graph
Visual representation of the attack path
Impact assessment
What value was at risk or extracted
Replay pack
A Foundry/Hardhat test file you can run locally
Verdicts
Confirmed
The attack executed successfully. The exploit proof includes the complete attack path, stte changes, and a reproducible test.
A confirmed finding means this vulnerbility is exploitable given the current deployed state of your protocol. Remediation is recommended.
Disproven
The attack did not succeed under current conditions. The proof includes what was attemtped and why it failed.
A disproven finding is still valuable. It provides evidence that a potential concern is not currently exploitable, which helps prioritize remediation efforts and reduces noise from false positives.
Inconclusive
The test could not definitively confirm or deny exploitability. This can happen when:
The attack requires conditions that couldn't be fully replicated on the fork
External dependencies behaved unexpectedly
The hypothesis needs refinement
Inconclusive findings are flagged for manual review or re-testing with a more specific hypothesis.
Replay Packs
Every confirmed exploit proof comes with a replay pack - a self-contained test file that reproduces the exploit locally. This lets your team:
Verify the finding independently by running the test in your own environment
Develop and test fixes by modifying your contracts and re-running the exploit
Confirm remediation by verifying the attack no longer succeeds after a fix
Execution Graph
Each exploit proof includes a visual execution graph showing:
Entry point and initial conditions
Each step in the attack sequence as a node
Contract interactions and function calls as edges
State changes at each step
The final outcome
The graph is interactive so you can inspect individual nodes to see call parameters, return values, and state diffs at that point in the attack.
Using Exploit Proofs
For remediation
Exploit proofs give your development team exactly what they need to fix the issue: the attack path, the vulnerable function, the preconditions, and a test to verify the fix works.
For audit reports
Security researchers can include exploit proofs in audit reports as execution-backed evidence. This strengthens findings and helps clients understand severity through concrete demonstration rather than theoretical risk assessment.
For regression testing
Confirmed exploit proofs become regression tests. After a fix is deployed, Shepherd re-runs the exploit against the updated twin to confirm the vulnerability is resolved and no new issues were introduced.
Last updated