Flash loans are a way to borrow large amounts of money for a certain fee. The requirement is that the loans need to be returned within the same transaction in a block. If not, the transaction will be reverted. 

An attacker can use the borrowed money as the initial funds for an exploit to enlarge the profit and/or manipulate the token price in the decentralized exchanges. 

We find that the contract `Calculator` relies on price calculations that are based on-chain, meaning that they would be susceptible to flash-loan attacks by manipulating the price of given pairs to the attacker's benefit. 

Potential Flashloan Attack

In the contract `TradingChef` the role `router` has authority over the functions shown in the diagram below.

Any compromise to the `router` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-TradingChef-router.svg)

In the contract `MasterChef` the role `devaddr` has authority over the functions shown in the diagram below.

Any compromise to the `devaddr` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-MasterChef-devaddr.svg)

In the contract `TradingChef` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-TradingChef-_owner.svg)

In the contract `MasterChef` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.
![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-MasterChef-_owner.svg)

```solidity

```
```solidity

```

Centralization Related Risks

In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-Ownable-_owner.svg)

In the contract `OwnableUpgradeable` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-OwnableUpgradeable-_owner.svg)

In the contract `LockingChef` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-LockingChef-_owner.svg)

In the contract `XoXoToken` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-XoXoToken-_owner.svg)

In the contract `gXoXoToken` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-gXoXoToken-_owner.svg)

In the contract `UniswapV2Factory` the role `feeToSetter` has authority over the functions shown in the diagram below.

Any compromise to the `feeToSetter` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-UniswapV2Factory-feeToSetter.svg)

In the contract `UniswapV2Pair` the role `factory` has authority over the functions shown in the diagram below.

Any compromise to the `factory` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-UniswapV2Pair-factory.svg)

In the contract `UniswapV2Router` the role `WETH` has authority over the functions shown in the diagram below.

Any compromise to the `WETH` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-UniswapV2Router-WETH.svg)

In the contract `UniswapV2Router` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/058ac827f8794a9e8d1bb67f6dec28ae/diagrams/centralization-UniswapV2Router-_owner.svg)

The state variables `claimFeePeriod`, `claimFeeMax`,  `halvingPeriod`, `xoxoPerBlock` etc., can be changed and have no limitations. So they can be set to an arbitrary number.

Key Metrics can be Changed without Limitations

In the contract `XoXoToken`, the role `owner` has authority over the following function:
- function mint(), to mint any amount of tokens only if `totalSupply()` is no more than the `_maxTotalSupply`.

Any compromise to the `owner` account may allow a hacker to take advantage of this authority.

In the contract `gXoXoToken`, the role `owner` has authority over the following function:
- function mint(), to mint any amount of tokens.

Any compromise to the `owner` account may allow a hacker to take advantage of this authority.

Centralization Related Risks in contract `XoXoToken` and `gXoXoToken`

The owner can burn tokens from anyone's wallet to a dead address without approval by function `_burn()` in the contract `gXoXoToken`. This may raise the community's concerns about the centralization issue.

Owner Could Burn Anyone's Token Without Approval

Addresses should be checked before assignment or external calls to make sure they are not zero addresses.

Missing Zero Address Validation

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

Improper Usage of `public` and `external` Type

Both `XoXoToken` and `gXoXoToken` inherited the `ERC20Votes` contract, we would like to confirm if both of these tokens are used for voting. 

The inheritance of `ERC20Votes`

According to the following code:
```solidity
function increaseLockAmount(uint256 _amount) external nonReentrant {
        UserLocking storage user = lockings[msg.sender];
        require(user.principal != 0, "no lock");

        uint256 payout = estimateReward(user.currentTerm, _amount);
        // reduce reward to match to current remaining locking period
        uint256 remainLockSecs = user.releaseTime > block.timestamp ? user.releaseTime.sub(block.timestamp) : 0;
        payout = payout.mul(remainLockSecs).div(terms[user.currentTerm].lockingTerm);
        _updateRewardFor(msg.sender, terms[user.currentTerm].lockingTerm, payout);

        uint256 govPower = estimateGovPower(user.currentTerm, _amount);
        gXoXo.mint(msg.sender, govPower);

        user.principal = user.principal.add(_amount);
        user.govPower = user.govPower.add(govPower);

        xoxo.transferFrom(msg.sender, address(this), _amount);

        emit LockingIncreased(msg.sender, lockings[msg.sender].principal, terms[user.currentTerm].lockingTerm);
    }
```
, the `payout` would be calculated as 0 if `remainLockSecs` is 0. Hence no reward would be paid while the tokens have already been transferred to the contract.

