Pseudo-random Number Generator
(PRNG)
| Pass | | | | Transaction-Ordering Dependence | Pass | | | | DoS (Denial of Service) | Pass | | | | Access Control of Owner | Pass | | | | Low-level Function (call/delegatecall) Security | Pass | | | | Returned Value Security | Pass | | | | tx.origin Usage | Pass | | | | Replay Attack | Pass | | | | Overriding Variables | Pass | | | | 3 | Business Security | Business Logics | Pass | | Business Implementations | Pass | | | ## Note: Audit results and suggestions in code comments  Disclaimer: This audit is only applied to the type of auditing specified in this report and the scope of given in the results table. Other unknown security vulnerabilities are beyond auditing responsibility. Beosin (Chengdu LianAn) Technology only issues this report based on the attacks or vulnerabilities that already existed or occurred before the issuance of this report. For the emergence of new attacks or vulnerabilities that exist or occur in the future, Beosin (Chengdu LianAn) Technology lacks the capability to judge its possible impact on the security status of smart contracts, thus taking no responsibility for them. The security audit analysis and other contents of this report are based solely on the documents and materials that the contract provider has provided to Beosin (Chengdu LianAn) Technology before the issuance of this report, and the contract provider warrants that there are no missing, tampered, deleted; if the documents and materials provided by the contract provider are missing, tampered, deleted, concealed or reflected in a situation that is inconsistent with the actual situation, or if the documents and materials provided are changed after the issuance of this report, Beosin (Chengdu LianAn) Technology assumes no responsibility for the resulting loss or adverse effects. The audit report issued by Beosin (Chengdu LianAn) Technology is based on the documents and materials provided by the contract provider, and relies on the technology currently possessed by Beosin (Chengdu LianAn). Due to the technical limitations of any organization, this report conducted by Beosin (Chengdu LianAn) still has the possibility that the entire risk cannot be completely detected. Beosin (Chengdu LianAn) disclaims any liability for the resulting losses. ## The final interpretation of this statement belongs to Beosin (Chengdu LianAn). ### Audit Results Explained: Beosin (Chengdu LianAn) Technology has used several methods including Formal Verification, Static Analysis, Typical Case Testing and Manual Review to audit three major aspects of the partial of project ONE, including Coding Standards, Security, and Business Logic. **The audited ONE contracts passed all audit items. The overall result is Pass.** Please find below the basic information of the smart contract: ### Business Audit: 1. **Coding Conventions** Check the code style that does not conform to Solidity code style. * 1. Compiler Version Security * Description: Check whether the code implementation of current contract contains the exposed solidity compiler bug. * Result: Pass 2. Deprecated Items * Description: Check whether the current contract has the deprecated items. * Result: Pass 3. Redundant Code * Description: Check whether the contract code has redundant codes. * Result: Pass 4. SafeMath Features * Description: Check whether the SafeMath has been used. Or prevents the integer overflow/underflow in mathematical operation. * Result: Pass 5. require/assert Usage * Description: Check the use reasonability of 'require' and 'assert' in the contract. * Result: Pass 6. Gas Consumption * Description: Check whether the gas consumption exceeds the block gas limitation. * Result: Pass 7. Visibility Specifiers  * * * Description: Check whether the visibility conforms to design requirement. * Result: Pass * Fallback Usage * Description: Check whether the Fallback function has been used correctly in the current contract. * Result: Pass ### General Vulnerability Check whether the general vulnerabilities exist in the contract. * 1. Integer Overflow/Underflow * Description: Check whether there is an integer overflow/underflow in the contract and the calculation result is abnormal. * Result: Pass 2. Reentrancy * Description: An issue when code can call back into your contract and change state, such as withdrawing ETH. * Result: Pass 3. Pseudo-random Number Generator (PRNG) * Description: Whether the results of random numbers can be predicted. * Result: Pass 4. Transaction-Ordering Dependence * Description: Whether the final state of the contract depends on the order of the transactions. * Result: Pass 5. DoS (Denial of Service) * Description: Whether exist DoS attack in the contract which is vulnerable because of unexpected reason. * Result: Pass 6. Access Control of Owner * Description: Whether the owner has excessive permissions, such as malicious issue, modifying the balance of others. * Result: Pass 7. Low-level Function (call/delegatecall) Security * Description: Check whether the usage of low-level functions like call/delegatecall have vulnerabilities. * Result: Pass 8. Returned Value Security * Description: Check whether the function checks the return value and responds to it accordingly.  * * * Result: Pass * tx.origin Usage * Description: Check the use secure risk of 'tx.origin' in the contract. In this project, the contract * Result: Pass * Replay Attack * Description: Check whether the implement possibility of Replay Attack exists in the contract. * Result: Pass * Overriding Variables * Description: Check whether the variables have been overridden and lead to wrong code execution. * Result: Pass ### Business Security * 1. **ONE Related Token Audit** In this project, one mining reward pool contract based on the “stake-reward” architecture, three ERC20 Token contracts, one lockup contract, and one Offering contract are implemented, detailed information is as follows. * * 1. Basic token information of ONE The contract implements a basic ERC20 token, and its basic information is as follows: | Token name | One Eth | | ------------ | -------------------------------------- | | Token symbol | ONE | | Decimals | 18 | | TotalSupply | 100 (Mintable without a cap; Burnable) | | Token type | ERC20 | Table 1 – Basic Token Information * * 1. ONE Token Functions * Description: This contract token implements the basic functions of ERC20 standard tokens, and token holders can call corresponding functions for token transfer, approve and other operations. * Related functions: *name, symbol, decimals, balanceOf, allowance, transfer, transferFrom, approve, increaseAllowance, decreaseAllowance* * Safety Suggestion: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. Using function *increaseAllowance* and *decreaseAllowance* to alter allowance is recommended. * Result: **Pass**  * * 1. ONE Token burning * Description: The contract implements *burn\_* function for the contract vault to destroy tokens of a specified address by calling it. **Only the vault contract can call this function. The detail operation logic in the vault contract is not implemented yet, the possibility of existing the risk of that vault contract destroying tokens of any address cannot be ensured.** * Related functions: *burn\_, \_burn* * Safety Suggestion: None * Result: **Pass** 2. ONE Token minting * Description: The contract implements *mint*\_ function for the contract vault to mint tokens to a specified address by calling it. All the initial tokens is minted to the specified address oneFarm via the internal call in function *ONE\_init*. * Related functions: *mint\_, \_mint* * Safety Suggestion: None * Result: **Pass** 3. Basic token information of ONS The contract implements a basic ERC20 token, and its basic information is as follows: | Token name | One Share | | ------------ | -------------------------------- | | Token symbol | ONS | | Decimals | 18 | | TotalSupply | 100000 (totalSupply is constant) | | Token type | ERC20 | Table 1 – Basic Token Information * * 1. ONS Token Functions * Description: This contract token implements the basic functions of ERC20 standard tokens, and token holders can call corresponding functions for token transfer, approve and other operations. * Related functions: *name, symbol, decimals, balanceOf, allowance, transfer, transferFrom, approve, increaseAllowance, decreaseAllowance* * Safety Suggestion: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. Using function *increaseAllowance* and *decreaseAllowance* to alter allowance is recommended.  * * * * Result: **Pass** * Basic token information of ONB The contract implements a basic ERC20 token, and its basic information is as follows: | Token name | One Bond | | ------------ | ------------------------------------------------------ | | Token symbol | ONB | | Decimals | 18 | | TotalSupply | Initial supply is 0 (Mintable without a cap; Burnable) | | Token type | ERC20 | Table 1 – Basic Token Information * * 1. ONB Token Functions * Description: This contract token implements the basic functions of ERC20 standard tokens, and token holders can call corresponding functions for token transfer, approve and other operations. But there are some restrictions here, the ONB token is not allowed to be transferred, only token minting and burning can be made. * Related functions: *name, symbol, decimals, balanceOf, allowance, transfer, transferFrom, approve, increaseAllowance, decreaseAllowance* * Safety Suggestion: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. Using function *increaseAllowance* and *decreaseAllowance* to alter allowance is recommended. * Result: **Pass** 2. ONB Token burning * Description: The contract implements *burn\_* function for the contract vault to destroy tokens of a specified address by calling it. **Only the vault contract can call this function. The detail operation logic in the vault contract is not implemented yet, the possibility of existing the risk of that vault contract destroying tokens of any address cannot be ensured.** * Related functions: *burn\_, \_burn* * Safety Suggestion: None * Result: **Pass** 3. ONB Token minting  * Description: The contract implements *mint*\_ function for the contract vault to mint tokens to a specified address by calling it. The initial token supply of ONB is 0 * Related functions: *mint\_, \_mint* * Safety Suggestion: None * Result: **Pass** ### Offering Contract Audit * * 1. Offering token for users * Description: The contract implements the *offer* function for the users to get the specified token. This function require that the offering function is open (the time reaches the begin time). If the time exceeds the specified time span, all the tokens of this offering contract will be sent to the vault contract, it means the offer function is over. During the normal offering time, the caller should deposit a specified amount (convert according to the specified price) of *currency* token to the Offering contract, then the Offering contract will approve the vault contract, and the function *receiveAEthFrom* of the vault contract is called to receive specified aETH tokens and do other operations. * Related functions: *offer, balanceOf, approve, receiveAEthFrom, safeTransferFrom, safeTransfer* * Safety Suggestion: None * Result: **Pass** ### Timelock Contract Audit * * 1. Set lock information * Description: The contract implements the *start* function to set the lock information. This function require that the lock information should be set only once. The specified unlock(release) recipient address, begin time, lock time span, and unlock times are initialized in this function. * Related functions: *start* * Safety Suggestion: None * Result: **Pass** 2. Unlock * Description: The contract implements the *unlock* function to release the unlocked tokens to the specified recipient address. The unlocked amount is calculated (anyone can query the releasable amount) by the *unlockCapacity* function with the time changes. In addition, the *unlock* function also can be called in the *fallback* function. Note: if other ERC20 tokens are transferred to this contract after the lock information is set, these tokens cannot be transferred out, only the specified lock token can be transferred out from this Timelock contract. * * * * Related functions: *unlock, unlockCapacity, fallback* * Safety Suggestion: None. * Result: **Pass** ### Mine Contract Audit * * 1. Mining reward approval * Description: The contract implements the *approvePool* function to approve reward tokens to the pool contract. The governor address (initialized in the *initialize* function) can call the *approvePool* function to set the allowance between the Mine contract and pool contract. Note: the allowance can be arbitrarily set by the governor address. The reward generation will be affected by the allowance value. * Related functions: *approvePool* * Safety Suggestion: None * Result: **Pass** ### StakingPool Contract Audit The StakingPool is devided into two modes, one is the normal mode that the pool allows users to stake one type of tokens to the pool contract, another one is the EthPool that this pool allows users to stake ETH and the specified staking token. The staking pool contract allows users to mining 2 types of token. * * 1. Stake Initialization * Description: The "stake-reward" mode of the contract needs to initialize the relevant parameters including rewardsDistribution address (Mine contract), ecology address \_ecoAddr, and the ecology reward ratio. After initialization, the function *notifyRewardBegin* is called by the governor address to initialize the reward related information including the increasing mode *lep (linear, exponential, power)* and other time parameters. And the function *notifyReward2* is called to set the *reward2* related information. The functions *notifyRewardBegin* and *notifyReward2* can be called by the specified address governor at any time to control the reward rate and the key time judgment condition. The modified value will affect the user's reward to be not match expectations. * Related functions: *notifyRewardBegin, notifyReward2* * Safety Suggestion: None * Result: **Pass** 2. Stake tokens * Description: The contract implements the *stake* function to stake the specified tokens. The user approve the contract address in advance. By calling the *transferFrom* function in the specified ERC20 token contract, the contract address transfers the specified amount of tokens to the contract address on behalf of the user; each time this function is called to stake tokens, the reward related data is updated through the modifier *updateReward*; and in each stake, the total generated reward and the reward of the ecology address is updated in the modifier *updateReward*. Especially in the EthPool mode, the users can call the function *stakeEth* to stake ETH to this contract. The staked ETH is handled as the normal staking token (WETH). **Note: the receive function (EthPool contract) is allowed to receive transferred ETH, but this contract have no interface to withdraw the ETHs transferred in this contract. If users use this function to stake ETH, the transferred ETH will lose.** * * * * Related functions: *stake, transferFrom, rewardPerToken, rewardDelta, earned, stakeEth* * Safety Suggestion: None * Result: **Pass** * Withdraw tokens * Description: The contract implements the *withdraw* function to withdraw the specified tokens. By calling the *transfer* function in the specified ERC20 token contract, the contract address transfers the specified amount of tokens to the user; each time this function is called to withdraw tokens, the reward related data is updated through the modifier *updateReward*; and in each stake, the total generated reward and the reward of the ecology address is updated in the modifier *updateReward*. Especially in the EthPool mode, the users can call the function *withdrawEth* to withdraw ETH from this contract. The staked ETH is handled as the normal staking token (WETH). * Related functions: *withdraw, transfer, rewardPerToken, earned, withdrawEth* * Safety Suggestion: None * Result: **Pass** * Withdraw rewards * Description: The contract implements the *getReward* function to calculate the stake reward that the user can receive; By calling the *transferFrom* function in the specified ERC20 token contract, the contract address transfers the specified amount (all rewards of caller) of reward tokens from the Mine contract (address rewardsDistribution) to the user; each time this function is called to withdraw reward tokens, the reward related data is updated through the modifier *updateReward*; and in each claiming, the total generated reward and the reward of the ecology address is updated in the modifier *updateReward*. If the reward2 information is set and the reward2 mining time is reached, the specified reward2 token will be claimed (calculated according to the amount of reward1 tokens) and sent to the caller. * Related functions: *getReward, getConfig, rewardPerToken, earned, balanceOf, isContract* * Safety Suggestion: None  * * * * Result: **Pass** * Exit the stake participation * Description: The contract implements the *exit* function to close the participation of "stake-reward" mode. Call the *withdraw* function to withdraw all staked tokens and call the *getReward* function to withdraw all stake rewards. The user address cannot get new rewards because the balance of specified staking token already staked is empty. Note: when *exitETH* function is called to exit, all the staked WETH token will be converted to the ETH. * Related functions: *exit, withdraw, getReward, rewardPerToken, earned, exitETH, withdrawEth* * Safety Suggestion: None * Result: **Pass** ### OneMinter Contract Audit **This contract is not contained in the whole audit scope. The security of implemented contents is not ensured.** This contract implements some functions including *mintInitial*, *purchase*, *cancel*, *mint* and \_*rebase* to interact with the ONE contract, mint specified amount of ONE tokens to the OneMinter contract. ### Vault Contract Audit **This contract is not contained in the whole audit scope. The security of implemented contents is not ensured.** This contract implements some functions including *rebase.* Etc. to interact with the ONE contract, mint specified amount of ONE tokens to the OneMinter contract. ### Conclusion Beosin(ChengduLianAn) conducted a detailed audit on the design and code implementation of the partial of project ONE. In this project, all found issues have been informed to the project side. The audited ONE contracts passed all audit items. The overall audit result is Pass. **Official Website** [https://lianantech.com](http://lianantech.com/) **E-mail**