[LRC] ERC20 Token SC Domain Team Assessment

General Information

Risk Summary

  • Does the contract implement the ERC20 token standard? Yes, the contract implements all the required ERC20 functions.
  • Risk analysis: LOW.

Technical Information

  • Compiler version: v0.5.7+commit.6da8b019
  • Decimals: 18
  • Overflow checks: Yes, the contract uses a SafeMath library.
  • Mitigation against allowance race-condition: Yes (increaseAllowance and decreaseAllowance functions are implemented).
  • Upgradeable contract patterns: No.
  • Access control or restriction lists: No.
  • Non-standard features and behaviors:
    • Implements a batchTransfer function.
    • Implements burn and burnFrom functions and tracks total tokens burned.
    • A call to transfer or transferFrom with a recipient address of 0 will call burn (or burnFrom, respectively) instead of executing the transfer (and the Burn event will be emitted instead of the Transfer event).

Formal Verification Considerations

  • Does transfer have simple semantics? Mostly, excepting delegation to burn on transfers to the zero address.
  • Does transferFrom have simple semantics? Mostly, excepting delegation to burnFrom on transfers to the zero address.
  • Can balances be arbitrarily modified by some actor? No.
  • Are there any external calls? No.

Testnet Information

  • Kovan LRC token address: no official deployment from the team—we should deploy our own version for testing

Audits & Related Documentation

  • Loopring Protocol Security Audit Report:
    • Can be found here, but doesn’t seem to cover the token contract itself.

Contract Logic Summary

The contract is essentially a vanilla ERC20 contract that includes functions for burning tokens and performing batch transfers.

Administrative Addresses


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, although a user could still fall victim to the race condition if they do not understand how to avoid it. The contract makes use of a SafeMath library to prevent overflows & underflows.

One thing to note: while the contract itself is not upgradeable, the rest of the Loopring system is, and thus if the Loopring system were upgraded to use a different token, this contract would effectively become defunct and very likely valueless. The probability of this happening is judged to be low (and a Loopring team member stated there were no plans to ever do this).