a
How to Mint NFTs on Flow

How to Mint NFTs on Flow

This is part of a three step tutorial on minting NFTs on Flow.

A three-step How to on minting NFTs

Navigating back to our allcode-nft directory in terminal that we created in Part 1. Let’s create a new directory within the root of our allcode-nft project called transactions. Within the new transactions directory, create a new file entitled MintAllCodeNFT.cdc.

Inside your MintAllCodeNFT.cdc, insert the following Cadence code:

import AllCodeNFTContract from 0xf8d6e0586b0a20c7

transaction {
  let receiverRef: &{AllCodeNFTContract.NFTReceiver}
  let minterRef: &AllCodeNFTContract.NFTMinter

  prepare(acct: AuthAccount) {
      self.receiverRef = acct.getCapability<&{AllCodeNFTContract.NFTReceiver}>(/public/NFTReceiver)
          .borrow()
          ?? panic("Could not borrow receiver reference")

      self.minterRef = acct.borrow<&AllCodeNFTContract.NFTMinter>(from: /storage/NFTMinter)
          ?? panic("could not borrow minter reference")
  }

  execute {
      let metadata : {String : String} = {
          "name": "AllCode Logo",
          "street_address": "Fillmore Street",
          "phone_number": "415-890-6431",
          "email": "[email protected]",
          "uri": "ipfs://QmVH5T7MFVU52hTfQdWvu73iFPEF3jizuGfyVLccTmBCX2"
      }
      let newNFT <- self.minterRef.mintNFT()

      self.receiverRef.deposit(token: <-newNFT, metadata: metadata)

      log("NFT Minted and deposited to Account 2's Collection")
  }
}

 

Let’s start at the top of the file. You’ll notice the import statement on the first line. When we deployed the AllCodeNFTContract, we received the contract address output that we are importing here. We’re merely importing the contract from the public address. After you deploy your contract, then replace your public address accordingly.

 

AllCode NFT Mint 1
Next, we defined the transaction. We define to reference variables receiverRef and minterRef. In this transaction, we are both the receiver and minter of the NFT.

After the variable definitions, we have the prepare function. The prepare function validates that the account has the permission to borrow the NFTReceiver and NFTMinter functionality. If the account does not have the permission, then the panic function will be invoked, and the operation will fail. 

Last, we have the execute function. In this function, we build the metadata for the NFT with the uri pointing to IPFS CID for the NFT content that we obtained in our previous post. In this case, the metadata contains extra attributes. We mint the token and deposit the token into the receiverRef of this account.

We’re almost ready to mint our NFT, but first we need to run a few commands in Flow. 

Run the following command:

flow keys generate

This command will generate public and private keys. Remember to store the private key safely and don’t share with anyone! 

We will need the private key to sign the transaction, so we can paste that into our flow.json file. We also need to specify the signing algorithm.

Here’s what your accounts object in the flow.json file should look like now:

"accounts": {
  "emulator-account": {
     "address": "YOUR ACCOUNT ADDRESS",
     "privateKey": "YOUR PRIVATE KEY",
     "chain": "flow-emulator",
     "sigAlgorithm": "ECDSA_P256",
     "hashAlgorithm": "SHA3_256"
  }
},

If you intend to store any of this project on github or any remote git repository, make sure you do not include the private key. You may want to .gitignore your entire flow.json. Even though we are only using a local emulator, it’s good practice to protect your keys.

Now that we’ve updated our keys, we can send our transaction. Doing so is as simple as running this command:

flow transactions send ./transactions/MintAllCodeNFT.cdc --signer emulator-account

In this command, we are referencing the transaction file we wrote and our signer account from the flow.json. If everything went well, you should see an output like this:

Transaction ID: 7299859f23b3359555f99b520de944ced86bfcbd14da6b13d439b2db96573519
Status ✅ SEALED
ID 7299859f23b3359555f99b520de944ced86bfcbd14da6b13d439b2db96573519
Payer f8d6e0586b0a20c7
Authorizers [f8d6e0586b0a20c7]
Proposal Key:
Address f8d6e0586b0a20c7
Index 0
Sequence 2
No Payload Signatures
Envelope Signature 0: f8d6e0586b0a20c7
Signatures (minimized, use --include signatures)
Events: None
Code (hidden, use --include code)
Payload (hidden, use --include payload)

