EIP-6682: NFT Flashloans

EIPs
,
1

This standard is an extension of the existing flashloan standard (EIP-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.

The current flashloan standard, EIP-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.

I tried quite hard to make this EIP have as minimal additional requirements from EIP-3156 as possible. There are only 2 methods:

interface IERC6682 {
    /// @dev The address of the token used to pay flash loan fees.
    function flashFeeToken() external view returns (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.
    function availableForFlashLoan(address token, uint256 tokenId) external view returns (bool);
}

Here is the link to the EIP:

I’ve also created an example implementation here (in addition to the reference implementation in the spec): GitHub - outdoteth/ERC-6682-example: Example implementation of NFT flashloans

1 Like
2

Since NFTs are non-fungible, would it make sense to give each token the ability to decide its own willingness to flashloan, its own fee, and its own recipient?

This might be too overloaded for a single function, but maybe something like:

function availableForFlashLoan(address token, uint256 tokenId) external view returns (bool isLoanable, address sendFeeTo, uint256 feeAmount);

I’m specifically imagining a scenario where an NFT has native flashloan support, and the owners can set their own settings.

1 Like
3

Interesting proposal. Can you elaborate on some use cases for borrowing an NFT and returning it in the same transaction?

4

The existing flashFee method already allows for customising the fee on a per-NFT basis so this proposed addition would only allow for the addition of customising the recipient per NFT. In my opinion, this offers quite a bit of excessive customisation with a non-trivial technical cost in the form of complexity and also the fact that it breaks backwards compatibility with EIP-3156.

5

A flash loan could be useful in any action where NFT ownership is checked.

For example; claiming airdrops, claiming staking rewards, taking an in-game action such as claiming farmed resources etc.

6

Oops you’re right, I didn’t notice that you were overloading amount as tokenId to stay backwards compatible. :slight_smile: