Approvals

In this tutorial you'll learn the basics of an approval management system which will allow you to grant others access to transfer NFTs on your behalf.

This is the backbone of all NFT marketplaces and allows for some complex yet beautiful scenarios to happen. If you're joining us for the first time, feel free to clone this repository and go to the nft-contract-basic/ folder to follow along.

cd nft-contract-basic/

tip

If you wish to see the finished code for this Approval tutorial, you can find it on the nft-contract-approval/ folder.

Introduction

Up until this point you've created a smart contract that allows users to mint and transfer NFTs as well as query for information using the enumeration standard. As we've been doing in the previous tutorials, let's break down the problem into smaller, more digestible, tasks.

Let's first define some of the end goals that we want to accomplish as per the approval management extension of the standard. We want a user to have the ability to:

Grant other accounts access to transfer their NFTs on a per token basis.
Check if an account has access to a specific token.
Revoke a specific account the ability to transfer an NFT.
Revoke all other accounts the ability to transfer an NFT.

If you look at all these goals, they are all on a per token basis. This is a strong indication that you should change the Token struct which keeps track of information for each token.

Allow an account to transfer your NFT

Let's start by trying to accomplish the first goal. How can you grant another account access to transfer an NFT on your behalf?

The simplest way that you can achieve this is to add a list of approved accounts to the Token struct. When transferring the NFT, if the caller is not the owner, you could check if they're in the list.

Before transferring, you would need to clear the list of approved accounts since the new owner wouldn't expect the accounts approved by the original owner to still have access to transfer their new NFT.

The problem

On the surface, this would work, but if you start thinking about the edge cases, some problems arise. Often times when doing development, a common approach is to think about the easiest and most straightforward solution. Once you've figured it out, you can start to branch off and think about optimizations and edge cases.

Let's consider the following scenario. Benji has an NFT and gives two separate marketplaces access to transfer his token. By doing so, he's putting the NFT for sale (more about that in the marketplace integrations section). Let's say he put the NFT for sale for 1 NEAR on both markets. The tokens list of approved account IDs would look like the following:

Token: {
    owner_id: Benji
    approved_accounts_ids: [marketplace A, marketplace B]
}

Josh then comes along and purchases the NFT on marketplace A for 1 NEAR. This would take the sale down from the marketplace A and clear the list of approved accounts. Marketplace B, however, still has the token listed for sale for 1 NEAR and has no way of knowing that the token was purchased on marketplace A by Josh. The new token struct would look as follows:

Token: {
    owner_id: Josh
    approved_accounts_ids: []
}

Let's say Josh is low on cash and wants to flip this NFT and put it for sale for 10 times the price on marketplace B. He goes to put it for sale and for whatever reason, the marketplace is built in a way that if you try to put a token up for sale twice, it keeps the old sale data. This would mean that from marketplace B's perspective, the token is still for sale for 1 NEAR (which was the price that Benji had originally listed it for).

Since Josh approved the marketplace to try and put it for sale, the token struct would look as follows:

Token: {
    owner_id: Josh
    approved_accounts_ids: [marketplace A, marketplace B]
}

If Mike then comes along and purchases the NFT for only 1 NEAR on marketplace B, the marketplace would go to try and transfer the NFT and since technically, Josh approved the marketplace and it's in the list of approved accounts, the transaction would go through properly.

The solution

Now that we've identified a problem with the original solution, let's think about ways that we can fix it. What would happen now if, instead of just keeping track of a list of approved accounts, you introduced a specific ID that went along with each approved account. The new approved accounts would now be a map instead of a list. It would map an account to it's approval id.

For this to work, you need to make sure that the approval ID is always a unique, new ID. If you set it as an integer that always increases by 1 whenever u approve an account, this should work. Let's consider the same scenario with the new solution.

Benji puts his NFT for sale for 1 NEAR on marketplace A and marketplace B by approving both marketplaces. The "next approval ID" would start off at 0 when the NFT was first minted and will increase from there. This would result in the following token struct:

Token: {
    owner_id: Benji
    approved_accounts_ids: {
        marketplace A: 0
        marketplace B: 1
    }
    next_approval_id: 2
}

When Benji approved marketplace A, it took the original value of next_approval_id which started off at 0. The marketplace was then inserted into the map and the next approval ID was incremented. This process happened again for marketplace B and the next approval ID was again incremented where it's now 2.

Josh comes along and purchases the NFT on marketplace A for 1 NEAR. Notice how the next approval ID stayed at 2:

Token: {
    owner_id: Josh
    approved_accounts_ids: {}
    next_approval_id: 2
}

Josh then flips the NFT because he's once again low on cash and approves marketplace B:

Token: {
    owner_id: Josh
    approved_accounts_ids: {
        marketplace B: 2
    }
    next_approval_id: 3
}

The marketplace is inserted into the map and the next approval ID is incremented. From marketplace B's perspective it stores it's original approval ID from when Benji put the NFT up for sale which has a value of 1. If Mike were to go and purchase the NFT on marketplace B for the original 1 NEAR sale price, the NFT contract should panic. This is because the marketplace is trying to transfer the NFT with an approval ID 1 but the token struct shows that it should have an approval ID of 2.

Expanding the `Token` and `JsonToken` structs

Now that you understand the proposed solution to the original problem of allowing an account to transfer your NFT, it's time to implement some of the logic. The first thing you should do is modify the Token and JsonToken structs to reflect the new changes. Let's switch over to the nft-contract-basic/src/metadata.rs file:

Loading...

Introduction​

Allow an account to transfer your NFT​

The problem​

The solution​

Expanding the Token and JsonToken structs​

Approving accounts​

Internal functions​

Changing the restrictions for transferring NFTs​

Refunding storage on transfer​

Changes to nft_core.rs​

Check if an account is approved​

Revoke an account​

Revoke all accounts​

Testing the new changes​

Deployment and initialization​

Minting​

Approving an account​

Transferring an NFT as an approved account​

Conclusion​

Introduction

Allow an account to transfer your NFT

The problem

The solution

Expanding the `Token` and `JsonToken` structs

Approving accounts

Internal functions

Changing the restrictions for transferring NFTs

Refunding storage on transfer

Changes to `nft_core.rs`

Check if an account is approved

Revoke an account

Revoke all accounts

Testing the new changes

Deployment and initialization

Minting

Approving an account

Transferring an NFT as an approved account

Conclusion