sui
sui copied to clipboard
MystenLabs
[RFC] NFT standard philosophy, requirements, and some implementation …
…ideas
Philosophy and requirements are in README.md, the implementation ideas are in sources.
On today's roundtable, we will present an alternative approach to royalty enforcement which we call strong enforcement and it has whitelisting at its core.
To take a strong stance and support creators, we deem it necessary to implement a logical transfer of ownership for NFTs. In Sui terms - an NFT only has the key ability. Here we are presented with a crucial dichotomy: (i) an NFT wrapper type analogical of the Coin object or (ii) a collection’s own type.
We are strongly opposed to the latter because it breaks composability. Packages cannot access the functions which facilitate the transfers, therefore they would have to work around them via some intermediary state. Whenever possible, we don’t want to rely on the implementation of the client (with batched txs) to guarantee an atomic transfer.
The proposed NFT wrapper contains a metadata property (generic of a collection type) and a property with the address of the owner which we shall refer to as the logical owner for the rest of this document to disambiguate it from the owner of the Sui object.
We create means for whitelisting trading contracts. Only whitelisted contracts can perform NFT transfers between two addresses. There is a shared object which can be controlled by creators or the creators can delegate the maintenance of that object to some emerged DAO or some organization akin to an HTTPs certificate authority. The advantage of whitelists is that these schemas are all enabled and don't have to be decided from day 1.
The logical transfer of ownership in the NFT wrapper contract is facilitated by the following public functions:
transfer<C>(whitelist: &Whitelist<C>, source: &UID, nft: Nft<C>, target: address)
- Will assert that the &UID is contained (as ID) in the whitelist. Therefore, one could whitelist an orderbook. Interesting whitelists to explore further are package IDs to avoid generic via witness patterns.
- Creators can also whitelist contracts that facilitate p2p transfers via some off-chain validation. They act as an oracle.
transfer_to_object<C, T>(nft: Nft<C>, target: &mut T)
- We allow transfer to an arbitrary object for an NFT. It does not change the logical owner.
transfer_to_owner<C>(nft: Nft<C>)
- Transfers the NFT to its logical owner. Can be used for example to claw back the NFT from a shared object.
The concept of Safe was introduced in previous conversations. To quickly recapitulate, its purpose is to enable listing in multiple marketplaces, borrowing, and royalty enforcement. A user can create a TransferCap object and give it to e.g. an auction house. Such a trading contract can then use the TransferCap to tell Safe to transfer ownership of the NFT to the buyer.
The funds paid for the NFT are wrapped in an object defined by the standard. To unwrap these funds, one must validate the call with a witness pattern. The witness used to unwrap these funds is declared in the specific collection contract, e.g. foo.move for the purposes of this discussion. The wrapped funds are transferred as children objects to a shared object declared by foo.move: RoyaltyCollector. Therefore, if an auction wants to perform a trade, it must accept the collector in the entry arguments. (Is there a possibility to deduplicate responsibility and have the whitelist serve as the collector?)
To be more concrete, the Safe contract exposes the following public function:
trade_nft<C, R>(whitelist: &Whitelist<C>, source: &UID, cap: TransferCap, buyer: address, royalty_collector: &mut R)
The collector remembers the last payment, and therefore Safe can check that some royalty has been transferred. This in conjunction with the whitelisting concept guarantees that marketplaces remain honest.
There’s an entry function in the foo.move contract which facilitates the royalty collection. We design it this way to enable custom royalty enforcement while most of the logic resides in the standard’s contracts and is therefore composable.
The RoyaltyCollector must be defined in the same module as the collection logic due to constraints on accessing child objects imposed by Sui. The wrapped coins are unwrapped, deducted royalties, and the rest is sent to the stated beneficiaries. The beneficiaries here are the NFT seller and optionally also e.g. wallets if a commission logic is implemented by the auction contract.
…ideas
Philosophy and requirements are in README.md, the implementation ideas are in
sources.
Should we come up with the simplest NFT standard first? Because there are a variety of product development requirements in the Sui network, everyone needs a standard to develop. And now there is no perfect standard, can we come up with the simplest and backward compatible standard first, so that the developer community can use it first. This standard can be changed at will, at least until the Sui mainnet is launched.
As for the launch of the Sui network, this NFT standard should not be achieved overnight. It needs to face various development needs in the future and define a new NFT standard with forward compatibility.
The object itself is very good as an NFT abstraction.
Of course, the NFT standard will speed up the development of the Sui Ecosystem.
But too specific NFT standard lack flexibility, which will limit the development of Sui Ecosystem.
If the standard is not good, it will block NFT creativity.
aptos-token is a negative example.
I think Sui should notice that NFT standards exist, but not the only option. Standard-NFT and Custom-NFT (origin object) are equally important for Sui, and appropriately encourage the community to get creative on Custom-NFT.
Announcing the existence of Custom-NFT is not only to reserve corresponding interfaces for applications such as NFT wallets and trading markets, but also to protect the possible ideas of NFT.
Because once the NFT wallet and trading market do not support Custom-NFT, there will be no entry and trading market for Custom-NFT, and even the best Custom-NFT ideas will be stifled in the bud.
Erc721 is the application first, then the community promotes, and finally becomes the NFT standard, which is bottom-up.
Best wishes to Sui network.
