Astronaut x HashEx Audit Report

Disclaimer

This is a limited report on our findings based on our analysis, in accordance with good industry practice as at the date of this report, in relation to cybersecurity vulnerabilities and issues in the framework and algorithms based on smart contracts, the details of which are set out in this report. In order to get a full view of our analysis, it is crucial for you to read the full report. While we have done our best in conducting our analysis and producing this report, it is important to note that you should not rely on this report and cannot claim against us on the basis of what it says or doesn’t say, or how we produced it, and it is important for you to conduct your own independent investigations before making any decisions. We go into more detail on this in the below disclaimer below — please make sure to read it in full.

DISCLAIMER: By reading this report or any part of it, you agree to the terms of this disclaimer. If you do not agree to the terms, then please immediately cease reading this report, and delete and destroy any and all copies of this report downloaded and/or printed by you. This report is provided for information purposes only and on a non-reliance basis, and does not constitute investment advice. No one shall have any right to rely on the report or its contents, and HashEx and its affiliates (including holding companies, shareholders, subsidiaries, employees, directors, officers and other representatives) (HashEx) owe no duty of care towards you or any other person, nor does HashEx make any warranty or representation to any person on the accuracy or completeness of the report. The report is provided “as is”, without any conditions, warranties or other terms of any kind except as set out in this disclaimer, and HashEx hereby excludes all representations, warranties, conditions and other terms (including, without limitation, the warranties implied by law of satisfactory quality, fitness for purpose and the use of reasonable care and skill) which, but for this clause, might have effect in relation to the report. Except and only to the extent that it is prohibited by law, HashEx hereby excludes all liability and responsibility, and neither you nor any other person shall have any claim against HashEx, for any amount or kind of loss or damage that may result to you or any other person (including without limitation, any direct, indirect, special, punitive, consequential or pure economic loss or damages, or any loss of income, profits, goodwill, data, contracts, use of money, or business interruption, and whether in delict, tort (including without limitation negligence), contract, breach of statutory duty, misrepresentation (whether innocent or negligent) or otherwise under any claim of any nature whatsoever in any jurisdiction) in any way arising from or connected with this report and the use, inability to use or the results of use of this report, and any reliance on this report.

The analysis of the security is purely based on the smart contracts alone. No applications or operations were reviewed for security. No product code has been reviewed.

Introduction

HashEx was commissioned by the Astronaut team to perform an audit of Astronaut smart contracts. The audit was conducted between March 23 and March 26, 2021.

The audited code is located in Astronaut’s github repository. The audit was performed for astronauttoken commit 51da64f. There was limited documentation provided on astronaut-1.gitbook.io.

The purpose of this audit was to achieve the following:

• Identify potential security issues with smart contracts.
• Formally check the logic behind given smart contracts.
• Information in this report should be used to understand the risk exposure of smart contracts, and as a guide to improve the security posture of smart contracts by remediating the issues that were identified.
  We found out that Astronaut token is a fork of Reflect.finance [1] custom token with an audit report available [2].
• Contracts overview
• astronaut-contract/AstronautToken.sol
• Implementation of BEP20 token standard with custom functionality of auto-yield by burning tokens on transfers.

Found issues

1. 01 No safeguard for _TAX_FEE — Critical
2. 02 excludeAccount() abuse — High
3. 03 BEP20 standard violation — High
4. 04 for() loop in getCurrentSupply() — High
5. 05 updateBurnFee() bug — Medium
6. 06 Low severity issues — Low
7. 07 Recommendations — Low

#01 No safeguard for _TAX_FEE — Critical

Astronaut.sol L509 and L513 contains public onlyOwner functions that set _TAX_FEE to any value of uint256. This behavior is dangerous and must be mitigated by renouncing contract ownership as soon as possible. There are no getter functions nor events to check the current or previous values of _TAX_FEE variable.

#02 excludeAccount()abuse — High

Exclusion and inclusion of certain addresses into auto-yield mechanism may cause a confusing result for users. Including back the greater part of owner’s balance would revert the rate (and users’ balances) to the almost initial state of the time it was excluded. Moreover, the possible sale from excluded owner address will redistribute balances in profit of the owner in case of backwards including. We suggest removing includeAccount() function or lock exclusion/inclusion methods by renouncing ownership.

