Finding bugs is just one part of the bug hunting process.
Once you’ve found a bug, you write a report, and more importantly, you **must **write a proof of concept. It helps you ensure your finding is valid, makes triage faster, and creates less room for ambiguity & interpretation in the impact assessment.
However, there are quite a few PoC types. Which one should you pick?
1️⃣ Unit Test
One of the easiest methods is to write a unit test.
Projects will usually already have various unit tests exercising the vulnerable code. All you need to do is copy-paste one of these tests and adapt it to show the undesirable behaviour.
Unit tests are great as a PoC because the team can immediately add them to their test suite!
🍴 Exploit on a Fork
The most objective PoC type is a fully functional exploit.
To demonstrate the vulnerability, all you have to do is run it. Not on mainnet, though! Dev nodes all support forking from a real network. This allows you to run your exploit in a cleanroom environment like the real world but isolated from it.
This method is excellent as it demonstrates that the deployed contracts are definitively vulnerable!
🖥 Simulation
The previous two PoC types might be impractical for the bug you found.
For example, what if you discover a game-theoretic bug? The vulnerability might be in the design rather than the implementation. A complex-systems modelling and simulation framework like cadCAD can be helpful here! With it, you can demonstrate how particular actors and strategies can have a negative impact.
Simulations can help you demonstrate flaws in the design of a system.