Now, the last thing we need to do is verify the token is in our account and fetch the metadata. To do this, we’re going to write a very simple script and call it from the command line.

From the root of your project, create a new folder called scripts. Inside of that, create a file called CheckTokenMetadata.cdc. In that file, add the following:

import AllCodeNFTContract from 0xf8d6e0586b0a20c7

pub fun main() : {String : String} {
    let nftOwner = getAccount(0xf8d6e0586b0a20c7)
    // log("NFT Owner")
    let capability = nftOwner.getCapability<&{AllCodeNFTContract.NFTReceiver}>(/public/NFTReceiver)

    let receiverRef = capability.borrow()
        ?? panic("Could not borrow the receiver reference")

    return receiverRef.getMetadata(id: 1)
}

This script can be thought of in the same way as the way that read-only methods on Ethereum smart contracts are utilized. They are free and simply return data from the contract.

In our script, we are importing our contract from the deployed address. We are then defining a main function (which is the required function name for a script to run). Inside this function, we’re defining three variables:

  • nftOwner: This is simply the account that owns the NFT. We minted the NFT from the account that also deployed the contract, so in our example those two addresses are the same. This may not always be true depending on the design of your contracts in the future.
  • Capability: We need to “borrow” the available capabilities (or functions) from the deployed contract. Remember, these capabilities are access-controlled, so if a capability is not available to the address to borrow, the script will fail. We are borrowing capabilities from the NFTReceiver resource.
  • receiverRef: This variable simply takes our capability and tells the script to borrow from the deployed contract.

Now, we can call functions (that are available to us). In this case, we want to make sure the address in question actually has received the NFT we minted, and then we want to see the metadata associated with the token.

Let’s run our script and see what we get. Run the following on the command line:

flow scripts execute ./scripts/CheckTokenMetadata.cdc

You should see an output something like this for the metadata output:

Result: {
  "name": "AllCode Logo", 
  "street_address": "Fillmore Street", 
  "phone_number": "415-890-6431", 
  "email": "[email protected]", 
  "uri":"ipfs://QmVH5T7MFVU52hTfQdWvu73iFPEF3jizuGfyVLccTmBCX2"
}

Congratulations! You successfully created a Flow smart contract, minted a token, and associated metadata to the token, and stored the token’s underlying digital asset on IPFS.

 

allcode_admin

allcode_admin

Related Articles

The Difference Between Amazon RDS and Aurora

The Difference Between Amazon RDS and Aurora

AWS does incorporate several database services that offer high performance and great functionality. However, customers do find the difference between Amazon Relational Database Service and Amazon Aurora. Both services do provide similar functions, but do cover their own use cases.

AWS Snowflake Data Warehouse Pricing Guide

AWS Snowflake Data Warehouse Pricing Guide

AWS Snowflake Data Warehouse – or just Snowflake – is a data cloud built for users to mobilize, centralize, and process large quantities of data. Regardless of how many sources are connected to Snowflake or the user’s preferred type of organized data used, data is easily stored and controllably shared with selectively-authorized access. Snowflake does offer extensive control over its pricing, though how it works isn’t always clear.

Guide to Cost Factors for Amazon’s RDS Pricing

Guide to Cost Factors for Amazon’s RDS Pricing

Addressing the question of what influences Amazon RDS costs, it’s important to note that Amazon sports a complex pricing model. While the pay-for-what-you-use model seems straightforward, there are nuanced aspects to consider. Factors such as data usage and the choice of computing components can swiftly deplete one’s budget allocation. However, this doesn’t mean that AWS is inherently costly. With proper planning and a deep understanding of the contributing elements to billing, users can navigate and optimize their expenses effectively.

Download our 10-Step Cloud Migration ChecklistYou'll get direct access to our full-length guide on Google Docs. From here, you will be able to make a copy, download the content, and share it with your team.