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.