Description

In an effort to provide a unifying experience for developers to access runtime functionality for non-fungible tokens, APIs compliant to the PSP34 standard will be provided, as well as a set of extra functions (see Management). The interface as defined by this specification will be accessible for smart contracts via:

use pop_api::nonfungibles::<function>;

Note that the lack of version equals latest. As an example, the user could explicitly specify the version as:

use pop_api::v0::nonfungibles::<function>;

The introduced changes includes changes made to the forked pallet-nfts following what has been discussed in the internal spec. Adding and making changes to two new pallets:

• pallets/nfts: Changes made to the forked version to add new storage items to optimize the performance for the contract functionalities
• pallets/api/nonfungibles: Built on top of the pallet-nfts to expose neccessary functions for the contract API implementation.

API Development Tracking

• Contract size before: N/A
• Contract size after: N/A

• Does it follow any contract standard?

  • Name of the standard: PSP34

  • Link to reference: https://github.com/inkdevhub/standards/blob/master/PSPs/psp-34.md

• Does it require a new pallet implementation?

  • Name of the pallet: pallet-api/nonfungibles

• Does it require forking any upstream dependencies?

  • Name of the pallet: pallet-nfts
  • Link to reference: https://docs.rs/pallet-nfts/latest/pallet_nfts/
  • Reason why forking the pallet: The upstream pallet-nfts module is primarily intended for integration as a runtime pallet, which introduces inefficiencies when used within the context of smart contracts. To create a high-performance pop-api/nonfungibles library that adheres to the PSP34 standard, the optimizations and changes are required.
    • PSP34 interface compatibility: The pallet-nfts interface is not directly aligned with the PSP34 standard.
    • The storage structure in pallet-nfts is optimized for runtime operations, which may involve redundant read/write operations when accessed via contracts.

• Does it require changes made to pop-drink crate?

Related Issues & Pull Requests

• Specification

Runtime

• Runtime configuration: feat: add pallet-api/nonfungibles to runtime devnet #389
• Chain extension configuration: feat: add pallet-api/nonfungibles to runtime devnet #389
• Runtime testing: feat: add pallet-api/nonfungibles to runtime devnet #389

Pallet

• Pallet implementation: feat(nonfungibles): add pallet-api/nonfungibles #388
• Pallet documentation:
• Pallet testing: feat(nonfungibles): add pallet-api/nonfungibles #388
• Forked pallet implementation (optional): feat(pallet-nfts): optimization #387

Contract

• Contract API implementation: feat(devnet): pop-api methods for non-fungible use case #336
• Contract API integration test: chore: non-fungible use case integration test #334
• Contract API documentation:
• Contract standard trait and error: feat(api): PSP34 trait & errors with function selector #340
• Contract example (optional): chore: psp34 example contract  #333
• Update Pop API documentation:

Drink (optional)

• New pop-drink API:
• Contract example pop-drink test: chore: psp34 example contract  #333