Intro

I'm gathering requirements for the non-fungible tokens (NFT) standard adoption on Stellar network. If the community decides that Stellar ecosystem needs that feature, I'll compose the formal proposal, post it on the stellar-dev mailing list, and bring it to the protocol discussion meeting. In case if the proposal is approved, we'll finalize and publish the standard, and it will become the foundation for new class of applications built on top of Stellar.

The functionality can be defined either on the protocol level (CAP) or the ecosystem level (SEP). CAP requires a core protocol update (including Stellar Core, Horizon, and SDKs), while SEP only describes the recommended interoperability practices for the applications.

What is NFT

A non-fungible token (NFT) is a special type of token which represents something unique. Each NFT token offers unique characteristics which make it different and digitally scarce. All assets issued on Stellar Network are fungible in nature.

Use cases:

Crypto-collectibles like CryptoKitties, unique in-game items.
Physical assets ownership (real estate, business commodities, artworks).
Intellectual property, certification, digital art authenticity.
Identity management (birth certificates, academic credentials, warranties, KYC records).
Event tickets and coupons.

Ethereum NFT tokens mostly follow ERC-721 standard. Other Ethereum-like platforms (EOS, Tron, Qtum) support the same standard.

Implementation on the ecosystem level

Currently, there are two approaches for the non-fungible tokens functionality emulation on Stellar network.

1. Standard Stellar assets as NFT tokens.

The issuer account creates NFTs by sending 0.0000001 of each asset with names like "A001", "A002", "A003", etc. to the distributor account (0.0000001 is the smallest possible non-divisible asset amount). Tokens can be traded on DEX or transferred between accounts like any other Stellar asset. The metadata for this token including friendly name, icon, and other properties can be defined in stellar.toml accordingly to SEP-0001 standard.

Pros:

A token behaves just like any other Stellar asset, automatically supported by all wallets.
Can be freely traded on DEX using standard functionality.

Cons:

No way to ensure token uniqueness without issuer account locking. However, issuer locking prevents new tokens creation, home_domain and authorization rules changes. Can be fully solved only by using a unique issuer account per token, but this solution complicates tokens discovery and overall usability.
Horizon represents a single token as a fractional amount. Therefore wallets by default will display an incorrect amount and trades price.
Poor token discovery. Clients don't know whether it's an NFT or a regular asset. Can be addressed by SEP-0001 modification or a new SEP.
Currently stellar.toml supports up to 300 asset meta descriptions due to the 100KB size limit. The problem is addressed by the Dynamic Assets Metadate SEP proposal.
Each token requires a trustline, so if someone owns, say, 50 collectible tokens, 26 XLM are frozen on the balance (1 XLM base reserve and 0.5 XLM per trustline).

2. Accounts as NFT tokens.

In order to issue a new token, the issuer application creates an account, sets master signer weight to 0, and then adds a signer - token owner. The account is unique and indivisible; the ownership can be transferred by changing signers, metadata can be attached to account data-fields. Token creation costs at least 1.5 XLM for the issuer (1 XLM base_reserve + 0.5 XLM for additional signer).

Pros:

No need to establish trustlines explicitly, no frozen reserve on the owner account balance.
Metadata may be hosted on the external server and addressed by the account public key.

Cons:

Can't be traded on DEX. Two parties can trade or swap such NFT tokens using a single transaction containing a few set_options and payment operations, but it won't be recorded as trade on the ledger.
Wallets, exchanges, and other clients won't treat the account as NFT token. However, the convention can be defined on a SEP level.
Users won't be able to see those tokens or check the ownership without the specialized application. Again, this can be addressed on the SEP level, yet at the moment only a few wallets fully support even SEP-0001 standard which was introduced more than a year ago. Therefore, we can't expect fast adoption by the majority of wallets.

Implementation on the protocol level

Pros:

Native support.
Trading on DEX from the box.
Correct balances and prices in Horizon responses.
Guaranteed support by major wallets and exchange interfaces.
Compatibility with existing SEP-0001 metadata.

Cons:

Standardization, development, SDK updates, and beta testing may take more than a year. Probably, NFT implementation on the SEP level is a more convenient way to get this functionality on the ledger ASAP.
Protocol update may also require source code changes for the majority of existing Stellar-enabled applications.

Native implementation on the Stellar protocol will require significant changes. From my point of view, converting an asset to the first-level ledger entry is the best way to introduce NFT support and deal with some other problems.

Currently, the asset itself does not have any properties. All settings are controlled on the issuing account level. Converting assets to separate objects allows specifying individual properties for each asset, even if they were issued by the same account. This approach also brings several other benefits:

Enforcing maximum available supply on the asset level. So far the anchor can freeze the supply only by locking the issuer account, which is not always convenient.
Arbitrary precision. Clearly, BTC-anchored tokens should have at least 7 decimals, while other tethered assets (like houses or, say, tennis balls), should be indivisible - with 0 digits precision.
Individual AUTH_REQUIRED/AUTH_REVOCABLE setting for each asset, which allows the same account to issue regulated and non-regulated assets.
Explicit asset creation may help to deal with invalid trustlines creation. Users often establish wrong trustlines using, for example, "eth" instead of "ETH".
It's easy to charge base reserve upon new asset creation, which effectively prevents potential asset flooding.

Vote and share your thoughts

You can vote for the feature on the Reddit sub. Please share your thoughts/suggestions in comments.

Thanks