Module near_contract_standards::non_fungible_token

Non-fungible tokens as described in by the spec.

Modules

approval	The approval management standard for NFTs.
core	The core non-fungible token standard. This can be though of as the base standard, with the others being extension standards.
enumeration	Common implementation of the core non-fungible token standard. Trait for the NFT enumeration standard. This provides useful view-only methods returning token supply, tokens by owner, etc.
metadata	Metadata traits and implementation according to the NFT enumeration standard. This covers both the contract metadata and the individual token metadata.

Structs

NonFungibleToken

Implementation of the non-fungible token standard. Allows to include NEP-171 compatible token to any contract. There are next traits that any contract may implement: - NonFungibleTokenCore – interface with nft_transfer methods. NonFungibleToken provides methods for it. - NonFungibleTokenApproval – interface with nft_approve methods. NonFungibleToken provides methods for it. - NonFungibleTokenEnumeration – interface for getting lists of tokens. NonFungibleToken provides methods for it. - NonFungibleTokenMetadata – return metadata for the token in NEP-177, up to contract to implement.

Token

In this implementation, the Token struct takes two extensions standards (metadata and approval) as optional fields, as they are frequently used in modern NFTs.

Functions

bytes_for_approved_account_id
hash_account_id
refund_approved_account_ids
refund_approved_account_ids_iter
refund_deposit

Type Definitions

TokenId

Note that token IDs for NFTs are strings on NEAR. It’s still fine to use autoincrementing numbers as unique IDs if desired, but they should be stringified. This is to make IDs more future-proof as chain-agnostic conventions and standards arise, and allows for more flexibility with considerations like bridging NFTs across chains, etc.