<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

Function `withdraw()` tallies the `totalCanRelease` and `totalCanReleaseNoFee` values from all `ids` used in withdraw and as long as one is 0, allows the stake to be collected for each amount. In the case where all stakes listed in `ids` are `pledge_2` type, the `totalCanRelease` value will be 0. 

In this case, the `totalCanRelease` value is still used in call to `removeLiquidity()` in the `exchagneSwap` contract. This contract calls a router's `removeLiquidity()` function. In the case where pair contracts associated with this router behave like pancakeswap, the `burn()` function called in `removeLiquidity()` will expect a nonzero value of both `usdtAddress` and `freeAddress`. However, since the totalCanRelease` is 0, these converted values will also be 0, causing a revert.

As a result, those users who exclusively have stakes in `pledge_type` 2 will be unable to retrieve their stakes.

`pledge_type` 2 Only Calls Will Always Revert on `withdraw()`

If a user stakes with the same function more than once in the same transaction, their first stake will be overwritten with the information of the second stake in the corresponding mapping `informations`, while the same `id` will be pushed twice to `allKey`, and the `lpAmount` for the user will be updated with the same amount twice. This makes the user's first stake inaccessible, and as a result, they lose the funds they stake permanently.

This issue is most prevalent in function `stakeLP()`; it is less likely to be a problem in `stakeWithUSD()` where the `liquidity` is unlikely to be the same after the first call. This is still a possibility that should be prevented. 

The function `reStake()` will produce the same `newID` value if two different `_id` inputs are called consecutively both with the same `info.lockAmount`.

Staking Ids are not unique

Function `stakeLp()` can be called by anyone, for any amount, and it will be recorded that they have deposited a stake, even though the function does not transfer a stake from the user.

- If the user specifies a `_type` of 3 for the call, they can immediately withdraw all funds.
- If the user specifies a `_type` of 2 for the call, then they can immediately start collecting LP tokens from the contract through the `withdraw()` function, so they may take all user's funds from the contract early in the withdraw process by recording a large enough `amount` for the stake.
- The stake can be used in the `reStake()` function to continue to take funds after 100 days.

Function `stakeLp()` Does Not Collect a Stake From User 

```solidity
        IBEP20(fptAddress).transferFrom(msg.sender, address(1), amount);  // transfer fpt to address(1)
        IBEP20(freeAddress).transferFrom(poolAddress, address(this), amount.div(100)); //transfer free in
        IBEP20(usdtAddress).transferFrom(msg.sender, address(this), uAmount); // transfer usdt in 

        uint minA = amount.mul(87).div(100);
        uint minB = uAmount.mul(87).div(100);
        IBEP20(freeAddress).approve(exchagneSwap, amount);
        IBEP20(usdtAddress).approve(exchagneSwap, uAmount);
        (,, uint liquidity) = IExchangeSwap(exchagneSwap).addLiquidity(freeAddress,usdtAddress,amount,uAmount,minA,minB, address(this), block.timestamp.add(3600));
```

Function `stakeWithUSD()` transfers the `amount` input of `fptAddress` from the `msg.sender` to `address(1)`. The logic then transfers the `freeAddress` token from the `poolAddress` (set as `address(0)` currently) to `address(this)` in the amount of `amount.div(100)`.

Additionally, a `uAmount` of `usdt` is transferred from the `msg.sender` to `address(this)`.

The function logic then proceeds to approve the contract `exchagneSwap` to move an `amount` of `freeAddress`, even though, at most, the contract just transferred in `amount.div(100)` of `freeAddress` token.

There are several issues with this set up that need to be addressed.

1. The contract is approving the the transfer of an `amount` of `freeAddress` token that it did not receive from any source. At most, it received 1/10 of this value.
2. The `freeAddress` token is coming from a `poolAddress` source instead of from the `msg.sender`. This means the user does not have to offer any `freeAddress` tokens themselves.
3. The `fptAddress` token is transferred from the `msg.sender` to `address(1)`; the `fptAddress` token does not appear to be a part of the specification for this function and sending this amount to `address(1)` effectively removes the token from circulation since this address is not owned by anyone.
4. The `uAmount` calculated is based off the input `amount` but uses the `reserve0` and `reserve1` values in its conversion. Value `amount` is the amount of `fptAddress` token and cannot be explicitly converted using the reserves of `freeAddress` token in the `lpAddress` pair.

Misrepresented Amounts of Pair Tokens When Creating Liquidity

```solidity
        uint minA = amount.mul(87).div(100);
        uint minB = uAmount.mul(87).div(100);
        IBEP20(freeAddress).approve(exchagneSwap, amount);
        IBEP20(usdtAddress).approve(exchagneSwap, uAmount);
        (,, uint liquidity) = IExchangeSwap(exchagneSwap).addLiquidity(freeAddress,usdtAddress,amount,uAmount,minA,minB, address(this), block.timestamp.add(3600));
```

The `Free_Pledge` contract is transferred an `amount` of `freeAddress` token and a `uAmount` of `usdtAddress` token to create lp tokens to be staked. However, it calculates that a minimum of 87% of each expected to be used in the call to `addLiquidity()`. If the minimum is achieved, the remainder of `free` and `usdt` stay in the `Free_Pledge` contract and are neither returned to the staker nor used in the recorded stake. In such a case, a significant amount of both tokens may be left in the contract.

