The Polkadot ecosystem is known for the diversity of solutions and approaches. Its very structure provokes the development of specialized decentralized solutions. But this also leads to fragmentation of implementations and APIs, duplication of ideas, ultimately causing the dApp developers to choose other ecosystems (primarily EVM-focused ones) over ours. Especially, it is true for NFTs in Polkadot.
The NFTs exist in our ecosystem, though they lack a unified API, and, overall, we don’t have a consensus on what “Polkadot NFTs” are, which makes our ecosystem less attractive for dApp developers than EVM platforms that have ERC-721 (even with its narrow focus).
Our ecosystem seems overwhelmingly diverse from the outside perspective (even if concentrating on NFTs only), so an average dApp developer will likely be feeling lost and will be compelled to choose another platform just to have a more unified view on the concept to reason about, even if it means sacrificing the possibility of building something powerful.
In practice, it would mean that a dApp developer will likely choose a full EVM ecosystem where no Substrate trace is visible.
The complexity itself may be a factor that causes a newbie developer to bail out of our ecosystem. At the same time, more complex foundational tools and standards provide more space for innovation for determined developers. But even the most determined ones may be discouraged by the diversity of interfaces and unpredictability of their future development.
It may appear that the solution is to declare a single “true” NFT pallet. We can not do that, however, since:
- It would be rather limiting due to the very nature of the unique objects since they could represent things of various kinds and, as such, require different associated operations.
- Many existing unique objects can be viewed as NFTs, e.g., fungible asset classes (i.e., any existing currency). Each class has an owner, maybe some manager accounts, and metadata like currency symbol and decimals. They can be naturally viewed as NFTs so that they would participate in an NFT logic like shared ownership (fractionalization).
Having one “true” NFT pallet that would cover all the possible NFT use cases and encompass the existing unique objects, we would likely end up with a large unmaintainable beast with a lot of interconnected parts.
To achieve a uniform NFT API without limiting the scope of its applicability and without creating a monster pallet, we need something similar to XCM, i.e., a language to describe the intentions of what we would like to do with an object.
The NFTMozaic announces an RFC draft of Unique Assets Standards for Polkadot.
They propose a common definition for crucial aspects of NFTs for the entire ecosystem:
- The common way of identifying the unique assets, see the Identification standard
- Since the unique assets have associated data, it must be inspectable by a client. See the Inspection standard.
- A chain may allow modification of the data of unique assets. The modification operations are subject to authorization and may be rejected by the given chain according to its internal rules. See the Modification standard
The proposed standards introduce the Unique Assets Virtual Machine. Its instruction set forms a granular unified API for parachain clients to interact with NFTs. This API could serve as a facade for any existing and future NFT solutions in the ecosystem.
Also, the instruction set is designed to be extendable and capable of altering the behavior of the existing instructions, with the possibility for a client to query the VM capabilities, so that a client connected to any parachain could decide if the parachain’s UAVM is good to go.
Essentially, UAVM and the accompanying standards are an attempt to separate the NFT interface from its implementation while also making it as granular and as extendable as possible to ensure minimal restrictive impact on the design of NFT use cases and future ecosystem-wide solutions based on such an interface. The “NFT language” (i.e., UAVM instruction set) should be the least restrictive yet powerful unification that will allow dApp developers to reason about unique objects in the whole ecosystem at once. At the same time, it should be an easy-to-maintain abstraction for chain runtime builders.
The problem at hand is complex, and addressing it effectively will benefit from diverse perspectives within the community. We will be happy to take into account your suggestions and overall feedback!