[LEND] ERC20 Token Smart Contract Domain Team Assessment

LEND ERC20 Token Smart Contract Domain Team Assessment

General Information

Risk Summary

  • Does the contract implement the ERC20 token standard? Yes, the contract implements all the required ERC20 functions. Aside from a few auxiliary functions, the contract is a basic ERC20 implementation.
  • Risk analysis: LOW.

Technical Information

  • Compiler version: v0.4.16+commit.d7661dd9
  • Decimals: 18
  • Overflow checks: Yes, the contract uses a SafeMath library.
  • Mitigation against allowance race-condition: Yes.
  • Upgradeable contract patterns: No.
  • Access control or restriction lists: No.
  • Non-Standard decimals:
    • uint256 instead of standard uint8

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?
    • Yes, one. In the ‘withdrawEther()` function there is an external call: ‘escrow.send(this.balance)’. This function contains the onlyTokenManager modifier, and can only be called by the tokenManager address.

Testnet Information

Audits & Related Documentation

Contract Logic Summary

The token uses a SafeMath contract as its base contract. The standard ERC20 interface, Token, inherits the SafeMath contract, and then a StdToken contract inherits the Token interface and provides the basic ERC20 function implementations. Lastly, an EthLendToken contract then inherits the StdToken contract. This EthLendToken contract contains all the ICO logic and a set of overriding ERC20 functions that wrap the inherited StdToken ERC20 specific functions.

The contract has six states, as defined in the ‘State’ enum: Init, Paused, PresaleRunning, PresaleFinished, ICORunning, and ICOFinished. The contract is in its terminal state, ICOFinished, and can no longer return to any other state. Most of the ICO logic in EthLendToken is now defunct or inaccessible.

The token audit reported several issues that “did not affect the security of the ICO contract directly.” And further cited that “most of the issues are fixed.” The audit then cites the contract initialization design pattern as one of the unfixed issues.

Administrative Addresses

Below is a list of several addresses related to token management:

Contract Risk Summary

This is a low risk contract. The ERC20 functions are implemented to the industry standard and does not use upgradeable design patterns. The ERC20 allowance race condition is mitigated and noted in their code. The contract makes use of a SafeMath library to prevent overflows & underflows. The teamTokenBonus, tokenManager, and escrow addresses can not interact with any of the ERC20 contract logic. The ICO has concluded, and as a result all of the ICO code is now defunct and unusable, but still present. Lastly, the contract does not make use of any access control lists or restrictive features.

It’s also worth noting that the contract has been operational on mainnet since September 17th, 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 (there are requires)

== 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)
[x] 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**