#03 BEP20 standard violation(restriction of zero High amount transfer)

Implementation of transfer() function does not allow to input zero amount as it’s demanded in ERC-20 [3] and BEP-20 [4] standards. This issue may break the interaction with smart contracts that rely on full ERC20 support.

#04 for()loopingetCurrentSupply() — High

Mechanism of removing addresses from auto-yielding implies loop over excluded addresses for every transfer operation or balance inquiry. This may lead to extreme gas costs up to block gas limit and may be avoided only by the owner restricting the number of excluded addresses. In an extreme situation with a large number of excluded addresses transaction gas may exceed maximum block gas size and all transfers will be effectively blocked.

#05 updateBurnFee()bug — Medium

updateBurnFee() function sets new value to _TAX_FEE instead of _BURN_FEE. Apparently the contract was designed with the intention of _BURN_FEE to be updated, but it is impossible.

#06 Low severity issues and recommendations — Low

1. excludeAccount() function contains hardcoded address of Uniswap Router02 [5] in Ethereum blockchain which make this requirement completely useless for current realization in BSC. Moreover, address hardcoding is not a good practice as third-party contracts could be deprecated/upgraded.
2. Maximum transfer amount is restricted for a non-owner user by _MAX_TX_SIZE variable. This variable is set to 10x of total supply which makes it virtually useless still gas consuming.
3. Private function _getTaxFee() is not used anywhere. It’s visibility should be changed to external.
4. Function transfer() consists of an excessive number of conditional statements. Default condition is never reached.
5. updateTaxFee() and updateBurnFee() functions use unsafe multiplication, although the proposed safeguard will justify this.
6. Incorrect error message: must be “Account is already included”.
7. Solidity version is not fixed but set to pragma ^0.6.0. Address library is OpenZeppelin
8. v3.0.0 with ^0.6.2. Such inconsistencies may lead to compilation errors.
9. There are zero custom events besides IBEP20 interface. We suggest to implement such events for user actions as well as for changing values of crucial variables.
10. Defaults for _TAX_FEE and _BURN_FEE are 6% and 3%. Whitepaper claims “we will set it to 4% slippage which will do a 3% burn and 1% redistribution”. Up to the block 6008624 we can’t ensure that tax fee was updated.

#07 General recommendations — Low

1. Getters functions for contract constants may be set to pure and/or external. name()

• symbol() decimals() _getMaxTxAmount()

1. We suggest to add a permit() function to ERC20 tokens for gas savings on approvals.
2. Private function _getMaxTxAmount() is not used anywhere. It could be removed for the gas economy or made external.
3. _GRANULARITY constant can be used with 100x multiplier to save gas on calculations.
4. _tFeeTotal and _tBurnTotal variables are not in practical usage. The contract may be
5. reworked to reduce gas costs.
6. Address library is not in use and may be removed.
7. We suggest adding unit tests for future development according to the roadmap of the Astronaut project.
8. Code style recommendations: _TAX_FEE and _BURN_FEE should be in mixedCase; omitted curly braces should be added for readability; four different cases of transfer function (L646, L656, L667, L678) should be merged in _transfer().

Conclusion

Reviewed contract is deployed at 0x05B339B0A346bF01f851ddE47a5d485c34FE220c in BSC. The audited contract is a fork of Reflect.finance smart contract with some changes such as ability to change fees.

One critical and 3 high severity issues were found. Most of the issues can be mitigated by renouncing ownership of the contract.

Audit includes recommendations on the code improving and preventing potential attacks.

Astronaut message: For the time being we will look into the issued and consider mitigating all issues by renouncing ownership as suggested by Hashex audit. We will continue to have our excludeAccount_ ability to be able to exclude accounts which NAUT pools with partners. We will try to fix the criticle No safeguard for _TAX_FEE issue. The present time shows we are on track with our projects function of being able to have the Phase I reflect token function, and exclude certain accounts and pools such as our future IDO pools. We will be releasing updated messages on any fixes done to the code.

• Twitter: https://twitter.com/astronauttoken
• Telegram: https://t.me/astronaut_bsc
• Discord: https://discord.gg/6wZDJ7Ys
• Website: https://astronaut.to