Requirement

Please provide us with issues you found in your past project or your research works.
The issues must be graded with 5 different levels
5 levels
- Level 1: Issues that free scan tools such as Slither and 4naly3er are expected to identify.
- Level 2: Issues that paid scan tools such as MythX and SolidityScan are expected to identify.
- Level 3: Issues that junior-level auditors are expected to identify.
- Level 4: Issues that intermediate-level auditors are expected to identify.
- Level 5: Issues that only senior-level auditors are expected to identify.
As a minimum requirement, please provide at least 1 issue for each level (total 5 issues)
- Please make sure every level has at least 1 issue
- 🙆‍♂️ Lv1: 1 issue, Lv2: 1 issue, Lv3: 1 issue, Lv4: 1 issue, Lv5: 1 issue
- 🙅‍♀️ Lv1: 2 issues, Lv2: 1 issue, Lv3: 2 issues, Lv4: 0 issue, Lv5: 0 issue
Tags
- Please select tags to group the issue properly. You can add multiple tags
  - DeFi
  - DEX
  - Lending
  - Bridge
  - Oracle
  - NFT
  - Marketplace
  - Staking
  - Vesting
  - Token
- If you know other good tags to explain the issue, please add them

Output guideline

The output should be submitted as a zip file in the following format

Directory Structure

output/
  |- lvl1
  |   |- src/
  |   |   |- <filename>.sol
  |   |   |- ...
  |   |
  |   |- details.md
  |
  |- lvl2 // Same structure as Lvl1
  |- lvl3 // Same structure as Lvl1
  |- lvl4 // Same structure as Lvl1
  |- lvl5 // Same structure as Lvl1

Format of `details.md` (!! Please copy this template !!)

# Title
<!-- title of the issue -->

# Level
<!-- integer from 1 to 5. Please read the 'Requirement' section in this doc -->

# Project Overview
## Name
<!-- project name -->
## Project Page
<!-- [Optional] the URL of the project page if it exists -->
## Code Page
<!--
   The URL of block explore or the git repo.
   In the case of git repo, please show it with tree and commit ID.
   (e.g. <https://github.com/Uniswap/v3-core/tree/e8de69a550d579c475f52d59a6fb2f7ef9e7f364>)
 -->
 ## Tags
 <!-- List of tags. Please read the 'Requirement' section in this doc -->

# Description
<!-- description to explain why it's vulnerable -->

# Location
<!-- Code location in the style <filePath:lineNumber> -->

# Code
<!-- original code block which has the issue -->


# How to fix
<!-- description to explain how to fix the code -->

# Suggested Code
<!-- Fixed code block -->

example

# Title
Reentrancy Vulnerability in Withdrawal Function

# Level
1

# Project Overview

## Name
Vulnerable Token Sale

## Project Page
<https://vulnerabletokensale.com>

## Code Page
<https://github.com/vulnerabletokensale/contracts/tree/a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6>

## Tags
- Token
- Reflection Token
- ERC20

# Description
The `withdraw` function in the `VulnerableTokenSale` contract is vulnerable to a reentrancy attack. The function first sends the requested amount of Ether to the caller and then updates the balance of the caller. This order of operations allows an attacker to recursively call the `withdraw` function before their balance is updated, potentially draining the contract of its Ether.

# Location
src/VulnerableTokenSale.sol:42-48

# Code
```solidity
function withdraw(uint256 _amount) public {
    require(balances[msg.sender] >= _amount, "Insufficient balance");
    
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success, "Failed to send Ether");
    
    balances[msg.sender] -= _amount;
}

How to fix

To fix the reentrancy vulnerability, the withdraw function should follow the "checks-effects-interactions" pattern. First, update the balance of the caller, then send the Ether. This ensures that the balance is updated before any external calls are made, preventing reentrancy attacks.

Suggested Code

function withdraw(uint256 _amount) public {
    require(balances[msg.sender] >= _amount, "Insufficient balance");
    
    balances[msg.sender] -= _amount;
    
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success, "Failed to send Ether");
}