In addition, the locking term has been increased in `_updateRewardFor(msg.sender, terms[user.currentTerm].lockingTerm, payout);`, however, all of the tokens could be redeemed when the previous term ends, which means a user could still claim rewards even if all of the locking tokens have been redeemed.

Logical issue in `increaseLockAmount()`

All of the `estimateGovPower` amounts of `gXoXo` tokens, which are calculated regardless of the time, would be minted in the function `increaseLockAmount()`, hence if a user calls `increaseLockAmount()` at the last second of a locking term, not only all the locking tokens could be redeemed immediately, but also all of the `gXoXo` tokens could be minted.

Logical issue on minting `gXoXo` token

According to the following code:
```solidity
    function increaseLockTime(uint256 _term) external nonReentrant {
        UserLocking storage user = lockings[msg.sender];
        require(user.principal != 0, "no lock");

        uint256 payout = estimateReward(_term, user.principal);
        _updateRewardFor(msg.sender, terms[_term].lockingTerm, payout);

        user.releaseTime = user.releaseTime.add(terms[_term].lockingTerm);

        emit LockingIncreased(msg.sender, user.principal, terms[_term].lockingTerm);
    }
```
, as the lock time increased, the `payout` would also increase. If the locking time increasing occurs when the previous locking time has not been reached, then more rewards could be achieved than expected for the same locking time. As a result, it is possible to achieve more rewards per unit of time by calling this function.

e.g.

If a user locked 10 tokens for 7days, `xoxoPerShare = 0.437*decimal`, the payout would be `0.437*10*7*24*3600*1000/437000 = 6048`, and at the end of the day2, the locking time was increased for another 30days. Totally `6048*2/7 = 1728` rewards tokens would be claimed, the payout would be updated as `6048-1728+0.437*10*30*24*3600*1000/437000 = 30240`. At the end of day32, a total of `30240*30/32 = 28350` rewards tokens could be claimed. As a result, `28350+1728= 30078` rewards tokens for 32days, nearly 940 rewards per day, and all of the locked tokens could be redeemed.

If another user locked 10 tokens for 7days, `xoxoPerShare = 0.437*decimal`, the payout would be `0.437*10*7*24*3600*1000/437000 = 6048`, and at the end of the day7, all of them could be claimed. If the user locked another 30days, the payout would be updated as `0.437*10*30*24*3600*1000/437000 = 25920`. At the end of day32, a total of `25920*25/30 = 21600` rewards could be claimed. As a result, a total of `21600+6048= 27648` rewards tokens for 32days, nearly 864 rewards tokens per day, and all of the locked tokens could not be redeemed until 5 days later.

Discussion on the calculation of `increaseLockTime()`

`updatePool()` function minted 100% + 10% (dev fee is included as 10% of the 100%) of total rewards.

Over Minted Token

According to the `XoXoToken` contract, the cap of `XOXO` token is 30,000,000. As a result, in the contract `TradingChef`, if `xoxoPerBlock` or `block.number-startBlock` is large enough, there may not be enough `XOXO` tokens for the reward, which would lead to the failure when the user attempted to call `takerWithdraw` to claim the reward.

In addition, in the function `safeXoXoTransfer()`, the `balanceOf(address(this))` is added by the `owner`, hence there may not be sufficient tokens in the contract for investors to issue the reward, which would cause the loss.

Insufficient  `XOXO` tokens

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Variables That Could Be Declared as Immutable

In the contract `TradingChef`, users swap tokens in the `_whitelist` to obtain the `XOXO` token. The total reward of a pool grows as the block number increases but is halved every time as the `halvingPeriod` is reached. The amount of rewards a user receives in the contract is determined by the number of swaps and the ratio of `output token` to `targetToken` as well as the transaction amount, and the value of the rewards would be diluted as the number of users' swaps increases. Also, the user could take out the reward after a certain period of time, otherwise, the reward value will be discounted. Due to this complex design, it is difficult for users to predict the actual amount of rewards they will receive.

When the total amount of transactions is large and users are concentrated in one block to withdraw reward, a very large transaction may only earn a small reward. On the contrary, a small transaction can earn more rewards because the total amount of transactions is small.

The economic model is not in the scope of this audit.

Hunny Swap

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

17

0

17

0

0