Introduction
On the blockchain, Non-Fungible Tokens serve as distinct ownership records. An NFT is typically linked to a valuable and uncommon item, such as a work of art, a ticket to a performance, a collectible cat, a hostname, or a real entity. Depending on the contract, NFTs may be minted, purchased, sold, or destroyed. Ethereum-based NFTs are Cryptokitties and SuperRare. NFTs can be implemented on NEAR.
There are a lot of rules about NFTs! But by far, the most popular is the ERC721 standard, which says things like how NFTs can be developed and transferred. This sustained long-term well, but like all ERC standards, it is only defined for the Ethereum platform. ERC721 may be portable to NEAR once NEAR EVM emulation is ready. Still, for now, the NEAR team has made an NFT reference implementation that requires a different NFT standard: NEP-4, which is described in a language-independent manner that is more
NEAR Protocol
NEAR Protocol is a new generation of layer one blockchain that solves problems like limited throughput, slow transaction rates, and poor compatibility. It is based sharding, which means that when network usage is high, nodes are split into smaller pieces called “shards,” and computing is done in parallel across these pieces. This network can grow to meet more users’ needs.
What is NEP -4?
NEP-4 is a very simple standard that only does the bare minimum to support the ownership and transfer of NFTs. However, it does include the ability to give power to other users or other smart contracts. This is a powerful feature because it means improvements could be made in the future by making cross-contract calls with a smart contract instead of upgrading the contract we write today. Other NFT projects on NEAR have already started to help NEP-4, so it’s a good choice for the short term.
This tutorial will show you how to build a smart contract for the Near protocol that will mint NFTs.
Prerequisite
To build the near-smart contract that we require.
Rust:
We will develop a smart contract using Rust’s high-performance general-purpose programming language.
Near CLI:
Use the Near CLI command-line interface to connect to and interact with the near blockchain.
Near Wallet:
Before beginning our project, we require a near wallet.
Setup
To get started, Create a cargo project.
cargo new nft --libGo to project folder nft you will see.
src/lib.rs — This is where we are going to write our smart contract
Cargo.toml — This is our project configuration file
Go to the cargo.toml and add
[lib]
crate-type = ["cdylib", "rlib"]
[dependencies]
near-sdk = "*"
near-contract-standards = "*"
Getting Started
use near_sdk::{
near_bindgen,
borsh::{self, BorshDeserialize, BorshSerialize}
};
near_sdk::setup_alloc!();
#[near_bindgen]
#[derive(BorshDeserialize, BorshDeserialize)]
pub struct Contract {}
#[near_bindgen]
impl Contract {}
Let’s simplify this strange-looking code without taking any action just now. Because NEAR employs a stateful methodology, our contract state will be held in struct Contract, and we will code our state-changing methods in the implementation Contract.
It should be noticed that in this case, we are using specific macros and deriving characteristics. The state is changed using the #[near bindgen] macro so that it can be live on the NEAR chain. The features from the Borsh crate for the deserializing and serializing state are BorshDeserialize and BorshDeserialize.
Let’s now designate our state for NFT. You are aware that NFT has certain metadata attached to it. According to this description, our state appears as follows.
use near_contract_standards::non_fungible_token::{
metadata::NFTContractMetadata, NonFungibleToken,
};
pub struct Contract {
token: NonFungibleToken,
metadata: LazyOption<NFTContractMetadata>,
}
The default value for this state must always be set; hence an initializer function is required.
#[derive(BorshSerialize, BorshStorageKey)]
pub enum StorageKey {
NonFungibleToken,
Metadata,
TokenMetadata,
Enumeration,
Approval
}
#[near_bindgen]
impl Contract {
#[init]
pub fn new(owner_id: ValidAccountId) -> Self {
Self {
token: NonFungibleToken::new(
StorageKey::NonFungibleToken,
owner_id,
Some(StorageKey::TokenMetadata),
Some(StorageKey::Enumeration),
Some(StorageKey::Approval)
),
metadata: LazyOption::new(
StorageKey::Metadata,
Some(&NFTContractMetadata {
spec: NFT_METADATA_SPEC.to_string(),
name: "Example Name".to_string(),
symbol: "Example".to_string(),
icon: Some("ANY_SVG".to_string()),
base_uri: None,
reference: None,
reference_hash: None,
})
),
}
}
}
The #[init] macro-enabled function will always run first. It is usually employed to establish the default state.
Everything for our initializer and state is now established. Let’s implement functional NFT minting.
impl Contract {
......
#[payable]
pub fn nft_mint(
&mut self,
token_id: TokenId,
receiver_id: ValidAccountId,
token_metadata: TokenMetadata,
) -> Token {
self.token.mint(token_id, receiver_id, Some(token_metadata))
}
}This should be deployed to the chain. To build, enter the following command:
cargo build --target wasm32-unknown-unknown --releaseRun the following command to deploy
near deploy --wasmFile target/wasm32-unknown-unknown/release/nft.wasm --accountId "your near account username"This will provide you with a program id that you may use to access the smart contract’s RPCs. You may use the nearby CLI or the javascript client to communicate with the contract.
Kryptomind is a USA-based NFT minting company that has completed several profitable NFT projects for its clients. To get the most outstanding outcomes, our work methodology uses the most recent technologies and methods. We want to make the complex process of minting NFTs as simple as possible. At Kryptomind, our team of committed specialists works hard to meet your goals and requirements.
