<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

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 or manipulate the token price in decentralized exchanges. 

The **_convertHexToPairToken()** function relies on price calculations that are based on-chain, meaning they are susceptible to flash-loan attacks by manipulating the price of given pairs to the attacker's benefit. 


Within the `HexOnePriceFeed` contract, the `_convertHexToPairToken()` function employs each token's balance in the Pair contract to ascertain the amount of `HEX` tokens that can be exchanged for its corresponding `PairToken`. Any fluctuations in a token's balance can impact the calculation outcome of `_convertHexToPairToken()`.

Anyone can transfer `PairToken` directly to the Pair contract and subsequently retrieve the deposited tokens through the [`skim()`](https://github.com/Uniswap/v2-core/blob/ee547b17853e71ed4e0101ccfd52e70d5acded58/contracts/UniswapV2Pair.sol#L190) method within the Uniswap Pair contract.

Considering the aforementioned descriptions, a hacker could manipulate the return result of the `_convertHexToPairToken()` function, enabling them to stake a modest quantity of `HEX` tokens and acquire a disproportionately larger number of `$HEX1` tokens than would normally be attainable.

Potential $HEX1 Mint Amount Manipulation

The upgradeable contracts listed below, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.

- HexOneBootstrap
- HexOneEscrow
- HexOnePriceFeed
- HexOneStaking
- HexOneVault

Centralized Control of Contract Upgrade

In the contract `HexOneBootstrap` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/cddd5947491641cb865a747e711eddf4/diagrams/centralization_HexOneBootstap-HexOneBootstrap-_owner.svg)
Any compromise to the above central role accounts may allow the hacker to take advantage of this authority and do the following:

- `withdrawToken()`, get any assets from `HexOneBootstrap` contract.
- `setAllowedTokens()`, set malicious ERC20 token.
- `setTokenWeight()`, set higher weight of any token to get more `HEXIT` token rewards.
- `setEscrowContract()`, set malicious `HexOneEscrow` contract address or malicious EOA address to get the deposited `HEX` assets.
- `setPriceFeedCA()`, set malicious PriceFeed contract and manipulate token price.


In the contract `HEXIT` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/cddd5947491641cb865a747e711eddf4/diagrams/centralization_HEXIT-HEXIT-_owner.svg)
Any compromise to the above central role accounts may allow the hacker to take advantage of this authority and do the following:

- `setBootstrap()`, set malicious `HexOneBootstrap` contract address or malicious EOA address to mint any amount of `HEXIT` token to any account.

In the contract `HexOneEscrow` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/cddd5947491641cb865a747e711eddf4/diagrams/centralization_HexOneEscrow-HexOneEscrow-_owner.svg)
Any compromise to the above central role accounts may allow the hacker to take advantage of this authority.

In the contract `HexOnePriceFeed` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/cddd5947491641cb865a747e711eddf4/diagrams/centralization_HexOnePriceFeed-HexOnePriceFeed-_owner.svg)
Any compromise to the above central role accounts may allow the hacker to take advantage of this authority and do the following:

- `setPriceFeed()`, set malicious PriceFeed contract and manipulate token price. 
- `setMultiPriceFeed(), set malicious PriceFeed contract and manipulate token price. 

In the contract `HexOneProtocol` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/cddd5947491641cb865a747e711eddf4/diagrams/centralization_HexOneProtocol-HexOneProtocol-_owner.svg)
Any compromise to the above central role accounts may allow the hacker to take advantage of this authority and do the following:

- `setMinDuration()`, `setMaxDuration()`, set both min and max duration very large and provide unreasonable service.
- `setVaults()`, set malicious `HexOneVault` contract to steal deposited assets.
- `setStakingPool()`, set malicious `HexOneStaking` contract to steal deposited assets.
- `setDepositFee()`, set unreasonable high fee.
- `setDepositFeeEnable()`, disable fee charge.

In the contract `HexOneStaking` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/cddd5947491641cb865a747e711eddf4/diagrams/centralization_HexOneStaking-HexOneStaking-_owner.svg)
Any compromise to the above central role accounts may allow the hacker to take advantage of this authority and do the following:

- `removeAllowedTokens()`, maliciously remove ERC20 at any time and stop the staking service.

In the contract `HexOneToken` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/cddd5947491641cb865a747e711eddf4/diagrams/centralization_HexOneToken-HexOneToken-_owner.svg)
Any compromise to the above central role accounts may allow the hacker to take advantage of this authority and do the following:

- `setAdmin()`, set malicious `HexOneProtocol` contract or malicious EOA to mint any amount of `$HEX1` to any account or burn any amount of `$HEX1` owned any account.

In the contract `HexOneVault` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/cddd5947491641cb865a747e711eddf4/diagrams/centralization_HexOneVault-HexOneVault-_owner.svg)
Any compromise to the above central role accounts may allow the hacker to take advantage of this authority and do the following:

- `setHexOneProtocol()`, set malicious `HexOneProtocol` contract or malicious EOA to
  - claim other accounts' collateral assets.
  - get `$HEX1` token by using other accounts' collateral assets.
- `setLimitClaimDuration()`, set unreasonable small grace duration and get other accounts' collateral assets.


Centralization Related Risks

The three issues about the `receive()` function are listed below:

**Issue 1**. Potential Receive Function Failure

In Ethereum, `send/transfer/call` can be used for ETH transferring. In the worst case, the fallback function can only rely on 2300 gas being available (for example when `send` or `transfer` is used), leaving little room to perform other operations except for basic logic.

The `receive() external payable` function in the `HexOneBootstrap` contract is designed to accept the platform's native currency, `ETH`. Based on the code logic of the `receive()` function in the `HexOneBootstrap` contract, it involves complex operations such as Uniswap, which could result in gas fees exceeding 2300, leading to transaction failure. When users employ the `address. transfer()` function to send `ETH` to the `HexOneBootstrap` contract, the transaction will be reverted.

**Issue 2**. Potential swap failure due to non-existent DEX pair

If the initial value of the `pairToken` state variable in the `HexOneBootstrap` contract is set to `WETH`, attempting to contribute to the project early by staking `ETH` will fail due to the use of a non-existent DEX pair contract `WETH-WETH` during the DEX swap operation. Please refer to the `Scenario` section for more details.

Potential Receive Function Failure

During the *sacrifice* phase, users invest assets and receive `HEXIT` reward tokens, with the variable `userInfo.sacrificeUSD` documenting the value of the user's invested assets (denominated in USD). Users who stake their `HEX` tokens in the `HEX` contract receive `HEX T-shares`, and the variable `userInfo.hexShares` records the value of the user's staked assets in the `HEX` contract (also denominated in USD).

According to the comments on lines 38 and 41, we learn that the state variable `airdropDistRateForHexHolder` represents the percentage for users who hold t-shares by staking hex, while the state variable `airdropDistRateForHEXITHolder` signifies the percentage for users who hold $HEXIT through sacrifice.

Lines 466 to 470 contain code that calculates the user's total assets based on the pre-set weightings for `HEX` and `HEXIT` assets. However, an error in the corresponding relationship of the weightings in the calculation formula has occurred (refer to lines 412 to 416). This ultimately leads to an imprecise result for `userInfo.totalUSD`.

Incorrect Variable Assignment

When users stake assets in the `HexOneProtocol` contract, if a fee is required, it will be deducted from the staked assets. If the staked token is `HEX`, the fee will be transferred to the `HexOneStaking` contract. Otherwise, it will be permanently locked in the `HexOneProtocol` contract. In this case, as users continue to stake, non-`HEX` token fees will continue to be locked in the `HexOneProtocol` contract, resulting in asset loss.

Assets Leftover In `HexOneProtocol` Contract

The precision of the local variables `hexShare` and `hexitShare` is the precision of the staked token, while the precision of the local variables `distributedHex` and `distributedHexit` is 8 and 18, respectively. In the formulas for calculating the annual yield on lines 470 and 474, the inconsistency in precision between the numerator and denominator can lead to incorrect annual yield calculation results.

Decimal Mismatch In Equation

A sandwich attack may happen when an attacker observes a transaction swapping tokens or adding 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:

- `_processSacrifice()`

Potential Sandwich Attacks

According to the `whenSacrificeDuration` modifier, a user can successfully sacrifice at the last moment of the sacrifice phase, which is `sacrificeEndTime`. In this case, the user's sacrifice day index is recorded as `(sacrificeEndTime - sacrificeStartTime) / 1 days`.

When the user calls `claimRewardsForSacrifice()` the day after successfully sacrificing to obtain the `HEXIT` reward tokens, the local variable `curDay` in line 358 takes the value `(sacrificeEndTime-sacrificeStartTime) / 1 days`, resulting in `info.day == curDay`. This causes the validation on line 364 to fail, preventing the user from receiving rewards despite participating in the sacrifice.

Potential Unclaimable Sacrifice Reward

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

```solidity=116
        stakingMaster = _stakingMaster;
```
- `_stakingMaster` is not zero-checked before being used.



Missing Zero Address Validation

In file `HexOneBootstap.sol`, on line 598, the state variable `sacrificeInfos` records the daily `HEXIT` token rewards for users' sacrifices. Therefore, when users invoke the `claimRewardsForSacrifice()` function to claim their `HEXIT` token rewards, there is no need to recalculate the daily `HEXIT` token rewards for user sacrifices in line 371. Instead, simply utilizing `info.supplyAmount` will suffice, thus reducing the gas fee.

Duplicated SupplyAmount Calculation

According to the function signature of `_getSupplyAmountForSacrificeToday()`, it has two return values, `day` and `supplyAmount`. However, the code on line 639, `return (dayIndex, 0);`, results in a constant zero value for `supplyAmount`. Consequently, the `_calcSupplyAmountForSacrifice()` call on line 637 does not return the `HEXIT` token reward amount for a specific day to the caller, rendering line 637 redundant. Thus, it can be removed to reduce gas fees.

Redundant SupplyAmount Calculation

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=141
    function initialize(Param memory _param) public initializer {
```
`initialize` has memory location parameters: `_param`.


