This standard is an extension of the existing flashloan standard (ERC-3156) to support ERC-721 NFT flashloans. It proposes a way for flashloan providers to lend NFTs to contracts, with the condition that the loan is repaid in the same transaction along with some fee.
Motivation
The current flashloan standard, ERC-3156, only supports ERC-20 tokens. ERC-721 tokens are sufficiently different from ERC-20 tokens that they require an extension of this existing standard to support them.
An NFT flash loan could be useful in any action where NFT ownership is checked. For example, claiming airdrops, claiming staking rewards, or taking an in-game action such as claiming farmed resources.
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Contract Interface
pragmasolidity^0.8.19;interfaceIERC6682{/// @dev The address of the token used to pay flash loan fees.
functionflashFeeToken()externalviewreturns(address);/// @dev Whether or not the NFT is available for a flash loan.
/// @param token The address of the NFT contract.
/// @param tokenId The ID of the NFT.
functionavailableForFlashLoan(addresstoken,uint256tokenId)externalviewreturns(bool);}
The flashFeeToken function MUST return the address of the token used to pay flash loan fees.
If the token used to pay the flash loan fees is ETH then flashFeeToken MUST return address(0).
The availableForFlashLoan function MUST return whether or not the tokenId of token is available for a flashloan. If the tokenId is not currently available for a flashloan availableForFlashLoan MUST return false instead of reverting.
Implementers MUST also implement IERC3156FlashLender.
Rationale
The above modifications are the simplest possible additions to the existing flashloan standard to support NFTs.
We choose to extend as much of the existing flashloan standard (ERC-3156) as possible instead of creating a wholly new standard because the flashloan standard is already widely adopted and few changes are required to support NFTs.
In most cases, the handling of fee payments will be desired to be paid in a separate currency to the loaned NFTs because NFTs themselves cannot always be fractionalized. Consider the following example where the flashloan provider charges a 0.1 ETH fee on each NFT that is flashloaned; The interface must provide methods that allow the borrower to determine the fee rate on each NFT and also the currency that the fee should be paid in.
Backwards Compatibility
This EIP is fully backwards compatible with ERC-3156 with the exception of the maxFlashLoan method. This method does not make sense within the context of NFTs because NFTs are not fungible. However it is part of the existing flashloan standard and so it is not possible to remove it without breaking backwards compatibility. It is RECOMMENDED that any contract implementing this EIP without the intention of supporting ERC-20 flashloans should always return 1 from maxFlashLoan. The 1 reflects the fact that only one NFT can be flashloaned per flashLoan call. For example:
functionmaxFlashLoan(addresstoken)publicpureoverridereturns(uint256){// if a contract also supports flash loans for ERC20 tokens then it can
// return some value here instead of 1
return1;}
Reference Implementation
// SPDX-License-Identifier: CC0-1.0
pragmasolidity^0.8.19;import"../interfaces/IERC20.sol";import"../interfaces/IERC721.sol";import"../interfaces/IERC3156FlashBorrower.sol";import"../interfaces/IERC3156FlashLender.sol";import"../interfaces/IERC6682.sol";contractExampleFlashLenderisIERC6682,IERC3156FlashLender{uint256internal_feePerNFT;addressinternal_flashFeeToken;constructor(uint256feePerNFT_,addressflashFeeToken_){_feePerNFT=feePerNFT_;_flashFeeToken=flashFeeToken_;}functionflashFeeToken()publicviewreturns(address){return_flashFeeToken;}functionavailableForFlashLoan(addresstoken,uint256tokenId)publicviewreturns(bool){// return if the NFT is owned by this contract
tryIERC721(token).ownerOf(tokenId)returns(addressresult){returnresult==address(this);}catch{returnfalse;}}functionflashFee(addresstoken,uint256tokenId)publicviewreturns(uint256){return_feePerNFT;}functionflashLoan(IERC3156FlashBorrowerreceiver,addresstoken,uint256tokenId,bytescalldatadata)publicreturns(bool){// check that the NFT is available for a flash loan
require(availableForFlashLoan(token,tokenId),"IERC6682: NFT not available for flash loan");// transfer the NFT to the borrower
IERC721(token).safeTransferFrom(address(this),address(receiver),tokenId);// calculate the fee
uint256fee=flashFee(token,tokenId);// call the borrower
boolsuccess=receiver.onFlashLoan(msg.sender,token,tokenId,fee,data)==keccak256("ERC3156FlashBorrower.onFlashLoan");// check that flashloan was successful
require(success,"IERC6682: Flash loan failed");// check that the NFT was returned by the borrower
require(IERC721(token).ownerOf(tokenId)==address(this),"IERC6682: NFT not returned by borrower");// transfer the fee from the borrower
IERC20(flashFeeToken()).transferFrom(msg.sender,address(this),fee);returnsuccess;}functionmaxFlashLoan(addresstoken)publicpureoverridereturns(uint256){// if a contract also supports flash loans for ERC20 tokens then it can
// return some value here instead of 1
return1;}functiononERC721Received(address,address,uint256,bytesmemory)publicreturns(bytes4){returnthis.onERC721Received.selector;}}
Security Considerations
It’s possible that the flashFeeToken method could return a malicious contract. Borrowers who intend to call the address that is returned from the flashFeeToken method should take care to ensure that the contract is not malicious. One way they could do this is by verifying that the returned address from flashFeeToken matches that of a user input.