[MANA] ERC20 Token Smart Contract Domain Team Assessment

MANA ERC20 Token Smart Contract Domain Team Assessment

General Information

Risk Summary

  • Does the contract implement the ERC20 token standard? Yes, although the inheritance structure used is undesirable. Aside from a few auxiliary functions, the majority of the contract is the implementation of the ERC20 functions.
  • Risk Analysis: LOW.

Technical Information

  • Compiler version: v0.4.11+commit.68ef5810
  • Decimals: 18
  • Checks for overflow? Yes, the contract uses a SafeMath library.
  • Mitigation against allowance race-condition: Yes, via the inheritance of the OpenZeppelin StandardToken contract.
  • Upgradeable contract patterns: No.
  • Access control or restriction lists: No.

Formal Verification Considerations

  • Does transfer have simple semantics? Yes.
  • Does transferFrom have simple semantics? Yes.
  • Can balances be arbitrarily modified by some actor? No.
  • Are there any external calls? No.

Testnet Information

Audits & Related Documentation

Contract Logic Summary

MANAToken contract

This contract inherits BurnableToken, and OpenZeppelin’s PausableToken and MintableToken contracts.

There are three state variables:

  • string symbol “MANA”
  • string name “Decentraland Mana”
  • and uint256 decimals 18

There is one function:

  • burn(uint256 _value) that calls the parent BurnableToken contract.

To understand MANAToken, it’s important to know the context of its surrounding MANACrowdsale and MANAContinuousSale contracts.

  • The owner of the MANAToken is the MANACrowdsale contract.
  • Only the owner can pause or unpause the MANAToken contract.
  • The owner of the MANACrowdsale contract is address 0xDf861993Edbe95BAFbfA7760838f8ebbd5Afda9F and it was deployed and self-destructed on November 20th, 2018, rendering it unusable.
  • The owner of MANAContinuousSale is MANACrowdsale, meaning that the previously mentioned self-destructed address is the parent owner of all underlying contracts.
  • Any pause(), unpause(), or transferOwnership() calls would have to originate from the parent owner address, which is impossible as it has self-destructed.

The inheritance structure in MANAToken is undesirable but has no affect on the security of the token.

Contract Risk Summary

This is a low risk contract. The ERC20 functions are implemented to the industry standard and uses a SafeMath library, although the inheritance structure utilized is undesirable. The contract does not use upgradeable design patterns. The parent owner of the MANAToken and the MANACrowdsale token is a self-destructed address that cannot access the pause(), unpause(), and transferOwnership() functions. Lastly, the contract does not make use of any access control lists or restrictive features.

It’s also worth nothing that the contract has been operational on mainnet since August 15th, 2017.

== ERC20 functions definition ==
[✓] transfer (address, uint256) -> (bool)
[✓] approve (address, uint256) -> (bool)
[✓] transferFrom (address, address, uint256) -> (bool)
[✓] allowance (address, address) -> (uint256)
[✓] balanceOf (address) -> (uint256)

== Custom modifiers ==
[✓] No custom modifiers in ERC20 functions

== ERC20 events ==
[✓] Transfer (address, address, uint256)
[✓] Approval (address, address, uint256)
[x] transfer must emit Transfer (address, address, uint256)
[x] approve must emit Approval (address, address, uint256)
[x] transferFrom must emit Transfer (address, address, uint256)

== ERC20 getters ==
[✓] totalSupply () -> (uint256)
[✓] decimals () -> (uint8)
[✓] symbol () -> (string)
[✓] name () -> (string)

== Allowance frontrunning mitigation ==
[x] increaseAllowance (address, uint256) -> (bool)
[x] decreaseAllowance (address, uint256) -> (bool)

== Balance check in approve function ==
[✓] approve function should not check for sender's balance
5 Likes