Audits that take no more than 20 days to complete, now start within 10 days 

In the contract `eboxLiquidityLocker`, the role `contractOwner` has authority over the following functions:
- `ownerSetContractPaused()`, which decides whether or not to allow users to create locks, add to locks, extend locks, transfer locks, or withdraw from locks;
- `ownerSetFeeTiers()`, which decides the fees for creating and adding to locks;
- `ownerSetSpecificFeeFor()`, which decides if an address has a fixed fee or not;
- `ownerCollectFee()`, which sends the fees collected to `contractOwner`;
- `ownerSetNewOwner()`, which changes the address of the role `contractOwner`.

Any compromise to the `contractOwner` account may allow a hacker to take advantage of this authority and change as well as collect all fees.

Centralization Related Risks

For users that do not have a specific fee set for them, the fee they pay for creating and adding to a lock is determined by their balance in `feeToken`.

```solidity=126
        for(uint i = feeTiers.length - 1; i > 0; i--)
            if(feeToken.balanceOf(_addr) >= feeTiers[i].minTokenAmount)
                return feeTiers[i].fee;
```

Although users are not able to directly query the fee tiers, they can still go through the transaction history to see the thresholds and amount of fees for each fee tier. This means that users may be able to decrease the amount of fees they pay by acquiring or lowering their `feeToken` balance.

Potential Fee Manipulation

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the amount locked will be different from the amount received.

For example, if we consider a deflationary token with a 10% fee and a user locks 100 tokens, then the contract will only receive 90 but create a lock for 100 tokens less the lock fee. Depending on the lock fee, the user may be unable to withdraw their locked tokens if the contract's balance is too low.

Incompatibility With Deflationary Tokens

The linked `transfer()`/`transferFrom()` invocations do not check the return value of the function call which should yield a `true` result in case of a proper ERC-20 implementation.

```solidity=152
        _token.transferFrom(msg.sender, address(this), _value);
```
```solidity=169
        allLocks[_index].token.transferFrom(msg.sender, address(this), _value);
```
```solidity=209
        allLocks[_index].token.transfer(msg.sender, _value);
```
```solidity=271
            _tokens[i].transfer(msg.sender, value);
```
The aforementioned lines perform external calls to `transferFrom` of ERC20 contracts and the return value is not checked in either case.

Unchecked Value of ERC-20 `transfer()`/`transferFrom()` Call

Users withdraw from a lock through the function `lockRelease()` and are able to withdraw the entire amount in the lock if they choose to withdraw 0.

```solidity=205
        if(_value == 0)
            _value = allLocks[_index].value;
        allLocks[_index].value -= _value;
```

However, they are not able to withdraw the entire amount if the inputted withdraw value is the lock's amount.

```solidity=203
        require(allLocks[_index].value > _value, "release value too high");
```

Emptying a Lock

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. 
If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. 

In the updated functions `lockCreate()` and `lockAdd()`, the token transfer is done between checking the contract's balance for compatibility with deflationary tokens.

```solidity
        uint oldBalance = _token.balanceOf(address(this));
        _token.transferFrom(msg.sender, address(this), _value);
        _value = _token.balanceOf(address(this)) - oldBalance;
```

As the address of `_token` is decided by the user, this address may be a malicious contract that reenters the functions `lockCreate()` or `lockAdd()`. Doing so may inflate the user's locked value.

For example, suppose a user calls `lockCreate()` and locks 100 tokens. Then we expect `_value = 100`. Assume that `_token.transferFrom()` reenters and calls `lockCreate()` to create a lock for 100 tokens before the transferring tokens. 

The reentrancy call will create a lock for 100 tokens so currently, `_token.balanceOf(address(this)) = oldBalance + 100`. Once that is resolved, another 100 tokens will be transferred to this contract, so `_token.balanceOf(address(this)) = oldBalance + 200`. Then `_value = 200`.

Hence two locks were created: one for 100 tokens and another for 200 tokens, but only 200 tokens were transferred to this contract.

Potential Reentrancy Attack

When a user withdraws from a lock, a check is made on the lock's release time to see if the lock has expired,

```solidity=201
        require(allLocks[_index].releaseTime < block.timestamp, "lock is not expired yet");
```

However, if the release time is equal to the current block's timestamp, then the lock is not considered expired, when it should be.

Release Lock Time

The contract owner can decide the fee tiers through the function `ownerSetFeeTiers()` and from looking at the function `getFeeFor()`, it is clear that these fee tiers have to be sorted:

```solidity=126
        for(uint i = feeTiers.length - 1; i > 0; i--)
            if(feeToken.balanceOf(_addr) >= feeTiers[i].minTokenAmount)
                return feeTiers[i].fee;
```

However, there are no checks in `ownerSetFeeTiers()` that guarantees this.

Fee Validation Checks

The following functions affect the status of sensitive variables and should be able to emit events as notifications:
- `lockAdd()`
- `lockExtend()`
- `lockRelease()` (for partial withdrawals)
- `ownerSetContractPaused()`
- `ownerSetFeeTiers()`
- `ownerSetSpecificFeeFor()`
- `ownerCollectFee()`
- `ownerSetNewOwner()`

Missing Emit Events

ebox Liquidity Locker

ethbox

projects

contracts

eboxLiquidityLocker.sol

SafeMath is unused

Missing the input validation

ethbox provides a smart contract based digital escrow service to completely alleviate any risk of loss while sending cryptocurrency.

Ebox

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

9

0

2

1

6