ApproveForAll() – What is ApproveForAll() and What Exactly is Being Approved?

contract-designcontract-invocationmetamaskopenseapermissions

OpenSea asks approval (that costs gas) to list, sell NFTs you own if for the first time (until their next updates if any) using a contract interaction or function called ApproveForAll(). But what exactly are we signing away when doing this?

"Give permission to access all of your NFT" shown in the MetaMask prompt below sounds dangerous, given the numerous high-profile wallet hacks that have occurred on the Ethereum network this past year through social engineering, especially on Twitter.

In the image, the word "NFT" in blue is a link to the Etherscan page of the collection being approved. In this case, it's the well-known OpenSea Shared Storefront that they're simply calling "NFT", but this blue name could instead be "Bored Ape Yacht Club" if you were trying to approve the BAYC contract.

But the question here is, technically, what exactly are we signing away when we approve a collection contract for listing and trading on OpenSea? Approving "All of your NFT" sounds like anything that we own from a specific collection can just be taken out of our wallet without asking us for a MetaMask signature, even though we came to it only to list a NFT for sale.

Please provide a list of what ApproveForAll() actually encompasses in terms of potential events, versus the specific event (e.g. list the NFT for sale) we might have come to use it for. And is there any situation where the prompt would instead read "Give permission to access all of your funds"?

Best Answer

But the question here is, technically, what exactly are we signing away when we approve a collection contract for listing and trading on OpenSea? Approving "All of your NFT" sounds like anything that we own from a specific collection can just be taken out of our wallet without asking us for a MetaMask signature, even though we came to it only to list a NFT for sale.

This is exactly it. You're allowing an address (Usually a smart contract, but nothing prevents you from approving a user, which could then transfer your NFTs out of your wallet as it if was theirs) to spend all your tokens from a specific collection.

Please provide a list of what ApproveForAll() actually encompasses in terms of potential events, versus the specific event (e.g. list the NFT for sale) we might have come to use it for.

Well if you're interacting with a smart contract that isnt malicious, and is well designed, the answer is : nothing. Let me explain. While you are actually giving permission to that contract to do literally anything with your tokens, it cannot do anything it hasnt been programmed to do.

Let's take this very simple example contract :

contract TransferNFT {
  
  function makeTransfer(address collection, address to, uint tokenId) public {  
    IERC721(collection).transferFrom(msg.sender, to, tokenId);
  }
}

While, by calling setApprovalForAll(myContractAddress) on an NFT contract (let's say, BAYC), you're allowing my contract to transfer all of your BAYC tokens, to any address, the only situation where it would actually be able to transfer your tokens would be when you're calling makeTransfer(), only from the wallet that holds the tokens, only to the address you specified as input, and only the token you specified. (in the case of OS, it's a bit more complex obviously, they ask you for approval when you list your token so they can transfer it later when the sale is fulfilled, but it's the exact same idea)

In other words, it is perfectly safe. So safe that most dApps asks you to set approval for all of your tokens from a collection eventhough you're trying to list/transfer only one of them instead of asking you for only the one token you want to move, just to avoid asking you again for approval if you want to move more of these tokens with that smart contract in the future.

Now, if you're setting approval to a malicious address, well you just allowed them to transfer all of your tokens on your behalf, so that's what they're usually gonna do. And as soon as they do that, your tokens are gone and you'll never see them again.

And is there any situation where the prompt would instead read "Give permission to access all of your funds"?

Nop, that can't happen. 1 setApprovalForAll transaction = approving all of the tokens from ONE collection, to ONE address only.

ERC20 has a similar mechanism, btw. That's why you have to make an approval transaction when you're swapping tokens on a DEX for the first time, for example.

Related Solutions

[Ethereum] What are function modifiers

Modifiers are compile-time source code roll-ups. Functions can be "modified" by including the named modifier in the function declaration.

The _; line is mandatory. It's a merge wildcard that indicates where "the rest" of the function should go. For example, as @oktapdia suggested,

function test() public onlyOwner { ...

merges the function source with the modifier code at the _;

It is possible to place the _; at the beginning, in the middle or at the end of the modifier code. In practice, especially until you understand it really well, I would suggest the safest usage pattern is to use modifiers for consistent validation checks and only use the pattern with _; at the end. In other words, use modifiers to check some things up front and then carry on.

You can use modifiers in conjunction with getter functions. Here is a contrived example to show how you might use them together to keep code organized while you make the state discoverable to clients and ensure potentially complex logic is consistently applied.

modifier onlyIfOkayAndAuthorized {
  require(isOkay()); 
  require(isAuthorized(msg.sender));
  _;
}

// Let's say we have multiple concerns to mix and match

function isOkay() public view returns(bool isIndeed) {
  // return a check result
  return true;
}

function isAuthorized(address user) public view returns(bool isIndeed) {
  // return a check result
  return true;
}

return true are just placeholders for more meaningful results.

The idea is clients, other contracts, and other internal functions can use the getter functions to fetch/check the individual concerns (if they want to). Functions that should be guarded by a certain combination of concerns can use the modifier so the logic of it all (and your intent) remains very clear to reviewers.

So, you can have several functions like above, and they may have some tricky steps. Hopefully, they can be understood as individual concerns. Then, when used in combination, you can reduce repetition and improve readability with a modifier.

function sensitive() public onlyIfOkayAndAuthorized returns(bool success) {...

In case it isn't clear, you could accomplish something quite similar if instead of a modifier you made a third function to work with the combination and then included a require() in each function that needs it.

A function like:

function isOkayAndIsAuthorized(address user) public view returns(bool isIndeed) {
  require(isOkay());
  require(isAuthorized(user));
  returnt true;
}

Then use it like:

function sensitive() public returns(bool success) {
  require(isOkayAndIsAuthorized(msg.sender));
  // carry on
}

The security/validation concern is part of the function, and although this will work, it is arguably less readable than a modifier and the intent may be less clear.

Hope it helps.

Selling NFT with ETH on Polygon – Pros and Cons

Pros

cheaper transaction costs
faster transactions.

Cons

your assets are less secure. Do you trust polygon to not lose your funds?

Best Answer

Related Solutions

[Ethereum] What are function modifiers

Selling NFT with ETH on Polygon – Pros and Cons

Related Topic