EIP-6682: NFT Flashloans

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

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

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

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.

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.

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