error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> ERCS/erc-2612.md | 16 | 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. | = help: see https://ethereum.github.io/eipw/markdown-refs/

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> ERCS/erc-2612.md | 18 | 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. |

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> ERCS/erc-2612.md | 18 | 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. |

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> ERCS/erc-2612.md | 20 | 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`. |

error[markdown-refs]: unable to read file `erc-712.md`: Io: JsValue(Error: ENOENT: no such file or directory, open 'ERCS/erc-712.md' Error: ENOENT: no such file or directory, open 'ERCS/erc-712.md') --> ERCS/erc-2612.md | 22 | 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. |

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> ERCS/erc-2612.md | 24 | **_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. |

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> ERCS/erc-2612.md | 28 | 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. |

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> ERCS/erc-2612.md | 30 | 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. |

error[markdown-refs]: references to proposals with a `category` of `ERC` must use a prefix of `ERC` --> ERCS/erc-2612.md | 32 | 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. |