Write the PoC anyway
I was annoyed when Cantina made proofs of concept mandatory. After a year of competing and judging, and a flood of AI-generated reports, I think it's the most useful rule in audit competitions.
When Cantina announced that every finding needs a proof of concept, I was upset. Writing a PoC for a complex protocol, often without any guidance from the project team, takes a lot of time. Time spent on a PoC is time not spent finding the next bug.
I changed my mind. Even where it isn't required, I now write a PoC for almost every bug I submit.
What a PoC gets you
It catches false positives before you submit. A surprising number of "valid" issues fall apart the moment you try to execute them. A familiar loop from the Pump.fun competition:
- Find an issue that looks valid (and imagine the six-figure payout).
- Start the PoC.
- Fail to make it work.
- Realize the chain's design prevents the exploit.
Repeat. Painful, but much better than finding out from the judge.
It also turns up other bugs. Building a working exploit forces you through code paths you'd otherwise skim. Some of my better findings came from something odd I noticed while writing a PoC for a different issue.
And it makes the report hard to argue with. A judge doesn't have to trust your reasoning when they can run the test.
The view from the judge's seat
I started judging competitions at Cantina in early 2025. It is a very different job from being a researcher: across hundreds of submissions, the question shifts from "is there a bug?" to "does this report prove what it claims?"
Over the past year I've seen more and more reports that are clearly generated by LLMs: confident, well formatted, and wrong. They describe a plausible attack that the code doesn't allow.
The mandatory PoC rule is effective. In competitions without it, a much higher share of reports look LLM-generated.
A PoC is the cheapest filter we have. A model can produce a convincing paragraph; producing a passing exploit test against the real codebase is much harder.
This isn't anti-AI
AI is genuinely useful for auditing, and I use it every day. Automated tools and AI-assisted workflows are already finding real bugs in competitions, and that's good for the industry.
It also means the number of plausible-looking reports will keep growing, so the bar on evidence has to stay where it is. If you used AI to find a bug, use it to help write the PoC too.
My checklist before submitting
- The PoC runs against the in-scope commit, not a modified copy.
- It shows the actual impact (funds lost, invariant broken), not just an unexpected state.
- Assumptions about roles and trust are stated explicitly. "That is trusted" is a common reason for rejection, so I address it up front.
- If I can't make it work, I find out why before I submit.
