status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-22 11:48:19 +00:00
Code Issues Projects Releases Wiki Activity

erc3156: made security around automatic approvals clearer (#3425)

Browse Source
This commit is contained in:
Alberto Cuesta Cañada 2021-04-16 10:29:20 +01:00 committed by GitHub
parent e84f21e643
commit fa5d1efef6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
EIPS/eip-3156.md
View File

@ -101,7 +101,7 @@ function flashLoan(
}
```
The `flashLoan` function MUST transfer `amount` of `token` to `receiver` before the callback to the borrower.
The `flashLoan` function MUST transfer `amount` of `token` to `receiver` before the callback to the receiver.
The `flashLoan` function MUST include `msg.sender` as the `initiator` to `onFlashLoan`.
@ -471,12 +471,14 @@ The arguments of `onFlashLoan` are expected to reflect the conditions of the fla
### Flash lending security considerations
#### Automatic approvals for untrusted borrowers
#### Automatic approvals
The safest approach is to implement an approval for `amount+fee` before the `flashLoan` is executed.
Including in `onFlashLoan` the approval for the `lender` to take the `amount + fee` needs to be combined with a mechanism to verify that the borrower is trusted, such as those described above.
Any `receiver` that keeps an approval for a given `lender` needs to include in `onFlashLoan` a mechanism to verify that the initiator is trusted.
If an unsuspecting contract with a non-reverting fallback function, or an EOA, would approve a `lender` implementing ERC3156, and not immediately use the approval, and if the `lender` would not verify the return value of `onFlashLoan`, then the unsuspecting contract or EOA could be drained of funds up to their allowance or balance limit. This would be executed by a `borrower` calling `flashLoan` on the victim. The flash loan would be executed and repaid, plus any fees, which would be accumulated by the `lender`. For this reason, it is important that the `lender` implements the specification in full and reverts if `onFlashLoan` doesn't return the keccak256 hash for "ERC3156FlashBorrower.onFlashLoan".
Any `receiver` that includes in `onFlashLoan` the approval for the `lender` to take the `amount + fee` needs to be combined with a mechanism to verify that the initiator is trusted.
If an unsuspecting contract with a non-reverting fallback function, or an EOA, would approve a `lender` implementing ERC3156, and not immediately use the approval, and if the `lender` would not verify the return value of `onFlashLoan`, then the unsuspecting contract or EOA could be drained of funds up to their allowance or balance limit. This would be executed by an `initiator` calling `flashLoan` on the victim. The flash loan would be executed and repaid, plus any fees, which would be accumulated by the `lender`. For this reason, it is important that the `lender` implements the specification in full and reverts if `onFlashLoan` doesn't return the keccak256 hash for "ERC3156FlashBorrower.onFlashLoan".
### Flash minting external security considerations