Alpha Audit

Smart contract security audit report

Audit Number: 202108031755 Report Query Name: OnxAlpha Github link:

https://github.com/Onx-Finance/alpha-vaults/tree/master Commit hash: 8a90f1ebe7db93ad70de16438d4d8896626f5b3d (old) ed619924dcceb8d62f2d15f51670befa5bcf548f (Lasted) Start Date: 2021.07.05

Completion Date: 2021.08.03 Overall Result: Pass

Audit Team: Beosin (Chengdu LianAn) Technology Co. Ltd.

Audit Categories and Results:

No.	Categories	Subitems	Results
1	Coding Conventions	Compiler Version Security	Pass
Deprecated Items	Pass
Redundant Code	Pass
SafeMath Features	Pass
require/assert Usage	Pass
Gas Consumption	Pass
Visibility Specifiers	Pass
Fallback Usage	Pass
2	General Vulnerability	Integer Overflow/Underflow	Pass
Reentrancy	Pass
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

Disclaimer: This report is made in response to the project code. No description, expression or wording in this report shall be construed as an endorsement, affirmation or confirmation of the project. 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 smart contracts project OnxAlpha, including Coding Standards, Security, and Business Logic. The OnxAlpha project passed all audit items. The overall result is Pass. The smart contract is able to function properly.

Audit Contents:

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

• 1. Deprecated Items

     • Description: Check whether the current contract has the deprecated items.

     • Result: Pass

  2. Redundant Code

     • Description: Check whether the contract code has redundant codes.

     • Result: Pass

  3. SafeMath Features

     • Description: Check whether the SafeMath has been used. Or prevents the integer overflow/underflow in mathematical operation.

     • Result: Pass

  4. require/assert Usage

     • Description: Check the use reasonability of 'require' and 'assert' in the contract.

     • Result: Pass

  5. Gas Consumption

     • Description: Check whether the gas consumption exceeds the block gas limitation.

     • Result: Pass

  6. Visibility Specifiers

     • Description: Check whether the visibility conforms to design requirement.

     • Result: Pass

  7. 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

  • Transaction-Ordering Dependence

    • Description: Whether the final state of the contract depends on the order of the transactions.

    • Result: Pass

  • DoS (Denial of Service)

    • Description: Whether exist DoS attack in the contract which is vulnerable because of unexpected reason.

    • Result: Pass

  • Access Control of Owner

    • Description: Whether the owner has excessive permissions, such as malicious issue, modifying the balance of others.

    • Result: Pass

  • Low-level Function (call/delegatecall) Security

    • Description: Check whether the usage of low-level functions like call/delegatecall have vulnerabilities.

    • Result: Pass

  • 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.

    • 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

The main business contracts of the project are AlphaStrategy, OnxAlphaVault, Controller, TAlphaToken and the rest of the contracts mainly implement the initialization of basic parameters. Only the main business contract logic is detailed below.

• 1. Business analysis of contract token TAlphaToken

1. Basic Token Information

Token name	TAlphaToken
Token symbol	TALPHA
decimals	18
totalSupply	Initial is 0, mint without cap
Token type	ERC20

Table 1 Basic Token Information

1. ERC20 Token Standard Functions

   • Description: The token contract implements a token which conforms to the ERC20 Standards. It should be noted that the user can directly call the approve function to set the approval value for the specified address, but in order to avoid multiple authorizations, it is recommended to use the increaseAllowance and decreaseAllowance functions when modifying the approval value instead of using the approve function directly.

   • Related functions: name, symbol, decimals, totalSupply, balanceOf, allowance, transfer, transferFrom, approve, increaseAllowance, decreaseAllowance

   • Result: Pass

2. mint and burn functions

   • Description: The contract implements the mint function for minting a specified number of tokens to a specified address; the burn function for destroying tokens at a specified address; and the setMinter function for giving minter permissions to a specified address. Note: the burn function has excessive permissions, and according to the contract design, the owner permissions should be handed over to the control contract immediately after deployment.

Figure 1 source code of related functions

Safety recommendation: The owner and minter of the contract can destroy user tokens at will via the burn function, and there is an excess of authority. It is recommended that the owner hand over the ownership rights to the control contract after setting the minter to the strategy contract.

