> For the complete documentation index, see [llms.txt](https://audits.solidgrp.io/blitz-launchpad/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://audits.solidgrp.io/blitz-launchpad/audit-results/findings/airdrop.sol.md).

# airdrop.sol

## **Issue 01**

| **Type**      | **Severity**                                        | **Location** | **Status**                                       |
| ------------- | --------------------------------------------------- | ------------ | ------------------------------------------------ |
| Best Practice | <mark style="color:green;">**Informational**</mark> | `AirDrop`    | <mark style="color:red;">**Not Resolved**</mark> |

**Description**

Consider using OpenZepplin `AccessControl` library for managing rule based access.

## **Issue 02**

| **Type**      | **Severity**                                  | **Location** | **Status**                                     |
| ------------- | --------------------------------------------- | ------------ | ---------------------------------------------- |
| Best Practice | <mark style="color:orange;">**Medium**</mark> | `claim`      | <mark style="color:green;">**Resolved**</mark> |

**Description**

The function call an external contract, exposing itself to potential reentrancy attacks.&#x20;

The code does not follow [check effect interactions](https://fravoll.github.io/solidity-patterns/checks_effects_interactions.html) pattern.&#x20;

**Recommendation**

Add a reentrancy guard or follow check-effect interactions pattern. check-effect interaction pattern is more recommended because reentrancy guard has limitations such us calling other function which has reentrancy guard protection will cause an error. <mark style="color:purple;">**In addition, it's recommended to use check-effects-interact pattern even when using ReentrancyGuard as not all code paths are always protected by it.**</mark>

## **Issue 03**

| **Type**      | **Severity**                                  | **Location** | **Status**                                     |
| ------------- | --------------------------------------------- | ------------ | ---------------------------------------------- |
| Best Practice | <mark style="color:orange;">**Medium**</mark> | `removeAll`  | <mark style="color:green;">**Resolved**</mark> |

**Description**

The `allocators` array's size is limitless. Iterating over an unbounded array may cause the transaction to hit the block gas limit.

**Recommendation**

Add length restrictions on the number of iterations, or if array is not needed consider using mapping \[you already have userInfo which track the allocation].\`

The team add an upper limit for the allocators array, the team need to make sure that this upper limit is enough.&#x20;