- Symbol: LRC
- Address: 0xBBbbCA6A901c926F240b89EacB641d8Aec7AEafD
- Deployment date: April 11th, 2019
- Total Supply: 1,374,513,896.690823857345100827 (uint256, strictly decreasing)
- Developers Allotment: at least 186,010,140.666667 (~13%, balance of Icebox contract, developers may control other coins elsewhere—e.g. it seems the Icebox contract has staked ~4,202 LRC in the current staking pool)
- Project website: https://loopring.org/
- Github repository: https://github.com/Loopring/protocols/tree/master/packages/lrc_v2
- Can use existing MCD collateral adapter: Yes, the GemJoin adapter.
- Does the contract implement the ERC20 token standard? Yes, the contract implements all the required ERC20 functions.
- Risk analysis: LOW.
- Compiler version: v0.5.7+commit.6da8b019
- Decimals: 18
- Overflow checks: Yes, the contract uses a SafeMath library.
Mitigation against allowance race-condition: Yes (
decreaseAllowancefunctions are implemented).
- Upgradeable contract patterns: No.
- Access control or restriction lists: No.
Non-standard features and behaviors:
- Implements a
burnFromfunctions and tracks total tokens burned.
- A call to
transferFromwith a recipient address of
burnFrom, respectively) instead of executing the transfer (and the
Burnevent will be emitted instead of the
- Implements a
Formal Verification Considerations
Does transfer have simple semantics? Mostly, excepting delegation to
burnon transfers to the zero address.
Does transferFrom have simple semantics? Mostly, excepting delegation to
burnFromon transfers to the zero address.
- Can balances be arbitrarily modified by some actor? No.
- Are there any external calls? No.
- 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.
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).