• • Repair result: Ignore, the project team said this is simply a dummy token which is deposited on behalf the user using the vault contract into the onxFarm contract, representing their share in SLP tokens. It is mintable or burnable ultimately only from our vault contract. Burned after the user withdraws their SLP token which is in the logic.

  • Related functions: mint, burn, setMinter

  • Result: Pass

  • Business analysis of Contract OnxAlphaVault

1. initialization

   • Description: The contract implements the initialize function to initialize the basic parameters of the contract, which can only be done once.

Figure 2 source code of initialize

• • Related functions: initialize, _ERC20_init, _setupDecimals

  • Result: Pass

1. Basic Token Information

Token name	alpha_XX (symbol of underlying token)
Token symbol	alphaXX (symbol of underlying token)
decimals	Same as underlying token
totalSupply	Initial is 0, mint without cap
Token type	ERC20

Table 2 Basic Token Information

1. ERC20 Token Standard Functions

• • Description: The token contract implements a token which conforms to the ERC20 Standards. It should be noted that the user can directly call the approve function to set the approval value for the specified address, but in order to avoid multiple authorizations, it is recommended to use the increaseAllowance and decreaseAllowance functions when modifying the approval value instead of using the approve function directly.

  • Related functions: name, symbol, decimals, totalSupply, balanceOf, allowance, transfer, transferFrom, approve, increaseAllowance, decreaseAllowance

  • Result: Pass

1. setStrategy function

   • Description: The contract implements the setStrategy function to set the address of the strategy contract, requiring the underlying tokens and vault addresses within the strategy contract address to match those of the contract. Calling the internal function _setStrategy to set the strategy contract address will set the underlying token authorization value of this contract to the maximum value for the strategy contract. Only the controller or governor of the contract is available.

Figure 3 source code of setStrategy

• • Related functions: setStrategy safeApprove, _setStrategy

  • Result: Pass

1. stake by gov functions

   • Description: The controller or governor of the contract is free to call the following functions to complete response operations in the policy contract.

Figure 4 source code of related functions

• • Related functions: invest, stakeOnsenFarm, stakeSushiBar, stakeOnxFarm, stakeOnx

  • Result: Pass

1. stake by user function

   • Description: Anyone can call the following functions to complete the relevant operations through the policy contract, it is not possible to specify specific functions individually, only simultaneously.

Figure 5 source code of stake functions

• • Related functions: doHardWork, doHardWorkXSushi, doHardWorkSOnx, invest, stakeOnsenFarm, stakeSushiBar, stakeOnxFarm, stakeOnx

  • Result: Pass

1. rebalance function

   • Description: The contract implements the rebalance function to withdraw all the funds in the strategy contract before calling invest to send it.

Figure 6 source code of rebalance

• • Related functions: rebalance, withdrawAll, invest

  • Result: Pass

1. deposit functions

   • Description: The contract implements the deposit function for the user to pledge a specified number of underlying tokens to this contract, and the depositFor function for the user to pledge a specified number of underlying tokens to this contract for others. A certain number of alpha tokens will be calculated and minted for the user or holder.

Figure 7 source code of deposit and depositFor

• • Related functions: deposit, depositFor

  • Result: Pass

1. withdraw functions

   • Description: The contract implements the withdrawAll function for the controller or governance to pull all tokens into this contract via the policy contract. withdraw function is used for the user to pull the specified number of tokens from this contract to the caller's address, will calculate and destroy a certain number of alpha tokens for the caller. If the strategy contract is configured, the doHardWork function will be executed once before the withdrawal and a fee of 1/1000 will be calculated and charged.

Figure 8 source code of withdrawAll

Figure 9 source code of withdraw

• • Related functions: withdrawAll, withdrawAllToVault, updateAccPerShare, withdrawReward, totalSupply, withdrawToVault, underlyingBalanceWithInvestment, underlyingBalanceInVault, safeTransfer

  • Result: Pass

1. query functions

   • Description: The contract implements a number of query functions to look up information about the contract's parameters.

   • Related functions: shouldUpgrade, strategy, underlying, underlyingUnit, nextImplementation, nextImplementationTimestamp, nextImplementationDelay, underlyingBalanceInVault, underlyingBalanceWithInvestment, underlyingBalanceWithInvestmentForHolder

   • Result: Pass

   • Business analysis of Contract AlphaStrategy