Users may be subject to front-running attacks where the price is manipulated so that the minimum of 87% is met, the remainder is locked in the `Free_Pledge` contract.

Swap in Stake May Not Use Full Transfer

Currently the following line is commented out of function `currentWithdrawal()`:

```solidity
  // IBEP20(lpAddress).transfer(msg.sender, amount);
```

Without this line in the function logic, the function updates the recorded state of the stake, setting the `status` to 2, without returning a user's initial stake amount.

This prevents a user from ever getting their stake returned.

Commented Out Transfer

Calculation for uint `d` is days in *seconds* while `releaseDays` is a number of days (in days, not seconds).

```solidity=257
    uint public releaseDays = 4  * 365;
```

```solidity=286
        uint d = getTime(block.timestamp).sub(getTime(latestReleaseTime));
        require(d > 0,"not ready");
        uint release = totalAmount.mul(d).div(releaseDays);
```

If `releaseDays` is left as `4 * 365 = 1460`, then only one day must pass before the `userAddress` can collect the `totalAmount` of `free` tokens. This is because `d` will be `86400`, making the `release` amount more than 100% of the `totalAmount`. 

Incompatible Time Units

All `Free` and `fpt` tokens are sent to `msg.sender` when deploying each contract. This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

Initial Token Distribution

### Release.sol

In the contract `LockRelease` the role `userAddress` has authority over the functions shown in the diagram below.
Any compromise to the `userAddress` account may allow the hacker to take advantage of this authority and accumulate a large portion of the protocol's `free` token.

