[UNI-V2-LINK-ETH] ERC20 Token Smart Contract Technical Assessment

[UNI-V2-LINK-ETH] ERC20 Token Smart Contract Technical Assessment

General Information

Risk Summary

  • Does the contract implement the ERC20 token standards? Yes.
  • Risk analysis : LOW.

Technical Information

  • Compiler version : v0.5.16+commit.9c3226ce
  • Decimals : 18
  • Overflow checks : Yes, the contract uses the SafeMath library for uint operations.
  • Mitigation against allowance race-condition : No.
  • Upgradeable contract patterns : No.
  • Access control or restriction lists : No.
  • Non-standard features or behaviors : 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

  • Uniswap is deployed on Ropsten, Rinkeby, Gorli and Kovan. List of relevant addresses here.

Contract Logic Summary

Administrative Addresses

  • Fee Setter: 0x5e4be8Bc9637f0EAA1A755019e06A68ce081D58F
    • Fee setter can turn fees on and off and set the target address that recieves fees. This address is controlled by Uniswap Governance and is behind a time lock of 48 hours.

Inheritance Structure

UNI-V2-LINK-ETH uses custom minting/burning logic in UniswapV2Pair which extends UniswapV2ERC20.

Other

UniswapV2ERC20 also implements permit for gasless transactions.

Contract Risk Summary

This is a medium risk contract. The ERC20 functions are implemented to industry standard, there are checks to prevent over/underflows, and the contract is non-upgradeable. Uniswap LP tokens are very safe by themselves, and the underlying tokens are also safe.

Supporting Materials

Architecture Diagram

Inheritance Diagram

Sūrya’s Description Report

Files Description Table

File Name SHA-1 Hash
UniswapV2Pair-All.sol f5e7366252c794b5fe2bf7bd2c1ce82240138de2

Contracts Description Table