2. initialize function

• • Description: The contract implements the initializeAlphaStrategy function for initializing the basic information of the strategy contract, which can only be initialized once. The required underlying tokens must correspond to the lp token address of the slpRewardPool.

Figure 10 source code of initializeAlphaStrategy

• • Related functions: initializeAlphaStrategy, initialize, poolInfo

  • Result: Pass

1. fee function

   • Description: The contract implements the setKeepFee function for the governance of the contract to set the fee and the maximum fee. fee must not exceed the maximum fee and the maximum fee must be greater than 0.

Figure 11 source code of setKeepFee

• • Related functions: setKeepFee

  • Result: Pass

1. salvage function

   • Description: The contract implements a salvage function for the contract's governance to extract other ERC20 tokens mistakenly sent to the contract to the specified address. (onx, stakedonx, sushi, underlying tokens cannot be withdrawn)

Figure 12 source code of salvage

• • Related functions: salvage

  • Result: Pass

1. updateAccPerShare function

   • Description: The contract implements the updateAccPerShare function for vault contract update reward related parameters. This is achieved by calling the internal functions updateAccSOnxPerShare and updateAccXSushiPerShare.

Figure 13 source code of updateAccPerShare

• • Related functions: updateAccPerShare, updateAccSOnxPerShare, updateAccXSushiPerShare

  • Result: Pass

1. updateUserRewardDebts function

   • Description: The contract implements the updateUserRewardDebts function for vault contracts to update the collateral rewards for a given user.

Figure 14 source code of updateUserRewardDebts

• • Related functions: updateUserRewardDebts

  • Result: Pass

1. withdrawReward function

   • Description: The contract implements the withdrawReward function for the vault contract to calculate and send the reward to the specified user, which will calculate the fee and send it to the treasury address.

Figure 15 source code of withdrawReward

• • Related functions: withdrawReward, balanceOf, safeTransfer

  • Result: Pass

1. emergencyExit function

   • Description: The contract implements the emergencyExit function for the contract's governance to urgently withdraw all lp tokens from the specified collateral pool and will suspend invest.

Figure 16 source code of emergencyExit

• • Related functions: emergencyExit, emergencyExitSLPRewardPool, _setPausedInvesting

• • Result: Pass

1. continueInvesting function

   • Description: The contract implements the continueInvesting function for the contract's governance to resume the invest state.

Figure 17 source code of continueInvesting

• • Related functions: continueInvesting

  • Result: Pass

1. withdraw to vault function

   • Description: The contract implements the withdrawAllToVault function to withdraw all the underlying tokens from the corresponding slpRewardPool before withdrawing all the tokens from this contract to the vault contract. withdrawToVault is used to withdraw a specified number of underlying tokens to the vault contract. If the current balance is insufficient, a portion of the slpRewardPool will be calculated and withdrawn from the slpRewardPool. Both functions are only available to vault contracts, contract governors or controllers.

Figure 18 source code of withdrawAllToVault and withdrawToVault

• • Related functions: withdrawAllToVault, withdrawToVault, exitSLPRewardPool, safeTransfer, balanceOf, slpRewardPoolBalance, slpPoolId

  • Result: Pass

1. stake function

• • Description: The contract implements the stakeOnsenFarm function to pledge the underlying tokens in this contract to the slpRewardPool; the stakeSushiBar function to first withdraw 0 to get reward tokens from the slpRewardPool and then pledge the sushi tokens in this contract to the sushiBar's The stakeOnxFarm function is used to pledge tAlpha tokens from this contract to the onxFarmRewardPool (the first pledge will mint the same number of tAlpha tokens as the underlying tokens in the vault contract to this contract); the stakeOnx function is used to first extract 0 tAlpha tokens from the onxFarmRewardPool to get reward tokens and pledge them to the onxFarmRewardPool. The stakeSushiBar and stakeOnx functions do not execute the pledge to SushiBar if the contract's sushi and onx tokens do not meet the response conditions pool.

Figure 19 source code of stake functions (1/2)

Figure 20 source code of stake functions (2/2)