Inefficient Memory Parameter

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

The following code calculates the USD value of the user's effective `HEX` tokens and assigns it to the `currentValue` variable. In line 367, the price of one `HEX` token has already been assigned to the `curHexPrice` variable. Multiplying `effectiveHex` by `curHexPrice` yields the USD value of the user's effective `HEX` tokens, thereby reducing gas fee consumption.

```solidity=384
currentValue: IHexOnePriceFeed(hexOnePriceFeed)
    .getHexTokenPrice(effectiveHex),
```

```solidity=367
uint256 curHexPrice = IHexOnePriceFeed(hexOnePriceFeed)
    .getHexTokenPrice(10 ** hexDecimals);
```


Duplicated Hex Token Price Calculation

In light of the usage of the function decorator `onlyAllowedToken` within the `sacrificeToken()` and `receive()` functions, it is discerned that the token weight information `allowedTokens[token].weight` is only utilized when the `allowedTokens[token].enable` attribute is set to True. 

However, during the invocation of the `setTokenWeight()` function, there is no verification of whether the `allowedTokens[token].enable` attribute is indeed True. Under such circumstances, the potential for invalid data arises, where the token weight is non-zero, yet `allowedTokens[token].enable` remains False.

We notice that the `setAllowedTokens()` function lacks time verification, signifying that the value of `allowedTokens[token].enable` can be set at any given moment. However, the `setTokenWeight()` function may solely be invoked before the sacrifice start. If the allowed token is enable, its weight shouldn't be zero.

Missing Token Status Check 

There is no validation to check whether `_tokens.length` and `_weights.length` are the same.

Lack Validation for Array Length

1. The two addresses, [`address(0xdEaD)`](https://etherscan.io/address/0x000000000000000000000000000000000000dead) and [`address(0x0)`](https://etherscan.io/address/0x0000000000000000000000000000000000000000) are both commonly used by projects to burn tokens. 

2. The `_transfer()` function defined in the `HEXIT` and `HexOneToken` contracts merely checks that `from` and `to` cannot be the zero address, `address(0x0)`. However, it is unreasonable when `from` or `to` is `address(0xdEaD)`.

Missing `0xdEaD` Address Check

According the code logic of `HexOneStaking` contract, it doesn't support `ERC721` staking. So inheriting from `ERC721HolderUpgradeable` isn't needed.

The  Not Needed `ERC721HolderUpgradeable` Inheritance

The various `HexOneVault` contracts are divided based on the type of staked token. The staked token for a `HexOneVault` contract can be obtained by calling the `baseToken()` function. Currently, the `baseToken()` function only returns the address of the `HEX` token, it should returns the initialized base token.

Base Token Of `HexOneVault`

1. The local variable `dayPayoutTotal` represents the amount of `HEX` tokens issued in a day, which are rewarded to users who stake their `HEX` tokens in the `HEX` contract on that day. The daily issuance of `HEX` tokens is calculated in the `HEX` contract by multiplying the daily `HEX` token total minting amount with the daily interest rate. The total minting amount of `HEX` tokens varies due to user staking and redemption operations, so the `HEX` token reward amount for each day is not consistent. However, lines 515-519 of the code call the function `getLiquidableDeposits()/getUserInfos()` to query the information on the `HEX` token reward amount for that day in the `HEX` contract, which is used as the daily `HEX` token reward amount for users during their staking period.

2. When a user ends their stake in the `HEX` contract, `HEX` contract calculates the user's total reward by using the number of reward tokens earned per day during the user's staking period and the user's proportion of T-shares. However, lines 515-519 of the code use a fixed value of `FIXED_POINT_PAYOUT=10 ** 15` as the total daily minting amount of HEX tokens.

Based on the aforementioned factors, it may lead to inaccurate calculation of user reward tokens.

Inaccurate Effective Hex Calculation

Hex1 - addendum

TokenUtils.sol

HEXIT.sol

HexOneBootstap.sol

HexOneEscrow.sol

HexOnePriceFeed.sol

HexOneProtocol.sol

HexOneStaking.sol

HexOneToken.sol

HexOneVault.sol

Hex One Protocol ($HEX1) is a stablecoin backed by Hex T-Shares. Each 1 HEX1 = $1 worth of HEX. Hex One distributes an incentive token, $HEXIT, to all bootstrap participants and LP stakers.

Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program