MANA ERC20 Token Smart Contract Domain Team Assessment
- Symbol: MANA
- Address: 0x0F5D2fB29fb7d3CFeE444a200298f468908cC942
- Deployment date: August 15th, 2017
- Total Supply: 2196559685435138954648519268 (uint256)
- Project website: https://www.decentraland.org/
- Github repository: https://github.com/decentraland/mana
- Can use existing MCD collateral adapter: Yes, the GemJoin adapter.
- 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.
- 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.
- Kovan MANA token address: 0x230Fc362413D9e862326C2C7084610a5a2fdF78A (unverified)
- Other contract links found here: https://contracts.decentraland.org/links
Audits & Related Documentation
- OpenZeppelin Smart Contract Security Audit Write-up:
Contract Logic Summary
This contract inherits
BurnableToken, and OpenZeppelin’s
There are three state variables:
stringname “Decentraland Mana”
There is one function:
burn(uint256 _value)that calls the parent
MANAToken, it’s important to know the context of its surrounding
- Only the
ownercan pause or unpause the
- The owner of the
MANACrowdsalecontract is address 0xDf861993Edbe95BAFbfA7760838f8ebbd5Afda9F and it was deployed and self-destructed on November 20th, 2018, rendering it unusable.
- The owner of
MANACrowdsale, meaning that the previously mentioned self-destructed address is the parent owner of all underlying contracts.
transferOwnership()calls would have to originate from the parent
owneraddress, which is impossible as it has
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
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