search

code-423n4 / 2022-01-livepeer-findings

0 stars 0 forks source link

EIP2612 in token problematic #118

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

Handle

sirhashalot

Vulnerability details

Impact

There are two issues that may occur from inheriting EIP2612 in the Livepeer Token:

  1. The Livepeer token on layer 1 does not inherit EIP2612 functions like permit(). Using EIP2612 in the Livepeer token on layer 2 would cause it to act slightly differently than then Livepeer token on layer 1. This misalignment between the layers could cause misunderstanding of the 2 step transfer process in place on layer 1 when users can approve transactions in 1 step on layer 2.
  2. EIP2612 is still in draft: https://eips.ethereum.org/EIPS/eip-2612 Using a draft EIP in a production contract can cause problems if the EIP is modified. Changes to the EIP or the OpenZeppelin library could result in the permit() function failing to work as expected. Such behavior could impact all Livepeer token users on Arbitrum L2.

Proof of Concept

The OpenZeppelin draft EIP2612 contract is imported in L2/token/LivepeerToken.sol

Recommended Mitigation Steps

Make the Layer 1 and Layer 2 Livepeer tokens consistent. Or wait until EIP2612 is finalized before including functions from it on the mainnet.

yondonfu commented 2 years ago

Severity: 0 (Non-critical)

We don't believe there are any actual issues with this and while the points raised are true we think the benefits UX improvements from supporting permit() in the L2 LPT contract outweigh the concerns from those points.

0xleastwood commented 2 years ago

Agree with sponsor, marking as non-critical.