![](https://accelerator-tasks-prod.s3.amazonaws.com/6db31adf454042b49cde027947e65ede/diagrams/centralization_Release-LockRelease-userAddress.svg)

### exchange_swap.sol

In the contract `ExchangeSwap` 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 and incorrectly set a `path` used in making a swap through the `router` of the contract, or
-  remove the `free` token address as a `whitelisted` address, preventing `transferFrom()` logic from being called correctly.

![](https://accelerator-tasks-prod.s3.amazonaws.com/6db31adf454042b49cde027947e65ede/diagrams/centralization_exchange_swap-ExchangeSwap-_owner.svg)


In the contract `ExchangeSwap` the role `isWhitelisted` has authority over the functions shown in the diagram below.
Any compromise to the `isWhitelisted` account may allow the hacker to take advantage of this authority and use the `swap()` function in an unexpected way.
![](https://accelerator-tasks-prod.s3.amazonaws.com/6db31adf454042b49cde027947e65ede/diagrams/centralization_exchange_swap-ExchangeSwap-isWhitelisted.svg)


### free.sol

In the contract `Free` 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 and 
- set `masxwap` to 0, preventing users subject to fees from transferring;
- use `setLp()` to set the `lpAddress` to a non-corresponding address, if `lpAddress` has not already been set to a nonzero address.
- update `NeedFeeAddress`, `NoFeeAddress`, and `setSwapAddress` in such a way that unintended addresses are subject to fees, causing issues with the protocol, or update the state in such a way that their own addresses are not subject to fees during transfers;
- update the `buyFeeRate` and `sellFeeRate` to values as high as 40% and 100% respectively. We note, by default, this is what the values are set as in the contract;
- update the `exchangeSwapAddr` to a malicious contract which performs reentrancy, makes unexpected updates, or does not work, preventing users from transferring their tokens.

Additionally, since the `_owner` is the deploying address, the `_owner` is minted an initial distribution of `free` tokens. Any compromise to the `_owner` account may allow the hacker to use the tokens in exchange for usdt in the `free`-usdt pair address used within the protocol, or else use a large amount of `free` to manipulate the price stake a larger amount of lp tokens in the `Free_Pledge` contract for less usdt.

![](https://accelerator-tasks-prod.s3.amazonaws.com/1ebdfcb4ed0f45c0879f295381cc44a7/diagrams/centralization_Free-Free-_owner.svg)

![](https://accelerator-tasks-prod.s3.amazonaws.com/6db31adf454042b49cde027947e65ede/diagrams/centralization_free-Ownable-owner.svg)


### pledge.sol


In the contract `Free_Pledge` 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 and

- set the `stakeFeeRate` to be as high as a value of 100 which is a 10% fee in `stakeWithUSD()` that is used to transfer `free` token from the `msg.sender` to the `daoAddress`.
- set the `releaseRate` to be as high as a value of 100 which represents a 10% fee. It is noted that this is the starting `releaseRate` by default, and the worst an attacker could accomplish is to set fees to be the original default rate or lower.
- set the `burnRate_lp` to be as high as a value of 100 which represents a 10% fee. It is noted that this is the starting `releaseRate` by default, and the worst an attacker could accomplish is to set fees to be the original default rate or lower.

![](https://accelerator-tasks-prod.s3.amazonaws.com/451b523203cb4b79b26abc8bd1989eac/diagrams/centralization_pledge-Free_Pledge-_owner.svg)

![](https://accelerator-tasks-prod.s3.amazonaws.com/5a6429cfe5c24080b90e33d8da5f306c/diagrams/centralization_pledge-Ownable-_owner.svg)

Centralization Related Risks

As long as an `_id` for a stake has a `status` of 1, and 100 days have passed since the stake was created, a user can call `reStake()` on the `_id` and get a `newID` created for the same `lockAmount`, with a `_type` of 2, meaning that the user can immediately start withdrawing Lp tokens from the stake one day later.

In the case where the original stake `_id` is of `_type` 2 or 3, the `status` is not updated until the total to be released is equal to the `lockAmount`. Further note that `lockAmount` is fixed from the creation of the stake for the `_id`, so it is never reduced. 

A user with stake type 3 can immediately withdraw all but 1 token of the `lockAmount` so that `status` remains 1, then wait 100 days and use the `_id` for this stake to create a `newID` in `reStake()` of the same `lockAmount` without further depositing more LP tokens to the contract.

A user with stake type 2 can withdraw most of their stake, so that the `status` is still 1, wait 100 days, then call `reStake()` without further depositing more LP tokens to the contract.

Since `reStake()` creates stakes of `_type` 2, the user can continue to perform this exploit for as long as it is profitable.

Users Can `reStake()` withdrawn stakes

The function `stakeWithUSD()` includes the following commented documentation:

```solidity
    /**
    *  @dev stake with usdt,  it will burn fpt , and exchange free out , use free + usdt add liquidty the swap pool.
    *  exchange rate 100 : 1
    *  amount input amout is the number of fpt, 
    *  _type it for stake type
    */
```

Where the function logic makes an assumption that the worth of `fpt` in relation to `free` tokens is 100 to 1 based on their initial supplies.

1. The initial supply of `fpt` is `8_000_000_000_000 ether`, according to its contract while the initial supply of `free` is `84_000_000 * (10 **_decimals)`, making the actual initial ratio out to be 95238:1
2. Even if pairs are set up in an exchange that initially match this worth, the worth can change depending on demand over time. With this in consideration, the hardcoded assumption in the logic that the worth of fpt to free is always 100 to 1 may result in the protocol or the users losing funds through an unchanging conversion and may allow for opportunities of bad arbitrage using this contract.
3. Each token can be burned. This affects the ratio of supplies over time.

The worth of of `fpt` to `free` is Not Fixed

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction.

Reference:
https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f

---
```solidity=268
        totalAmount = 4_000_000 ether;
```

```solidity=289
        if (release + releaseAmount >= totalAmount){
            release = totalAmount - releaseAmount;
        }
        IERC20(freeAddress).transfer(userAddress, release);
        releaseAmount = releaseAmount.add(release);
```

The logic of `Release.sol` expects that the `totalAmount` is present as a balance in the contract. If someone sends the `totalAmount` to the contract and they are subject to fees, then the received amount by the Release contract will be less than the `totalAmount`. If the `release + releaseAmount` is at least the `totalAmount when function `release()` is called, then adjusting `release` to `totalAmount - releaseAmount` may cause the function to revert, since the contract did not hold the `totalAmount` of `free` tokens. As such, one would have to "donate" more tokens to the contract just to remove the final remaining amount.

---

```solidity=704
      IBEP20(lp).transferFrom(msg.sender, address(this), liquidity);
```
- Transferring tokens by `liquidity`.

```solidity=706
      (uint a, uint b) = ISwap(routerAddress).removeLiquidity(tokenA,tokenB,liquidity,amountAMin,amountBMin,address(this),deadline);
```
- The `liquidity` appears to be used for bookkeeping purposes without compensating the potential transfer fees.
- Note: `removeLiquidity` is an external function and its behavior wasn't evaluated.


---
```solidity=541
        IBEP20(fptAddress).transferFrom(msg.sender, address(1), amount);  // transfer fpt to address(1)
```
- Transferring tokens by `amount`.

```solidity=549
        (,, uint liquidity) = IExchangeSwap(exchagneSwap).addLiquidity(freeAddress,usdtAddress,amount,uAmount,minA,minB, address(this), block.timestamp.add(3600));
```
- The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.
- Note: `addLiquidity` is an external function and its behavior wasn't evaluated.


Incompatibility with Deflationary Tokens

### Hardcoded Init Code Hashes
In files `pledge.sol` and `exchange_swap.sol`, there are multiple different init code hashes being hardcoded to presumably interact with the same pancakeswap pair factory system. If this is the case, the correct value needs to be determined and used unilaterally to ensure that the correct pair address is returned in the call to `pairFor()`.

### Hardcoded Addresses
- In `pledge.sol`, addresses `fptAddress`, `poolAddress`, `exchagneSwap` and `daoAddress` are all coded as `address(0)`, currently making the set up unusable. We recommend including input parameters in the `constructor` to set these addresses at the time of deployment, and adding checks that none of the inputs are `address(0)`.
- In `free.sol`, addresses `foundationAddress`, `lpPool`, and `usdtAddress` are all set as `address(1)`, which is an unowned external account, and currently causes any fees to be "burned", with inaccurate events emitted after. We recommend including input parameters in the `constructor` to set these addresses at the time of deployment, and adding checks that none of the inputs are `address(0)`
- In `exchange_swap.sol`, a `routerAddress` and `factory` address are hardcoded in the contract. These addresses do not appear to match deployed contract addresses on BNB Chain. We recommend either ensuring the correct values are set before deployment or adding input parameters to the constructor for setting these values on deploy.

### Hardcoded Values
- In `pledge.sol`, uint variable `stepTime` is hardcoded as `1 minutes` with a comment that states

  ```solidity
   // test set to 1 minutes, for stable use set to 1 days
  ```

  As set, the value is not compatible with the other logic in the contract. We recommend updating the value to its intended value of `1 days` during testing to ensure compatibility of logic.

- In `exchange_swap.sol`, function `swap()` includes the hardcoded value `0xa0` in the `amountOutMin` of the call to `swapExactTokensForTokens()`. This value is hardcoded as 160. This leaves the swap vulnerable to sandwich attacks.

Hardcoded Values

A sandwich attack may happen when an attacker observes a transaction swapping tokens or adding/removing liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (executing before the target) a transaction to purchase one of the assets and make profits by backrunning (executing after the target) a transaction to sell the asset.

The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large:

```solidity
            (uint a, uint b) = IExchangeSwap(exchagneSwap).removeLiquidity(usdtAddress, freeAddress, totalCanRelease, 0, 0, address(this), block.timestamp.add(100));
```

```solidity
        return ISwap(routerAddress).swapExactTokensForTokens(amount,0,path,to,time.add(3600));
```

Potential Sandwich Attacks

Function `burnWithdraw()` does not take into account the possibility that a user may call the function later than the `releaseTotalDay` value, instead of earlier than this value.

If a user calls this function where `stake_days` is larger than `releaseTotalDay`, if the `pledge_type` is 1, then the call to `calculateBurnWithdraw()` transfers  to the `msg.sender` an `amount` of `freeAddress` token calculated as:

```solidity
uint amount = b.sub(feeB).mul(stake_days).div(releaseTotalDay);
```

where `amount` is over 100% of `b.sub(feeB)`, which is the amount of `freeAddress` returned to the contract in exchange for lp tokens burned, minus a fee. It is noted that such a manipulation would be likely to revert, unless the call is made while there is an extra amount of `freeAddress` token stored in the contract. This issue can occur for stakes of type 1, 2, or 4.

Miscalculation in Function `burnWithdraw()` when  stake `pledge_type`  is 1

Function `withdraw()` allows a user to withdraw portions of their stake based on the time passed, if the `type` is 2.

However, if a user calls function `withdraw()` frequently, less than one day apart between calls, then value `d` will be 0, meaning the user will not get back any portion of their stake, but each time, `latestReleasedTime` will be updated to `block.timestamp`.

Each time this happens, the user is pushing back the next time a portion of their reward will be eligible for withdraw, without receiving anything in return.

In this way, a user may accidentally interact with this function too frequently and keep themselves from unlocking their reward in a timely manner.

Users Can Call `withdraw()` too frequently when `type` is 2

Addresses should be checked before assignment or external call to ensure they are not zero addresses.

```solidity=265
        freeAddress = free;
```
- `free` is not zero-checked before being used.


---
```solidity=266
        userAddress = user;
```
- `user` is not zero-checked before being used.


---
```solidity=400
      exchangeSwapAddr = exchangeSwapContract;
```
- `exchangeSwapContract` is not zero-checked before being used.


---
```solidity=677
    lpAddress = addr;
```
- `addr` is not zero-checked before being used.


---
```solidity=466
        lpAddress = lp;
```

```solidity=475
        lpAddress = lp;
```
- `lp` is not zero-checked before being used.


---
```solidity=472
        usdtAddress = uAddr;
```
- `uAddr` is not zero-checked before being used.


---
```solidity=473
        freeAddress = free;
```
- `free` is not zero-checked before being used.



Missing Zero Address Validation

The return value of the transfer()/transferFrom() call is not checked.

```solidity=292
        IERC20(freeAddress).transfer(userAddress, release);
```


---
```solidity=691
      IBEP20(tokenA).transferFrom(msg.sender,address(this), amountA);
```


---
```solidity=692
      IBEP20(tokenB).transferFrom(msg.sender,address(this), amountB);
```


---
```solidity=704
      IBEP20(lp).transferFrom(msg.sender, address(this), liquidity);
```


---
```solidity=707
      IBEP20(tokenA).transfer(to, a);
```


---
```solidity=708
      IBEP20(tokenB).transfer(to, b);
```


---
```solidity=541
        IBEP20(fptAddress).transferFrom(msg.sender, address(1), amount);  // transfer fpt to address(1)
```


---
```solidity=542
        IBEP20(freeAddress).transferFrom(poolAddress, address(this), amount.div(100)); //transfer free in
```


---
```solidity=543
        IBEP20(usdtAddress).transferFrom(msg.sender, address(this), uAmount); // transfer usdt in
```


---
```solidity=710
        IBEP20(usdtAddress).transfer(daoAddress, aFee);
```


---
```solidity=711
        IBEP20(freeAddress).transfer(daoAddress, bFee);
```


---
```solidity=714
        IBEP20(usdtAddress).transfer(msg.sender, a.sub(aFee));
```


---
```solidity=715
        IBEP20(freeAddress).transfer(msg.sender, b.sub(bFee));
```


---
```solidity=718
        IBEP20(lpAddress).transfer(msg.sender, totalCanReleaseNoFee);
```



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

### `pledge.sol`
- In the constructor of `Free_Pledge`, there are no checks that the `fptAddress`, `freeAddress`, `usdtAddress`, `poolAddress`, `lpAddress`, and `exchagneSwap` addresses are set in a way that is compatible with one another. Specifically, `usdtAddress` and `freeAddress` should compose the tokens of the pair `lpAddress` in the `factory` used in `exchagneSwap`. This should be confirmed through checks in the code when set.
- In function `stakeLp()` and `stakeWithUSD()` there is no check that `amount` is nonzero.
- In function `stakeWithUSD()` there is no check that `reserve0` and `reserve1` are nonzero. If they are, the division by either reserve value will revert without a specific error message.
- In function `checkUserRelease()`, there is no check for `_type` 1 that `getTime(block.timestamp)` is at least as large as `getTime(users[addr].informations[_id].latestReleasedTime)`. In such a case, the function will revert due to underflow without a specific error message.
- In function `withdraw()`, there is no check for `_type` 2 that `d = getTime(block.timestamp)` is at least as large as `getTime(users[msg.sender].informations[ids[i]].latestReleasedTime)`. In such a case, the function will revert due to underflow without a specific error message.

### `free.sol`
- In function `setMaxSwap()` there is no check that `amount` lies between a predetermined range of values. If `maxswap` is set at 0, users who are subject to fees cannot transfer while users that are not subject to fees can transfer.

### `Release.sol`
- The constructor is missing a check that `releaseYears` is positive. If the value is 0, then the `Release()` function reverts due to division by zero (`releaseDays` set as zero).

Missing  Input Validation

The `fpt` contract includes a `burn()` function which anyone can call on their own balance at any time, and they receive nothing in return. 

In the `stakeWithUSD()` function of contract `Free_Pledge`, the token is "burned" in exchange for `free` tokens.

Users receive Nothing for Directly Burning `fpt`

In contract `Free` there are several different mappings, `swapAddress`, `needFeeAddress`, and `noFeeAddress` which are used in determining which transfers have fees applied.

Please confirm the following is the planned set up.

### Current Known Documentation

- set `needFeeAddress` as `true` for  `lpAddress`;
- set `noFeeAddress` as `true` for `exchangeSwapAddr`;
- set `swapAddress` as `true` for `lpAddress` and `exchangeSwapAddr`;

It is noted that `exchangeSwapAddr` must be set as `true` for `noFeeAddress`, or else the call to `swapExactTokensForTokens()` will not work properly in the function `swap` of the `ExchangeSwap` contract.

Additionally, please provide further documentation on the planned settings for the following addresses:
- `lpPool`;
- `foundationAddress`;
- `usdtAddress`;
- the `router` listed in the `exchangeSwapAddr`;

Please also provide more information on what `lpPool` is meant to represent. If this is a pair address, sending tokens directly to a pair contract allows anyone to skim the tokens from the pair.

The current mechanic is set up so that fees are *not* taken in `transfer()` unless the `_msgSender` is set to true in the `needFeeAddress` mapping. On the other hand, function `transferFrom()` takes fees by default from a `sender` address.

Please provide more information on when fees are supposed to be taken during transfers.

Documentation Needed for Handling of Fees in `Free` Contract

The addresses hardcoded in the deployed `Free` contract for `foundationAddress` and `lpDaoAddress` are not currently owned by anyone on BSC.


- `Free` deployed contract: [0xf24b77009815158b4d6b27f7145c7e14f28a9f43](https://bscscan.com/address/0xf24b77009815158b4d6b27f7145c7e14f28a9f43#readContract);
- `foundationAddress`: [0x410767adbac6d2f24a8f1684fd8bfacb10c6b5b1](https://bscscan.com/address/0x410767adbac6d2f24a8f1684fd8bfacb10c6b5b1);
- `lpDaoAddress`: [0x0f12602a41b5903b16bea30cbf062bec517e0d9e](https://bscscan.com/address/0x0f12602a41b5903b16bea30cbf062bec517e0d9e)

Unowned Account Addresses

### `Free_Pledge`

There is no requirement on the `amount` specified in `stakeWithUSD()` or `stakeLp()`. As such, a low enough value may cause the cited values to round down to an imprecise value through division.

Truncation by Division

Function `withdraw()` Allows a `type` 3 stake to be included in the `ids` input array. If a stake `id` is of type 3, no updates are made in the `for` loop based on the id. However, in the case where other types are included, one of `totalCanRelease` or `totalCanReleaseNoFee` may be nonzero and the transaction may successfully execute. A user may think their `type` 3 stake has been withdrawn.

Function `withdraw()` also allows for the inclusion of stakes the `msg.sender` does not own (in this case the `status` is 0) and stakes which have a `status` of 2. In both cases, the `for` loop logic skips over these `ids` entries.

Function `withdraw()` Allows Inclusion of `type` 3 stakes and Fake Stakes in `ids`

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.

### External call(s)
```solidity=292
        IERC20(freeAddress).transfer(userAddress, release);
```

### State variables written after the call(s)
```solidity=294
        latestReleaseTime = block.timestamp;
```

```solidity=293
        releaseAmount = releaseAmount.add(release);
```


This finding is set as minor since the `freeAddress` is presumed to be the `Free` contract within the scope of this audit. If any other token address is used for the `freeAddress` it may be possible to perform reentrancy and drain all funds from the contract immediately. In general, the `transfer()` logic can be added to the end of the function to prevent this.

Potential Reentrancy Attack (Sending Ether or Token)

- The uint `releaseDays` is initialized as `4 * 365`, but is then updated to another value based on input `releaseYears` in the constructor. We recommend choosing one method and removing the other.
- Input `totalAmount` is unused in the constructor. Instead, state variable `totalAmount` is hardcoded in the constructor as `4_000_000 ether`. The state variable `totalAmount` was already initialized at this value and does not need to be set in the constructor if it is not to be updated on deploy.
- `public` visibility in the constructor is ignored by the compiler and can be removed.

Constructor Inconsistencies in `Release.sol`

Function `setFeeRate()` uses a uint `i` as follows:

- If `i` is 0, the input `rate` sets the `buyFeeReate` state.
- For all other values of `i`, the input `rate` sets the `sellFeeRate`.

Since there are two possible options for update, a `bool` can be used with the `if-else` logic instead.

Type `uint` Can Be Replaced By Type `Bool`

State variables that never change should be declared as `constant` to save gas.

```solidity=256
    uint public totalAmount = 4_000_000 ether;
```
- `totalAmount` should be declared `constant`.


---
```solidity=259
    uint public stepTime = 1 days;
```
- `stepTime` should be declared `constant`.


---
```solidity=593
    address routerAddress = 0x2e4808F821E8418427027b9259bBe87f212D8bEf;
```
- `routerAddress` should be declared `constant`.


---
```solidity=596
    address factory = 0x7D978090C706605F3109e41aCF0b39F9B905679b;
```
- `factory` should be declared `constant`.


---
```solidity=354
  address public _mintAddress = address(0);
```
- `_mintAddress` should be declared `constant`.


---
```solidity=384
  address public foundationAddress = address(1);
```
- `foundationAddress` should be declared `constant`.


---
```solidity=385
  address public lpPool = address(1);
```
- `lpPool` should be declared `constant`.


---
```solidity=386
  address public usdtAddress = address(1);
```
- `usdtAddress` should be declared `constant`.


---
```solidity=453
    uint public stepTime = 1 minutes;   // test set to 1 minutes, for stable use set to 1 days
```
- `stepTime` should be declared `constant`.



State Variable Should Be Declared Constant

One or more parameters with `memory` data location are never modified in their functions and those functions are never called internally within the contract. Thus, their data location can be changed to `calldata` to avoid the gas consumption copying from calldata to memory.

```solidity=655
    function setPaths(address tokenContractAddress, address[]memory path) public onlyOwner{
```
`setPaths` has memory location parameters: `path`.

---
```solidity=647
    function withdraw(bytes32 [] memory ids) public returns(uint,uint){
```
`withdraw` has memory location parameters: `ids`.


Inefficient Memory Parameter

One or more state variables are never used in the codebase.

- Variable `whitelist` of contract `Free_Pledge` is never used in `Free_Pledge`.

- Mapping `isWhitelisted` of contract `Free_Pledge` is updated in the constructor but never used in `Free_Pledge`.

- Variable `d` in the struct `LockInformation` of contract `Free_Pledge` is never used within the struct.

- Variable `startTime` of contract `Free_Pledge` is initialized but never used in the contract.

- Variable `isInitialized` of contract `Free_Pledge` is initialized but never used in the contract.

- Variable `isInitialized` of contract `Free` is initialized but never used in the contract.

- Variable `lpAddress` of contract `Free` is initialized but never used in the contract.

- Variable `_mintAddress` of contract `FPC` is set as `address(0)` and is unused in the contract.

Unused State Variables

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

The linked functions are equivalent to the compiler-generated getter functions for the respective variables.

User-Defined Getters

In the constructor of contract `Free_Pledge`, address `lpAddress` is set twice.

`lpAddress` is Set Twice in Constructor

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.

### External call(s)
```solidity=511
            uint256[] memory amounts = IExchangeSwap(exchangeSwapAddr).swap(address(this), fee.div(2), foundationAddress);
```

```solidity=514
            amounts = IExchangeSwap(exchangeSwapAddr).swap(address(this), fee.div(2), lpPool);
```

### State variables written after the call(s)
```solidity=516
            _transfer(sender, recipient, amount.sub(fee));
```
* This function call executes the following assignment(s).
* In `Free._transfer`,
    * `_balances[sender] = _balances[sender].sub(amount,"BEP20: transfer amount exceeds balance")`
* In `Free._transfer`,
    * `_balances[recipient] = _balances[recipient].add(amount)`

This finding is set as informational because the reentrancy can only occur if the addresses involved in the external call are compromised via a compromised privileged account. In general, following the check-effect-interactions pattern (linked below) can prevent some of the risk.

Potential Reentrancy Attack

Variable `_decimals` in contract `Free` is `public` and is a `uint256`. Since it is public, a default public getter function is created for it, where the return value is of type `uint256`. The [EIP-20](https://eips.ethereum.org/EIPS/eip-20#specification) specifies that the `_decimals` for an ERC20 should be type `uint8`.

`_decimals` Does Not Meet Specification of EIP-20

Solidity frequently releases new compiler versions. Using an old version prevents access to new Solidity security features and may expose the code to known bugs in the compiler version. See the documentation at the following link for a full list of currently known bugs in old compiler versions:

https://solidity-fr.readthedocs.io/fr/v0.8.12/bugs.html


Solidity Version Not Recommended

A local variable is shadowing another component defined elsewhere.

```solidity=263
    constructor(address free, address user, uint totalAmount, uint releaseYears, string memory n)public{
```
- Local variable `totalAmount` in `LockRelease.constructor` shadows the variable `totalAmount` in `LockRelease`.


---
```solidity=423
  function allowance(address owner, address spender) external view returns (uint256) {
```
- Local variable `owner` in `FPC.allowance` shadows the function `owner` in `Ownable`.


---
```solidity=557
  function _approve(address owner, address spender, uint256 amount) internal {
```
- Local variable `owner` in `FPC._approve` shadows the function `owner` in `Ownable`.


---
```solidity=475
  function allowance(address owner, address spender) external view returns (uint256) {
```
- Local variable `owner` in `Free.allowance` shadows the function `owner` in `Ownable`.


---
```solidity=625
  function _approve(address owner, address spender, uint256 amount) internal {
```
- Local variable `owner` in `Free._approve` shadows the function `owner` in `Ownable`.



Shadowing Local Variable

```solidity=194
        for (uint256 i; i < path.length - 1; i++) {
```
- Local variable `i` is never initialized.

---
```solidity=381
        for (uint i; i < path.length - 1; i++) {
```
- Local variable `i` is never initialized.


Uninitialized Local Variable

The **require** statement can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing Error Messages

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

Redundant Code Components

### Contract `Free_Pledge`

Function `reStake()` in `Free_Pledge` updates `latestReleasedTime` by setting as the following

```solidity
        users[msg.sender].informations[newID].latestReleasedTime = block.timestamp + stepTime;
```

The compiler version is currently set at 0.5.17 and if the sum exceeds the maximum value, overflow will occur.

This finding is set as informational since the scenario is unlikely to happen unless `stepTime` is updated to an extremely large value before deploying the contract.

### Contract `Free`

The constructor of contract `Free` calculated `_totalSupply` without the use of SafeMath.

The compiler version is currently set at 0.5.17 and if the sum exceeds the maximum value, overflow will occur.

The finding is set as informational since the scenario is unlikely to happen unless the `_totalSupply` value is updated before deployment.

Missing Use of SafeMath

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.

*This finding is considered informational because an issue only occurs if the addresses set by the deployer become compromised, or are set to addresses which do not meet their description. For instance, it is assumed `usdtAddress` describes the use of well-known usdt, and that `freeAddress` describes the token contract in scope of this audit.*

### External call(s)
```solidity=511
            uint256[] memory amounts = IExchangeSwap(exchangeSwapAddr).swap(address(this), fee.div(2), foundationAddress);
```

```solidity=514
            amounts = IExchangeSwap(exchangeSwapAddr).swap(address(this), fee.div(2), lpPool);
```

### State variables written after the call(s)
```solidity=517
            _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"));
```
* This function call executes the following assignment(s).
* In `Free._approve`,
    * `_allowances[owner][spender] = amount`


---
### External call(s)
```solidity=541
        IBEP20(fptAddress).transferFrom(msg.sender, address(1), amount);  // transfer fpt to address(1)
```

```solidity=542
        IBEP20(freeAddress).transferFrom(poolAddress, address(this), amount.div(100)); //transfer free in
```

```solidity=543
        IBEP20(usdtAddress).transferFrom(msg.sender, address(this), uAmount); // transfer usdt in
```

```solidity=547
        IBEP20(freeAddress).approve(exchagneSwap, amount);
```

```solidity=548
        IBEP20(usdtAddress).approve(exchagneSwap, uAmount);
```

```solidity=549
        (,, uint liquidity) = IExchangeSwap(exchagneSwap).addLiquidity(freeAddress,usdtAddress,amount,uAmount,minA,minB, address(this), block.timestamp.add(3600));
```

### State variables written after the call(s)
```solidity=552
        users[msg.sender].allKey.push(id);
```

```solidity=553
        users[msg.sender].informations[id].lockAmount =  liquidity;
```

```solidity=554
        users[msg.sender].informations[id].latestReleasedTime = block.timestamp + stepTime;
```

*Note: Only a sample of 3 assignments (out of 8) are shown above.*



Events should be emitted in functions controlled by centralization roles or which make important updates to state.

Missing Emit Events

The addition of function `burnWithdraw()` in commit [9f38196d3dc07bb7d331e450b4c24d4c3e42b2a2](https://github.com/freeper-labs/freeper_pledge/tree/9f38196d3dc07bb7d331e450b4c24d4c3e42b2a2) seems to conflict with the original design of the `Free_Pledge` contract.

Here is the team's description of the newly implemented code:

"In pledge contract, added users to claim staking in advance. For LP staking, a 10% fee is charged based on the remaining time and sent to a specified address, with the rest distributed to the user.    For FPT+USDT staking, a 10% fee is charged on the remaining amount, with the remaining USDT fully refunded to the user.  Only the time portion of the FREE collateral is refunded, while the remaining part goes into a specified address."

Function `burnWithdraw()` is the feature specified in which users may call to claim in advance.

- Users can call this function on stake types 1, 2 or 4.
- Stake types 1 and 4 are supposed to describe stakes which are to be locked for an entire duration of time (either 100 or 180 days). Allowing users to claim early makes these stake types act closer to type 2 or type 3, depending on the `pledge_type`. If a user prefers a stake of type 2 or type 3, they can already do so initially.
- Stake type 2 already behaves similar to how the claiming utility in `burnWithdraw()` behaves.

A user who has collected `fpt` tokens given away by the protocol can now call function `stakeWithUSD()`, create a stake of type 1,2, or 4, and call function `burnWithdraw()` after a few days, which will send them back an amount of usdt, and an amount of `free` proportional to the number of days waited. This is close to the functionality of stakes of type 3, which are not allowed with function `stakeWithUSD()`. This potentially allows a user to collect something that they did not purchase in large amounts, stake it in the `Free_Pledge` contract for a short amount of time, and recoup a large amount of `freeAddress` token in return, that they can then trade for `usdt`.


Could you please clarify why this function was introduced into the `Free_Pledge` contract? Further, please confirm that the actions described above are accurate and intended for the design of the protocol, since it has changed from the original design.

Conflicting Design Elements

In the update in commit [9f38196d3dc07bb7d331e450b4c24d4c3e42b2a2](https://github.com/freeper-labs/freeper_pledge/tree/9f38196d3dc07bb7d331e450b4c24d4c3e42b2a2), address variable `fptAddress` is set to the following address in the constructor:

[0x0b9568bA77D2f0828E91f4dF0227479a7B7b0483](https://bscscan.com/address/0x0b9568ba77d2f0828e91f4df0227479a7b7b0483#code)

On BSC, this address is for a `FreeperToken` contract with differing logic from the in-scope `fpt.sol` file contract that was audited.

Contract Logic for `fptAddress` assignment does not match in-scope Contract Logic

Contract `Free_Pledge` allows users to stake their LP tokens with different rates of releasing the tokens back to the user. What incentivizes a user to stake with this contract? In the contract itself, the user receives no rewards in return for staking.

Rewards Are Not Distributed In-Contract for Pledging

Functions `stakeLp()` and `reStake()` are associated with `pledge_type` of 2 while function `stakeWithUSD()` is associated with `pledge_type` of 1. In struct `lockInformation`, the following comment is next to `pledge_type`:

```solidity
        uint pledge_type; // 1 pledge from fpt + usdt, 2 pledege from free + usdt
```

This comment appears to indicate that a `pledge_type` of 1 is for lp tokens of pair `fpt-usdt` while `pledge_type` of 2 is for lp tokens of pair `free-usdt`.

However, all pledges are transferred back `lpAddress` when withdrawn, which is presumably the pair `free-usdt`. Moreover, `lpAmount` for a user's `User` struct is updated to include pledge amounts from both `stakeLp()` and `reStake()`, making it impossible to distinguish between a stake that was made in `stakeLp()` and one made with `stakeWithUSD()`.

Last, the `pledge_type` in function `withdraw()` is used to distinguish whether the `lockAmount` should be counted in `totalCanRelease` or `totalCanReleaseNoFee`, which only determines whether the lp tokens will first be separated into `free` and `usdt` and given back tot he user with a fee taken out, or if the lp token will be given back directly to the user without a fee taken out. The `withdraw()` function does not include any consideration of an `fpt-usdt` pair, like the comment for `pledge_type` implies.

Clarification Needed on Pledge Types

In function `stakeWithUSD()`, the user is supposed to transfer an `amount` of `fpt` into the contract, and, in exchange, address `poolAddress` transfers `freeAddress` tokens into the contract to be used with usdt to add liquidity to `lpAddress`.

The understood design of the protocol is that users are only supposed to offer `fpt` in the stake when interacting with `stakeWithUSD()` and that the `freeAddress` token comes from an alternate source. Users interacting with `stakeWithUSD()` may not have `free` tokens if this is intended to be the source of their dispersal.



`free` is transferred from `msg.sender` in `stakeWithUSD()`

Freeper

Release.sol

exchange_swap.sol

fpt.sol

free.sol

pledge.sol

Freeper is a pioneering social platform of the Web3 value network that aims to establish cutting-edge technical standards. Its objectives include enhancing personal security, monetizing social connections, unifying social identities, and protecting personal data. Additionally, Freeper has introduced SocialFi incentives to promote social-to-earn opportunities.

Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program