• • Related functions: stakeOnsenFarm, stakeSushiBar, stakeOnxFarm, stakeOnx, enterSLPRewardPool, claimSLPRewardPool, enter, _enterOnxFarmRewardPool, _claimXSushiRewardPool, safeApprove, balanceOf

  • Result: Pass

1. exit function

   • Description: The contract implements the exitOnxFarmRewardPool function for extracting the tAlpha tokens pledged in onxFarmRewardPool and destroying an equal number of tAlpha tokens in this contract.

Figure 21 source code of exitOnxFarmRewardPool function

• • Related functions: exitOnxFarmRewardPool, _onxFarmRewardPoolBalance, withdraw, burn

  • Result: Pass

1. set sell functions

   • Description: The contract implements the setSell function for the governance of the contract to set the sell state; the setSellFloor function for the governance of the contract to set the lower limit on the number of sells. stakeSushiBar and stakeOnx functions have subsequent pledge operations only when the sell state is true and the number of pledges is greater than sellFloor.

Figure 22 source code of setSell and setSellFloor

• • Related functions: setSell, setSellFloor

  • Result: Pass

1. setOnxTreasuryFundAddress function

   • Description: The contract implements the setOnxTreasuryFundAddress function for the governance of the contract to set the treasury address for receiving fees.

Figure 23 source code of setOnxTreasuryFundAddress

• • Related functions: setOnxTreasuryFundAddress

  • Result: Pass

1. query functions

   • Description: The contract implements a number of query functions to look up information about the contract's parameters.

   • Related functions: unsalvagableTokens, pendingReward, pendingXSushi, pendingXSushiOfUser, pendingSOnxOfUser, slpPoolId, onxFarmRewardPoolId, pendingRewardOfUser, investedUnderlyingBalance

   • Result: Pass

   • Business analysis of Contract Controller

2. hardworker functions

   • Description: The contract implements the addHardWorker function for the contract's governance to grant hardWorker privileges to the specified address; the removeHardWorker function for the contract's governance to revoke hardWorker privileges to the specified address.

Figure 24 source code of addHardWorker and removeHardWorker

• • Related functions: addHardWorker, removeHardWorker

  • Result: Pass

1. greyList functions

   • Description: The contract implements the addToGreyList function for the contract's governance to add the specified address to the grey list; the removeFromGreyList function for the contract's governance to remove the specified address from the grey list. Only contract addresses in the grey list will be affected to some extent and the deposit and depositFor functions of the vault contract cannot be executed.

Figure 25 source code of addToGreyList and removeFromGreyList

• • Related functions: addToGreyList, removeFromGreyList

  • Result: Pass

1. addVaultAndStrategy functions

   • Description: The contract implements the addVaultAndStrategy function for the contract's governance settings to bind the specified vault contract to the strategy contract. It is required that the address is not 0 and that the vault contract is not bound.

Figure 26 source code of addVaultAndStrategy

• • Related functions: addVaultAndStrategy, setStrategy

  • Result: Pass

1. stake functions

• • Description: The contract implements the stakeOnsenFarm, stakeSushiBar, stakeOnxFarm, stakeOnx

functions for the hardWorker or governance to call the functions of the vault contract for pledging.

Figure 27 source code of stake functions

• • Related functions: stakeOnsenFarm, stakeSushiBar, stakeOnxFarm, stakeOnx

  • Result: Pass

1. salvage functions

   • Description: The contract implements the salvage function for the governance of the contract to send the specified ERC20 tokens mistakenly sent to this contract to the governance address; the salvageStrategy function for the governance to send the ERC20 tokens mistakenly sent to the specified strategy contract to the governance address is implemented by calling the salvage function in the strategy contract, and business-related tokens cannot be withdrawn.

Figure 28 source code of salvage functions

• • Related functions: salvage, salvageStrategy

  • Result: Pass

Conclusion

Beosin(ChengduLianAn) conducted a detailed audit on the design and code implementation of the smart contracts project OnxAlpha. The problems found by the audit team during the audit process have been notified to the project party and reached an agreement on the repair results, the overall audit result of the OnxAlpha project's smart contract is Pass.

Official Website https://lianantech.com E-mail [e-mail] Twitter

https://twitter.com/Beosin_com