Skip to content

Instantly share code, notes, and snippets.

@yuriy77k

yuriy77k/ETH_Enduracoin_v4_report.md Secret

Last active October 28, 2023 16:23
Show Gist options
  • Save yuriy77k/5890f3eea29767622baa41dc857620bd to your computer and use it in GitHub Desktop.
Save yuriy77k/5890f3eea29767622baa41dc857620bd to your computer and use it in GitHub Desktop.
Download ZIP
EnduracoinToken v4 Security Audit Report
Raw
ETH_Enduracoin_v4_report.md

EnduracoinToken v4 Security Audit Report

1. Summary

EnduracoinToken smart contract security audit report performed by Callisto Security Audit Department

2. In scope

Commit 2ac940bfee90dba11d0b5499ae3e16d988b47ec6

  • EnduracoinToken.sol
  • EnduracoinValue.sol
  • ManageApprovers.sol
  • StringHelpers.sol
  • ChangeRequests.sol

3. Findings

In total, 30 issues were reported, including:

  • 0 high severity issues.

  • 0 medium severity issues.

  • 0 low severity issues.

In total, 3 notes were reported, including:

  • 1 minor observation.

  • 2 owner privileges.

3.1. Owner privileges

Severity: owner privileges

Description

  1. 50 Billion Enduracoin will be pre-minted to the owner's wallet. If tokens are burnt, the owner has the right to mint new tokens up to 50 Billion in total supply.
  2. The majority of approvers can set any value in the EnduracoinValue contract. So the getCurrentValue in the EnduracoinValue contract does not get a real market value of Enduracoin in a decentralized way.

3.2. Multiple minor observation

Severity: minor observation

Description

  1. The modifier requiresMultiSig restrict owner to call function until voting is finished, but allow anybody else to call function without restriction. Therefore, in the context of the contract EnduracoinValue it does not make any sense and can be removed or replaced by the modifier onlyApprovers.
  1. The getPendingChangeRequest() is a view function, so does not require onlyApprovers modifier.

  1. Owner can't create change request and must be the last approver in voting. If owner vote earlier the chenge reqest can't be approved and all others aprovver should vote against it to be able create new request. It's not a security issue, but may cause inconvinient.

  2. Redundant require statement in the modifier requiresMultiSig, the require statement is unnecessary as the following check is already being performed in the function voteForChangeRequest().

4. Security practices

  • Open-source contact.
  • The contract should pass a bug bounty after the completion of the security audit.
  • Public testing.
  • Automated anomaly detection systems. - NOT IMPLEMENTED. A simple anomaly detection algorithm is recommended to be implemented to detect behavior that is atypical compared to normal for this contract. For instance, the contract must halt deposits if a large amount is being withdrawn quickly until the owner or the project community approves further operations.
  • Multisig owner account.
  • Standard ERC20-related issues. - NOT IMPLEMENTED. Every contract can potentially receive an unintended ERC20-token deposit without the ability to reject it, even if the contract is not intended to receive or hold tokens. As a result, it is recommended to implement a function that will allow extracting any arbitrary number of tokens from the contract.
  • Crosschain address collisions. ETH, ETC, CLO, etc. It is possible that a transaction can be sent to the address of your contract at another chain (as a result of a user mistake or some software fault). It is recommended that you deploy a "mock contract" that would allow you to withdraw any tokens from that address or prevent any funds deposits. Note that you can reject transactions of native tokens deposited, but you can not reject the deposits of ERC20 tokens. You can use this source code as a mock contract: extractor contract source code. The address of a new contract deployed using CREATE (0xf0) opcode is assigned following this scheme keccak256(rlp([sender, nonce])). Therefore you need to use the same address that was originally used at the main chain to deploy the mock contract at a transaction with the nonce that matches that on the original chain. Example: If you have deployed your main contract with address 0x010101 at your 2021st transaction, then you need to increase your nonce of 0x010101 address to 2020 at the chain where your mock contract will be deployed. Then you can deploy your mock contract with your 2021st transaction, and it will receive the same address as your mainnet contract.

5. Conclusion

The audited smart contract can be deployed. Users should pay attention to the contract owner's rights.

It is recommended to adhere to the security practices described in pt. 4 of this report to ensure the contract's operability and prevent any issues that are not directly related to the code of this smart contract.

6. Revealing audit reports

6.1. Previous audit reports

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment