Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove SafeERC20.safePermit #4582

Merged
merged 14 commits into from
Sep 11, 2023
Prev Previous commit
Update IERC20Permit.sol
  • Loading branch information
frangio authored Sep 11, 2023
commit 487b3f9cdd0561e151d4965ca18590bba907209a
4 changes: 2 additions & 2 deletions contracts/token/ERC20/extensions/IERC20Permit.sol
Copy link
Contributor

@frangio frangio Sep 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like IERC20Permit is not listed in the docs site. (https://docs.openzeppelin.com/contracts/4.x/api/token/erc20)

I added it in this PR, let's see if it looks nice.

When we have this interface/implementation separation I don't like having duplicate docs in the site. The same applies to I/AccessManager, for example. But if the interface is in the library it should be somewhere in the documentation... so I may have to accept adding it.

Using @inheritdoc leads to more duplication but it might make it nicer to navigate than a link like "See IERC20Permit.permit".

Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ pragma solidity ^0.8.20;
*
* There are two important considerations concerning the use of `permit`. The first is that a valid permit signature
* expresses an allowance, and it should not be assumed to convey additional meaning. In particular, it should not be
* considered as an intention to spend the approval in any specific way. The second is that because permits have
* considered as an intention to spend the allowance in any specific way. The second is that because permits have
* built-in replay protection and can be submitted by anyone, they can be frontrun. A protocol that uses permits should
* take this into consideration and allow a `permit` call to fail. Combining these two aspects, a pattern that may be
* generally recommended is:
Expand All @@ -32,7 +32,7 @@ pragma solidity ^0.8.20;
* }
* ```
*
* Observe that: 1) `msg.sender` is used as the owner, leaving no ambiguity as to the signer intent, 2) the use of
* Observe that: 1) `msg.sender` is used as the owner, leaving no ambiguity as to the signer intent, and 2) the use of
* `try/catch` allows the permit to fail and makes the code tolerant to frontrunning. (See also
* {SafeERC20-safeTransferFrom}).
*
Expand Down