Expand description
Non-fungible tokens as described in by the spec.
Re-exports§
pub use self::approval::NonFungibleTokenApproval;
pub use self::core::NonFungibleToken;
pub use self::core::NonFungibleTokenResolver;
pub use self::enumeration::NonFungibleTokenEnumeration;
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.
- events
- Standard for nep171 (Non-Fungible Token) events.
- metadata
- Metadata traits and implementation according to the NFT enumeration standard. This covers both the contract metadata and the individual token metadata.
Structs§
- 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 - refund_
approved_ account_ ids - refund_
approved_ account_ ids_ iter - refund_
deposit - Assumes that the precedecessor will be refunded
- refund_
deposit_ to_ account
Type Aliases§
- 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.