Update EIP-2612: Move to Last Call (#5506)

* Move EIP-2612 to Last Call

* replace ERC- with EIP-

* Update EIPS/eip-2612.md

Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>

* remove external links

* ERC -> EIP

* remove external links

* delay deadline

* Create UniswapV2ERC20.spec.ts

* Create UniswapV2ERC20.sol

* Use files in assets folder

* add missing assets and license

* edit title and description

* Fix YAML Error

* fix asset links

* push last-call-deadline

* remove reference implementation and test cases

* postpone deadline

Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>

EIPS/eip-2612.md

@@ -1,41 +1,42 @@
 ---
 eip: 2612
-title: permit – 712-signed approvals
-description: ERC-20 approvals via secp256k1 signatures
+title: "EIP-20 Permit Extension: Signed Approvals"
+description: EIP-20 approvals via EIP-712 secp256k1 signatures
 author: Martin Lundfall (@Mrchico)
 discussions-to: https://github.com/ethereum/EIPs/issues/2613
-status: Review
+status: Last Call
+last-call-deadline: 2022-10-08
 type: Standards Track
 category: ERC
 created: 2020-04-13
 requires: 20, 712
 ---
 
 ## Abstract
-Arguably one of the main reasons for the success of [ERC-20](./eip-20.md) tokens lies in the interplay between `approve` and `transferFrom`, which allows for tokens to not only be transferred between externally owned accounts (EOA), but to be used in other contracts under application specific conditions by abstracting away `msg.sender` as the defining mechanism for token access control.
+Arguably one of the main reasons for the success of [EIP-20](./eip-20.md) tokens lies in the interplay between `approve` and `transferFrom`, which allows for tokens to not only be transferred between externally owned accounts (EOA), but to be used in other contracts under application specific conditions by abstracting away `msg.sender` as the defining mechanism for token access control.
 
-However, a limiting factor in this design stems from the fact that the ERC-20 `approve` function itself is defined in terms of `msg.sender`. This means that user's _initial action_ involving ERC-20 tokens must be performed by an EOA (_but see Note below_). If the user needs to interact with a smart contract, then they need to make 2 transactions (`approve` and the smart contract call which will internally call `transferFrom`). Even in the simple use case of paying another person, they need to hold ETH to pay for transaction gas costs.
+However, a limiting factor in this design stems from the fact that the EIP-20 `approve` function itself is defined in terms of `msg.sender`. This means that user's _initial action_ involving EIP-20 tokens must be performed by an EOA (_but see Note below_). If the user needs to interact with a smart contract, then they need to make 2 transactions (`approve` and the smart contract call which will internally call `transferFrom`). Even in the simple use case of paying another person, they need to hold ETH to pay for transaction gas costs.
 
-This ERC extends the ERC-20 standard with a new function `permit`, which allows users to modify the `allowance` mapping using a signed message, instead of through `msg.sender`. 
+This ERC extends the EIP-20 standard with a new function `permit`, which allows users to modify the `allowance` mapping using a signed message, instead of through `msg.sender`. 
 
-For an improved user experience, the signed data is structured following [ERC-712](./eip-712.md), which already has wide spread adoption in major RPC providers.
+For an improved user experience, the signed data is structured following [EIP-712](./eip-712.md), which already has wide spread adoption in major RPC providers.
 
-**_Note:_** ERC-20 must be performed by an EOA unless the address owning the token is actually a contract wallet. Although contract wallets solves many of the same problems that motivates this EIP, they are currently only scarcely adopted in the ecosystem. Contract wallets suffer from a UX problem -- since they separate the EOA `owner` of the contract wallet from the contract wallet itself (which is meant to carry out actions on the `owner`s behalf and holds all of their funds), user interfaces need to be specifically designed to support them. The `permit` pattern reaps many of the same benefits while requiring little to no change in user interfaces.
+**_Note:_** EIP-20 must be performed by an EOA unless the address owning the token is actually a contract wallet. Although contract wallets solves many of the same problems that motivates this EIP, they are currently only scarcely adopted in the ecosystem. Contract wallets suffer from a UX problem -- since they separate the EOA `owner` of the contract wallet from the contract wallet itself (which is meant to carry out actions on the `owner`s behalf and holds all of their funds), user interfaces need to be specifically designed to support them. The `permit` pattern reaps many of the same benefits while requiring little to no change in user interfaces.
 
 ## Motivation
-While ERC-20 tokens have become ubiquitous in the Ethereum ecosystem, their status remains that of second class tokens from the perspective of the protocol. The ability for users to interact with Ethereum without holding any ETH has been a [long outstanding goal](./eip-101.md) and the [subject](./eip-1077.md) [of](./eip-777.md) [many](https://github.com/ethereum/EIPs/issues/1776) [EIPs](./eip-1271.md).
+While EIP-20 tokens have become ubiquitous in the Ethereum ecosystem, their status remains that of second class tokens from the perspective of the protocol. The ability for users to interact with Ethereum without holding any ETH has been a long outstanding goal and the subject of many EIPs.
 
-So far, many of these proposals have seen very little adoption, and the ones that have been adopted (such as [ERC-777](./eip-777.md)), introduce a lot of additional functionality, causing [unexpected behavior in mainstream contracts](https://medium.com/consensys-diligence/uniswap-audit-b90335ac007).
+So far, many of these proposals have seen very little adoption, and the ones that have been adopted (such as [EIP-777](./eip-777.md)), introduce a lot of additional functionality, causing unexpected behavior in mainstream contracts.
 
-This ERC proposes an alternative solution which is designed to be as minimal as possible and to only address _one problem_: the lack of abstraction in the ERC-20 `approve` method. 
+This ERC proposes an alternative solution which is designed to be as minimal as possible and to only address _one problem_: the lack of abstraction in the EIP-20 `approve` method. 
 
-While it may be tempting to introduce `*_by_signature` counterparts for every ERC-20 function, they are intentionally left out of this ERC-20 for two reasons:
+While it may be tempting to introduce `*_by_signature` counterparts for every EIP-20 function, they are intentionally left out of this EIP-20 for two reasons:
 
  - the desired specifics of such functions, such as decision regarding fees for `transfer_by_signature`, possible batching algorithms, varies depending on the use case, and,
  - they can be implemented using a combination of `permit` and additional helper contracts without loss of generality.
 
 ## Specification
-Three new functions are added to the ERC-20 ABI:
+Three new functions are added to the EIP-20 ABI:
 ```sol
 function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external
 function nonces(address owner) external view returns (uint)
@@ -85,7 +86,7 @@ DOMAIN_SEPARATOR = keccak256(
 ));
 ```
 
-In other words, the message is the ERC-712 typed structure:
+In other words, the message is the EIP-712 typed structure:
 
 ```js
 {
@@ -150,16 +151,13 @@ Note that nowhere in this definition we refer to `msg.sender`. The caller of the
 
 
 ## Rationale
-The `permit` function is sufficient for enabling any operation involving ERC-20 tokens to be paid for using the token itself, rather than using ETH. 
-An example of a contract which enables gasless token transactions can be found [here](https://github.com/dapphub/ds-dach).
-
-It avoids any calls to unknown code.
+The `permit` function is sufficient for enabling any operation involving EIP-20 tokens to be paid for using the token itself, rather than using ETH. 
 
 The `nonces` mapping is given for replay protection.
 
 A common use case of `permit` has a relayer submit a `Permit` on behalf of the `owner`. In this scenario, the relaying party is essentially given a free option to submit or withhold the `Permit`. If this is a cause of concern, the `owner` can limit the time a `Permit` is valid for by setting `deadline` to a value in the near future. The `deadline` argument can be set to `uint(-1)` to create `Permit`s that effectively never expire.
 
-ERC-712 typed messages are included because of its wide spread adoption in many wallet providers.
+EIP-712 typed messages are included because of its wide spread adoption in many wallet providers.
 
 
 ## Backwards Compatibility
@@ -169,19 +167,12 @@ Its implementation differs slightly from the presentation here in that:
 - instead of taking a `value` argument, it takes a bool `allowed`, setting approval to 0 or `uint(-1)`.
 - the `deadline` argument is instead called `expiry`. This is not just a syntactic change, as it effects the contents of the signed message.
 
-There is also an implementation in the token [`Stake`](https://etherscan.io/address/0x0Ae055097C6d159879521C384F1D2123D1f195e6#code) with the same ABI as `dai` but with different semantics: it lets users issue "expiring approvals", that only allow `transferFrom` to occur while `expiry >= block.timestamp`.
+There is also an implementation in the token `Stake` (Ethereum address `0x0Ae055097C6d159879521C384F1D2123D1f195e6`) with the same ABI as `dai` but with different semantics: it lets users issue "expiring approvals", that only allow `transferFrom` to occur while `expiry >= block.timestamp`.
 
-The specification presented here is in line with the implementation in [Uniswap-v2](https://github.com/uniswap/uniswap-v2-core).
+The specification presented here is in line with the implementation in Uniswap V2.
 
 The requirement to revert if the permit is invalid was added when the EIP was already widely deployed, but at the moment it was consistent with all found implementations.
 
-## Test Cases
-
-Some basic tests can be found here https://github.com/Uniswap/uniswap-v2-core/blob/master/test/UniswapV2ERC20.spec.ts.
-
-## Reference Implementation
-[UniswapV2ERC20.sol](https://github.com/Uniswap/uniswap-v2-core/blob/master/contracts/UniswapV2ERC20.sol)
-
 ## Security Considerations
 
 Though the signer of a `Permit` may have a certain party in mind to submit their transaction, another party can always front run this transaction and call `permit` before the intended party. The end result is the same for the `Permit` signer, however.
@@ -190,7 +181,7 @@ Since the ecrecover precompile fails silently and just returns the zero address
 
 Signed `Permit` messages are censorable. The relaying party can always choose to not submit the `Permit` after having received it, withholding the option to submit it. The `deadline` parameter is one mitigation to this. If the signing party holds ETH they can also just submit the `Permit` themselves, which can render previously signed `Permit`s invalid.
 
-The standard [ERC-20 race condition for approvals](https://swcregistry.io/docs/SWC-114) applies to `permit` as well.
+The standard EIP-20 race condition for approvals (SWC-114) applies to `permit` as well.
 
 If the `DOMAIN_SEPARATOR` contains the `chainId` and is defined at contract deployment instead of reconstructed for every signature, there is a risk of possible replay attacks between chains in the event of a future chain split.