HashEx x Astronaut audit report is available

Astronaut.to reported last Friday, March 25, through its Twitter account, that the HashEx x Astronaut audit report is ready and available.

The company explained that it commissioned HashEx to conduct an audit of Astronaut’s smart contracts, which is why it was conducted between March 23 and March 26, 2021.

“The audited code is in the Astronaut github repository. The audit was conducted for the 51da64f astronauttoken engagement. Limited documentation was provided on astronaut-1.gitbook.io”, he commented through an article published on the Medium platform.

Also read: Bittrex Global will raffle $15,000 USD in CEL tokens

Purpose of the audit

• Identify possible security problems with smart contracts.

• Formally verify the logic behind the given smart contracts.

• Implementation of the BEP20 token standard with custom functionality of automatic performance by burning tokens in transfers.

Problems found

1. No safeguard for _TAX_FEE – Critical

2. excludeAccount () abuse – High

3. Violation of the BEP20 standard – High

4. For () loop in getCurrentSupply () – High

5. Error updateBurnFee () – Medium

6. Low severity problems – Low

7. Recommendations – Low

Given this, the company detailed some of these problems encountered, such as:

#01 No safeguard for _TAX_FEE – Critical

Astronaut.sol L509 and L513 contain public-only owner functions that set _TAX_FEE to any value of uint256. This behavior is dangerous and should be mitigated by relinquishing ownership of the contract as soon as possible. There are no getter functions or events to check the current or previous values ​​of the _TAX_FEE variable.

#02 abuse of excludeAccount () – High

Excluding and including certain addresses in the automatic performance mechanism can lead to confusing results for users. Including most of the owner’s balance would revert the rate (and user balances) to the near-initial state at the time it was excluded. In addition, the possible sale from the address of the excluded owner will redistribute the balances to the benefit of the owner if the reverse is included. We suggest removing the includeAccount () function or blocking the include / exclude methods by relinquishing ownership.

#03 BEP20 Standard Violation (Zero Restriction High Amount Transfer)

The implementation of the transfer () function does not allow entering a zero quantity as required by the ERC-20 [3] and BEP-20 [4] standards. This issue can break interaction with smart contracts that rely on full ERC20 support.