> For the complete documentation index, see [llms.txt](https://dualguard.gitbook.io/dualguard/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dualguard.gitbook.io/dualguard/security-reviews/findings/how-to-write-a-proof-of-concept-poc.md).

# How to Write a Proof of Concept (PoC)

A Proof of Concept (PoC) demonstrates a concept's feasibility. In security reviews, it illustrates a vulnerability or flaw within a codebase. Properly constructed PoCs help developers understand issues and their impacts, facilitating resolutions.

### Key Components

#### 1. Working Test Case

"This is the most direct way to demonstrate a vulnerability. It should be executable and should clearly show the flaw in action." The test case should be runnable and visibly expose the problem.

#### 2. Line-by-Line Comments

Add comments when you see fit, it helps the readers understand the PoC's flow and reasoning.

#### 3. Clear Separation of Actors

Define distinct roles involved:

* Attacker: The entity exploiting the vulnerability
* Victim: The entity affected by the exploit
* Protocol: The vulnerable system

#### 4. Detailed Scenario Highlighting the Issue

When test cases are impractical, provide step-by-step scenarios including:

* Initial State: System's initial state
* Steps: Sequential actions
* Outcome: Exploit results
* Implications: Potential consequences

### Recommendations

1. Suggest fixes addressing the vulnerability
2. Link to vulnerable code and relevant resources

### PoC Template

````plaintext
## Proof of Concept
### Overview: Briefly describe the vulnerability.
### Actors:
- **Attacker**: Description of the attacker's role.
- **Victim**: Description of the victim's role.
- **Protocol**: Description of the protocol's role.
### Working Test Case (if applicable):
```solidity
// Commented Solidity code demonstrating the vulnerability
````