ERC-6682: NFT Flashloans

Minimal interface for ERC-721 NFT flashloans


Metadata
Status: DraftStandards Track: ERCCreated: 2023-03-12
Authors
out.eth (@outdoteth)

Abstract


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


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:


Reference Implementation



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.

Needs discussion.

Copyright


Copyright and related rights waived via CC0.