> 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/locker.sol.md).

# locker.sol

## **Issue 01**

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

**Description**

The functions call external contracts, exposing themselves 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;

```
IBEP20(currentLock.token).safeTransfer(currentLock.owner, releaseAmount);
```

**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.

## **Issue 02**

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

**Description**

Add a message to the `require` statement.

## **Issue 03**

| **Type**      | **Severity**                                  | **Location** | **Status**                                     |
| ------------- | --------------------------------------------- | ------------ | ---------------------------------------------- |
| Logical Issue | <mark style="color:orange;">**Medium**</mark> | `unLock`     | <mark style="color:green;">**Resolved**</mark> |

**Description**

Anyone can call unlock on behalf of the lock owner if they have the lock id.

**Recommendation**

Add a require statement that makes sure only the owner of the lock may call this function.

## **Issue 04**

| **Type**      | **Severity**                             | **Location** | **Status**                                     |
| ------------- | ---------------------------------------- | ------------ | ---------------------------------------------- |
| Logical Issue | <mark style="color:red;">**High**</mark> | `unLock`     | <mark style="color:green;">**Resolved**</mark> |

**Description**

`currentLock.claimed` should be subtracted from `releaseAmount`. Otherwise, users can call the function twice in a row.

**Recommendation**

Add a require statement that makes sure only the owner of the lock may call this function.

## **Issue 05**

| **Type**      | **Severity**                               | **Location**              | **Status**                                     |
| ------------- | ------------------------------------------ | ------------------------- | ---------------------------------------------- |
| Volatile Code | <mark style="color:yellow;">**Low**</mark> | `renounchOwnershipOfLock` | <mark style="color:green;">**Resolved**</mark> |

**Description**

The `userLock` 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.

⚠️ The maximum iterations is limited by 100, however the team need to check that the code doesn't reach block gas limit if the userLock array size is 100.&#x20;