Contract Type Bases
Function Name Visibility Mutability Modifiers
IUniswapV2Pair Interface
name External :exclamation: NO❗️
symbol External :exclamation: NO❗️
decimals External :exclamation: NO❗️
totalSupply External :exclamation: NO❗️
balanceOf External :exclamation: NO❗️
allowance External :exclamation: NO❗️
approve External :exclamation: :stop_sign: NO❗️
transfer External :exclamation: :stop_sign: NO❗️
transferFrom External :exclamation: :stop_sign: NO❗️
DOMAIN_SEPARATOR External :exclamation: NO❗️
PERMIT_TYPEHASH External :exclamation: NO❗️
nonces External :exclamation: NO❗️
permit External :exclamation: :stop_sign: NO❗️
MINIMUM_LIQUIDITY External :exclamation: NO❗️
factory External :exclamation: NO❗️
token0 External :exclamation: NO❗️
token1 External :exclamation: NO❗️
getReserves External :exclamation: NO❗️
price0CumulativeLast External :exclamation: NO❗️
price1CumulativeLast External :exclamation: NO❗️
kLast External :exclamation: NO❗️
mint External :exclamation: :stop_sign: NO❗️
burn External :exclamation: :stop_sign: NO❗️
swap External :exclamation: :stop_sign: NO❗️
skim External :exclamation: :stop_sign: NO❗️
sync External :exclamation: :stop_sign: NO❗️
initialize External :exclamation: :stop_sign: NO❗️
IUniswapV2ERC20 Interface
name External :exclamation: NO❗️
symbol External :exclamation: NO❗️
decimals External :exclamation: NO❗️
totalSupply External :exclamation: NO❗️
balanceOf External :exclamation: NO❗️
allowance External :exclamation: NO❗️
approve External :exclamation: :stop_sign: NO❗️
transfer External :exclamation: :stop_sign: NO❗️
transferFrom External :exclamation: :stop_sign: NO❗️
DOMAIN_SEPARATOR External :exclamation: NO❗️
PERMIT_TYPEHASH External :exclamation: NO❗️
nonces External :exclamation: NO❗️
permit External :exclamation: :stop_sign: NO❗️
SafeMath Library
add Internal :lock:
sub Internal :lock:
mul Internal :lock:
UniswapV2ERC20 Implementation IUniswapV2ERC20
Public :exclamation: :stop_sign: NO❗️
_mint Internal :lock: :stop_sign:
_burn Internal :lock: :stop_sign:
_approve Private :closed_lock_with_key: :stop_sign:
_transfer Private :closed_lock_with_key: :stop_sign:
approve External :exclamation: :stop_sign: NO❗️
transfer External :exclamation: :stop_sign: NO❗️
transferFrom External :exclamation: :stop_sign: NO❗️
permit External :exclamation: :stop_sign: NO❗️
Math Library
min Internal :lock:
sqrt Internal :lock:
UQ112x112 Library
encode Internal :lock:
uqdiv Internal :lock:
IERC20 Interface
name External :exclamation: NO❗️
symbol External :exclamation: NO❗️
decimals External :exclamation: NO❗️
totalSupply External :exclamation: NO❗️
balanceOf External :exclamation: NO❗️
allowance External :exclamation: NO❗️
approve External :exclamation: :stop_sign: NO❗️
transfer External :exclamation: :stop_sign: NO❗️
transferFrom External :exclamation: :stop_sign: NO❗️
IUniswapV2Factory Interface
feeTo External :exclamation: NO❗️
feeToSetter External :exclamation: NO❗️
getPair External :exclamation: NO❗️
allPairs External :exclamation: NO❗️
allPairsLength External :exclamation: NO❗️
createPair External :exclamation: :stop_sign: NO❗️
setFeeTo External :exclamation: :stop_sign: NO❗️
setFeeToSetter External :exclamation: :stop_sign: NO❗️
IUniswapV2Callee Interface
uniswapV2Call External :exclamation: :stop_sign: NO❗️
UniswapV2Pair Implementation IUniswapV2Pair, UniswapV2ERC20
getReserves Public :exclamation: NO❗️
_safeTransfer Private :closed_lock_with_key: :stop_sign:
Public :exclamation: :stop_sign: NO❗️
initialize External :exclamation: :stop_sign: NO❗️
_update Private :closed_lock_with_key: :stop_sign:
_mintFee Private :closed_lock_with_key: :stop_sign:
mint External :exclamation: :stop_sign: lock
burn External :exclamation: :stop_sign: lock
swap External :exclamation: :stop_sign: lock
skim External :exclamation: :stop_sign: lock
sync External :exclamation: :stop_sign: lock

Legend

Symbol Meaning
:stop_sign: Function can modify state
:dollar: Function is payable
1 Like

Is it possible to look at the reward join on MIP 44?

UNI rewards are currently turned off, but if/when they get re-enabled the plan is to use the crop join and have the vault owner deal with the rewards token. This is a much simpler model and leaves all the messiness of rewards out of the core protocol. We can just charge high fees because of the farm leverage available.

MIP 44 just allow gov to withdraw UNI on the vault.

Not all vault owner will move. We might end up with million in UNI locked for ever inside the contract.

Well either way having governance manage a pile of UNI is not something we’ve done in the past and not really something we just want to toss into a contract last minute. I get the code is ready, but 90% of getting something on chain is auditing and review which takes a lot of time and resources.

That is the issue, especially for a reviewed code. We are deploying code that partially works.

Governance doesn’t need to manage anything.
The join just allow governance to withdraw uni at some point in time.

There is additional code to review though, and it is not 100% clear that UNI rewards are even going to be turned back on. If they are then we would likely deploy a new crop join with rewards support at that time and most will migrate over (why give up free $$?).

There is an additional concern with giving governance control over vault user’s collateral to do whatever they want with. Vault owners may not want this to happen. Giving full control to the user and charging them a stability fee is the preferred way in my view.

Crop join is already planned to go in as it has been voted in. Adding in Uniswap support for that once it’s ready is an easier addition than a new type of join adapter from a smart contracts review/auditing perspective. In general sticking with what you know works is a faster way to get code on chain.

1 Like

As you said they can move to crop join.

But what are you going to do with users which don’t move. All UNI will be lost forever. I believe the code is simple enough to be audited as part of the deployment. 4 lines under an auth.

No UNI is currently lost because the rewards are turned off, and it’s not clear that they will ever be turned back on.

1 Like