0014 XLS-14d: (DEPRECATED) Non fungible tokens (indivisible NFT's) on the XRPL

[WietseWind]

DEPRECATION NOTICE

This proposal is DEPRECATED and should not be used. It served as a proof of concept. With XLS 20 being developed as we speak it is a bad practice (imo) to use XLS 14.

NFTs

A non-fungible token (NFT) is a special type of cryptographic token which represents something unique; non-fungible tokens are thus not mutually interchangeable. This is in contrast to eg. the native asset on the XRPL, XRP, where XRP can be sent and received without being uniquely (per token) identified.

Where normal tokens and the native asset XRP can be divided (eg. receive 1 XRP, send 0.5 XRP), NFT's can only be used as one whole, unique token: they are indivisible.

Applications

Non-fungible tokens are used to create verifiable digital scarcity, as well as digital ownership, and the possibility of asset interoperability across multiple platforms. NFTs are used in several specific applications that require unique digital items like crypto art, digital collectibles, and online gaming.

Issuing tokens on the XRP Ledger

The XRPL supports issuing tokens (formerly (?) called "IOU's") that can be issued, sent, transacted to other XPRL accounts, etc.) as can be read in the XRPL Docs.

Note on issued tokens on the XRPL

One big difference compared to most other blockchain projects (like ETH, where NFT's are being actively issued, purchased, sold and transferred) is that the XRPL requires users to "opt in" to receive a specific token from a specific issuer, by explicitly signing a TrustSet transaction listing the issuer (account) and token code to trust. A user is only able to receive a specific token from a specific issuer after doing this.

Issuing tokens on the XRPL

A simple issue procedure of a token on the XRP Ledger:

1. Issuing account signs & submits an AccountSet transaction, setting flag 8: "Default Rippling". This is required for future Trust Lines set up by users, to allow them to send the token to each other.
2. Receiving Hot Wallet signs & submits an TrustSet transaction, trusting the token code to be issued by the Issuing account (this process should be repeated by all future recipients of this token)
3. Issuing account signs & submits a Payment transaction to issue X amount of the token code to the Receiving Hot Wallet
4. Optionally, the Issuer account 'Black Holes' the account, so no more tokens can be issued. To do this, the Issuing account:
   • Sets a regular key SetRegularKey to an account that can't be accessed by anyone, eg. rrrrrrrrrrrrrrrrrrrrBZbvji
   • Sets flag 4 using an AccountSet to disable the native key of the keypair to that account

The procedure outlined above works & is actively being used, but results in fungible tokens: they can be send partially, and any value of the issued cannot be uniquely identified.

Issuing NFTs the XRPL

The XRP Ledger has an issued token precision of 15 significant figures. The smallest amount of an issued token the XRPL can handle is 1000000000000000e-96. The decimal value of this scientific notation is:
0.000000000000000000000000000000000000000000000000000000000000000000000000000000001
0.{80 zeroes}1

This is a quite unusual amount of decimal positions for real life use cases. There is no likely use case that requires that amount of decimal places to ever be used, as there will always be something closer to the decimal sign. This results in the last digits being sliced off anyway (because of the XRPL supported 15 significant figures). Even some value of a BTC IOU (8 decimal places) + Transfer Fee + rounding doesn't even come close to using anything close to the available decimal places.

Proposal

Let's assign the last (say) 11 figures to client side / user interface 'NFT behaviour':

• The smallest possible amount on the XRPL:
  0.000000000000000000000000000000000000000000000000000000000000000000000000000000001
• Not NFT, as the last possible 11 figures aren't used:
  0.0000000000000000000000000000000000000000000000000000000000000000000001
• Is NFT (smallest possible amount, as (at least one of) the last possible 11 figures are being used):
  0.0000000000000000000000000000000000000000000000000000000000000000000000|00000000001

As you can't divide values it even further (they are already behind the decimal separator, and will be turned into the scientific notation when querying the XRPL), if only one (1) token value is issued, only one (1) token value can be sent.

So: if the value of issued currency is in the range of 1000000000000000e-85 - 1000000000000000e-96, clients should handle (represent, mostly a user interface affair) the amount as NFT.

This requires no amendment on the XRPL side, as all of this is possible today.

Issuer (issuing account) requirements

• No Transfer Fee must be configured
• No TickSize must be configured
• The Domain value (AccountSet) must be set, and resolve to a (to be discussed separately) https:// document providing token information. This can be discussed separately from this proposal, as existing issued tokens would benefit from a standard like that as well.
• Use 0x02 prefix for HEX currency (token) code. The remaining HEX currency (token) code can be used to identify the unique asset (UTF8 to HEX). The HEX currency (token) code should resolve to object information using the Domain value + a appended value (to be determined, eg. a .well-known setup / extension of the XRPL TOML / EIP-1155, ... (needs another proposal)

Issuer (issuing account) best practices

• Only issue one (1000000000000000e-96) of each token, create unique tokens for unique objects
• Set an EmailHash value (AccountSet). Possibly use eg. Gravatar to list your email address and attach a logo, so explorers like Bithomp show a logo
• Black hole the issuing account when done issuing NFTs: this way it's clear that the issuer can't even create more of the same NFT token

Implementation

This sample implementation in Javascript can:

• Detect if a value (eg. Trust Line balance, transaction amount, ...) returned by the XRPL is NFT-like
• Convert the value to NFT representation
• Convert an entered amount of NFT to scientific notation to be used in eg. a Payment transaction

xrplValueToNft(4.65661287307739E-10)       // not NFT: false
xrplValueToNft(12.123)                     // not NFT: false
xrplValueToNft(0.000000000000000000000001) // not NFT: false
xrplValueToNft(0.0000000000000000000000000000000000000000000000000000000000000000000001) not NFT: false

xrplValueToNft(1000000000000000e-96)       // is NFT: 1
xrplValueToNft(1e-81)                      // is NFT: 1
xrplValueToNft(10e-82)                     // is NFT: 1
xrplValueToNft(3100000000000000e-95)       // is NFT: 31
xrplValueToNft(1000000000000000e-94)       // is NFT: 100

xrplValueToNft(0.000000000000000000000000000000000000000000000000000000000000000000000000000000001)   // is NFT: 1
xrplValueToNft(0.000000000000000000000000000000000000000000000000000000000000000000000000000000031)   // is NFT: 31
xrplValueToNft(0.0000000000000000000000000000000000000000000000000000000000000000000000000000001)     // is NFT: 100

Vice versa, when composing a transaction, amounts (possibly user input) should be converted to NFT representation:

nftValuetoXrpl(31)     // 3100000000000000e-95'
// Equals: 0.000000000000000000000000000000000000000000000000000000000000000000000000000000031

Note on amounts of tokens issued (good / bad practice)

It is considered a practice to issue too many of the same NFT-like tokens (amounts). One can argue that issuing a large amount of tokens as per this proposal, the issued token can no longer be considered a Non Fungible Token.

If a token represents a real life object, eg. a painting, and there are three unique paintings, then three unique tokens will be issued (presumably using HEX currency codes representing the three unique paintings). All unique issued tokens will have an issued amount of 1000000000000000e-96 (NFT-like representation: 1).

Only the account that has a Trust Line to the issuer and for a specific token setup, and owns the indivisible value of 1000000000000000e-96 owns the NFT.

Impact (user interface, logic, code)

Amounts fetched from the XRPL (Trust Line balance, Payment value, etc.) should be checked if an amount is NFT-like:

1. The amount should be represented (in the user interface) as the NFT value (3100000000000000e-95 is represented as 31).
2. When the user enters an amount (eg. sending a NFT-like token) the amount can not contain decimal places
3. After the user entered an amount (eg. for a Payment transaction) the user input should be converted to NFT-like scientific notation
4. The application should check if the issuing account meets the NFT issuer requirements (see: Issuer (issuing account) requirements above)
5. The application should check if the obligation for the specific NFT token by the issuer doesn't exceed the max. NFT value of 1000000000000000e-85
6. The client must check rippling settings on the (if operating from that context) user transacting account to verify if settings are safe and sound, to prevent one stealing the real NFT by "rippling" a counterfeit one.

This issue contains the planned changelog for adding support for XLS-14d to XUMM Wallet.

Advantages

1. No amendment required
2. Relatively easy to implement in wallets / client side software as no new native on ledger features have to be supported
3. Detecting & parsing NFT-like values is easy in any programming language

Potential disadvantages:

• 5 XRP reserve per NFT
• A lot of client side / lib. responsibilities regarding value parsing and representation, correct rippling settings, etc.
• Due to rounding of book offers, XLS 14d issued tokens will NOT work on the DEX: offers will not be matched. Only simple Payment transactions will work.

Sample (issuing, sending)

Here's a sample issue + NFT sending sequence containing XPRL JSON template transactions.

[WietseWind]

@JoelKatz: I know (from @nbougalis) that the two (?) of you have some ideas on NFTs as well. Love to read your proposal & hear how you feel about this proposal.

[TheMainlander]

Most interesting, good onya @WietseWind. Buidl-on. 👍

[KRay2375]

lost me along time ago,

[raajonb]

The decimal issue is similar to what we face with the Fan Tokens we are launching. They are zero decimal, indivisible and it presents unique problems. Much easier workarounds for fungible tokens.

There are so many bad practices with NFTs right now. I am interested to see how they will be displayed. The thing that is really lacking on OpenSea Marketplace, CB Wallet App etc are strong interfaces for NFTs. They should display key info like total #. There is so little emphasis on rarity/ serial #s with many ETH NFT platforms. Would love to see this market place and UI geared towards collectors who want to see NFTs displayed beautifully and the total # of NFTS minted displayed very prominently. This will help attract collectors, investors at scale while dissuading users from overminting. The blackhole is a must.

We have lots of artists interested in redeemable tokens for physical products, rare physical collectables and irl experiences that would want to test in the near future as well.

[WietseWind]

I agree, if we at some point all decide / settle on a standard, I think normalisation and more standards are required. We can use the Domain field (AccountSet) for a domain where eg. a '.well-known' file must be present with more details for the issued tokens per issuer.

[RareData]

I believe we should try to use existing standards, regarding metadata format and JSON schema. I suggest we stay away from .well-known and go with EIP-1155 inspired URIs.

[RareData]

My proposal below would still permit .well-known though, but it would need to be included in the domain property as a path "cdn.example.com/.well-known".

[WietseWind]

That looks great @RareData! That makes a lot of sense. H#ll, it would make sense to propose that separately from this proposal, as existing issued tokens benefit from adding this as well. If you feel like turning that into eg. XLS-15d that'd be awesome.

[raajonb]

@WietseWind Cross platform standards will be very important. Let us know if you want to chat about the Metadata / Delivery Standards for music formats. This relates directly to NFTs in our opinion. In music, DDEX in particular sets standards allowing music releases to be distributed to any platform in single format, There are a ton of fields, referencing music files, IRSC & UPC Codes etc.

With NFTs, the issuer should be discouraged from creating the same NFTs on various platforms/chains.

Maybe the initial issuer designates a supply cap (cross platform) from the outset and violaters lose credibility. It might be commonplace for NFTs to be issued on multiple chains that are popular with users before they are able to be traded between platforms.

[yyolk]

I like extending the form of token creation on the XRPL in a protocol that you lay out above.

Conceptual linking the amount or unit of account of the token with the literal unit of account of the token on the XRPL is cohesive, it is precious and no longer divisible.

The suggestions around the issuer account has me thinking.

[yyolk]

I've gone through your JSON @WietseWind and I made my first NFT on XRP …titled, "Y̴O̴L̴K̴"
I just can't sign for the issuance, I'm waiting for it to recognize it in the next update for my wallet 😎

This weekend I'm hoping to actually issue it though, by signing directly along with doing this in the Testnet

I like the option to use unicode in the token name. I like this can be used for a piece title, and is opaque unless you're on a viewer that does attempt a HEX2Unicode.

[RareData]

I find the current proposal good, but lacking important details about what metadata URI format and metadata JSON schema to use. This should be standardized as well. I suggest we take inspiration from EIP-1155, specifically the metadata URI and metadata URI JSON schema. Other blockchain and NFT developers are familiar with this standard and I see value in adhering to existing standards to the greatest extent possible.

An XRP Ledger variant of EIP-1155 would allow for ID substitution by clients as long as:

1. The string format of the substituted hexadecimal ID MUST be uppercase alphanumeric: [0-9A-F] with no 0x prefix.
2. The string format of the substituted hexadecimal ID MUST be leading zero padded to 40 hex characters length if necessary.

An example URI https://cdn.example.com/{id}.json formed from the 40 character hexadecimal currency code would then look like: https://cdn.example.com/0000000000000000000000000004CCE0.json, if the client is referring to token ID 314592/0x4CCE0.

I also propose that the NFT issuing account domain MUST be set with an AccountSet transaction. Using the same example as above, the issuing account of the NFT 0x4CCE0 would then have the domain cdn.example.com set. This allows on-ledger discovery of both domains and NFT IDs. The XRP Ledger domain property allows for up to 256 bytes to be stored, which should be more than enough.

Regarding the metadata JSON schema, I suggest we use EIP-1155 as is, properties like properties.decimals may be unused.

[RareData]

I suggest clients MUST default to https:// when fetching the resource, but respect overrides if the protocol is included in the domain property itself, such as a domain set to "ipfs://{content-id}" instead of "cdn.example.com". The domain property MAY also include a path such as "cdn.example.com/directory".

[WietseWind]

That makes a lot of sense. H#ll, it would make sense to propose that separately from this proposal, as existing issued tokens benefit from adding this as well. If you feel like turning that into eg. XLS-15d that'd be awesome.

I updated the proposal to include this note.

P.S. One approach would be to propose adding EIP-1155 characteristics / schema to the existing XRPL TOML format, where the currencies definition is pretty basic

[mDuo13]

Agreed. At the very least an EIP-1155 "metadata URL" (including {id} substitution) field in the [[CURRENCIES]] field would make a lot of sense to me, and that URL can resolve to a JSON document matching the metadata schema defined in EIP-1155.

Though, if you're issuing a very large number of unique tokens, listing them all exhaustively in the toml file may not be feasible. I'm open to ideas of how to handle that.

[RambeauTeasbox]

I've been working on the idea of issuing NFTs on XRPL myself and posted a scheme I tried on the testnet here: https://www.xrpchat.com/topic/36795-nfts-on-xrpl-how/?do=findComment&comment=898858

I do have some confusion over the appropriate amount to issue (precision vs. minimum value), so if issuing 1e-15 is incorrect (i.e., must issue 1000000000000000e-96 for a unique token), I will have to amend my NFT implementation scheme.

Otherwise, I chose to point to the NFT object using the Memo field in the issuing Payment transaction instead using the AccountSet Domain field. While the Memo field has the advantage of allowing for more information storage, I can see the advantage of using the Domain field: lookup of the issuing account's metadata vs. lookup of the issuing Payment transaction.

Looking forward to being a part of this discussion -- and glad to know that others are working on the same problem!

[WietseWind]

Wow! That's super cool to hear, good thinking ;) - if I can say so myself, haha. 1e-15 will not cut it indeed.

Using the Account Domain field is indeed much simpler to look up, and this combined with a TOML / .well-known / EIP-1155-like proposal (@RareData) I think we covered the same things. Thanks for your involvement and ideas!

[RambeauTeasbox]

Thanks -- I've repeated the experiment on testnet with the issuance amount correction and suggestions from this proposal. (https://www.xrpchat.com/topic/36795-nfts-on-xrpl-how/?do=findComment&comment=899719)

[ivanwoodson]

After reviewing how the data is presented it might be best to convert to a DDEX related platform.

[SASchofield]

Would using PayString IDs suffice as an identifier for an NFT?
That is to say instead of linking an ID solely to an issuing address, utilise the domain naming convention to ref an NFT?

This would likely look like Issuer = wietsewind$xumm.app, NFT = wietsewind+nft$xumm.app

[Wietse-Livingroom]

I gave it some thought and I am not convinced PayString helps here: I am afraid it'll even add complexity / possibility of errors / data mismatch:

1. A PayString refers to an on ledger account address, not to a specific issued token. One account can issue multiple of them.
2. What if the PayString references an NFT and the underlying account / token isn't configured properly?
3. What if the PayString doesn't reference an NFT and the underlying account / token is configured as NFT?
4. On top of that, it adds another lookup layer, domain+HTTPS » Ledger » Domain (Account) » HTTPS Token definition file. While there already has to be a (more than one, hopefully) marketplace listing multiple items by multiple issuers, where an index/mapping to on ledger accounts + token codes should be available, skipping the PayString.

A similar setup where the owner of a platform/account that issues many tokens hosts a PayString (or -like) service using the same format may make some sense (eg. tokencode$issuer.domain » resolves to issuing account, where a lookup for the tokencode can be done), but I feel this belongs in another standard proposal. A bundle (XLS-14 + XLS.. + XLS..) should then take care of:

• The On Ledger / Wallet NFT standard (this one)
• A standard for Token information (as mentioned by @RareData) as this is not NFT specific
• A standard for pointing towards issuers + specific tokens as this is also not NFT specific

[yyolk]

I have some thoughts here from almost a year ago before it was PayString, I echo the sentiment of "piece title" / ID correlating to the token (and in my jumbled thesis linked above, where a piece is custodian'd through; like a brick gallery)

PayString is useful for different scenarios where DNS is available.

I find flexibility in domain names, but for this case I think what could be leveraged here is determining who created the piece / what gallery created it / who owns it (dns redirect?) by looking at the xrpl-livenet wallet directly, from what is returned by PayString. It could also indicate if that piece is still for sale by if it returns a wallet or not, since we're leveraging DNS , we are flexible in how that DNS is propagated to your wallet, and could use private TLDs like .eth, .crypto

DNS is useful in many ways.

[intelliot]

It is necessary to 'lock up' one owner reserve (currently 5 XRP) for each NFT held, I believe. Any concern about that?

I think JoelKatz's proposal creates new ledger object types and allows up to 32 unique NFTs to be held while charging only 1 reserve. (A larger change that requires an amendment, of course.)

There is a potential security concern around 'counterfeit' NFTs: if someone can be 'tricked' into trusting an issuer for a particular NFT currency code, then 'rippling' could allow someone to send a counterfeit NFT and receive the real one. This is due to:

In a sense, rippling is like a passive, two-way currency exchange order with no limit and a 1:1 exchange rate for two currencies with the same currency code but different issuers.

This could likely be solved by having a 'best practice' of client software checking for any existing conflicting trustlines before creating a new one.

[WietseWind]

I'm looking forward to reading more about the implementation ideas from @JoelKatz! I believe there's an advantage to being able to sell/trade/offer using the existing DEX methods, I'm especially curious if that's part of it :)

I believe the 5 XRP reserve is a small price to lock up (not even pay) for holding an NFT.

The rippling part is a really good consideration, and must definitely be part of client setup and checks. Will update the proposal 👌

[yxxyun]

I'm looking forward to reading more about NFT, AMM from JoelKatz too.

[RambeauTeasbox]

How could we include royalty payments for NFTs? For example, the artist or issuer may want to receive a percentage of every secondary sale or use, automatically sent to an account or set of accounts, perhaps in a currency of choice.

There are a couple different ways I could imagine this being implemented:

1. If there is a native NFT ledger object in the future, exchange on the DEX could automatically send portions of a sale of an NFT to a set of accounts, using the DEX to send the royalty fees in a currency of choice.
2. The royalty fees sent to a set of accounts could be requested in NFT metadata or in a ledger field tied to the issuing account or issuing payment and implemented by wallets and platforms that allow for interaction with NFT-like objects.
3. The Transfer Fee or Trust Line Quality could somehow be leveraged to implement NFT royalty payments. I don't believe this is possible, but perhaps their applications could be modified in some way in future versions to do this, like if a Transfer Fee setting could act on the counterparty's payment currency?

[Wietse-Livingroom]

While I think this, like any other use case looking for a solution is interesting, I feel this belongs in another idea / proposal (or pre-proposal). I wrote this proposal to be entirely limited to the possibilities with today's (existing) XRPL features, so it can be implemented client side only. Without amendments. Any option here on layer one (on ledger) instead of layer two would require an amendment, and turn my proposal in something that isn't executable today.

Also, royalty / recurring payments aren't limited to NFT's: this use case can be looked at from a much broader perspective ;)

[Ponderjaunt]

Currently, the proposal suggests a 'disabled account transfer fee' flag.

Could an issuer establish a standby address, funded with a reserve as a 'minting cost' ( as well as an operational address creating a DEX accessible Path).

Enable setting the transfer fee to the operational address and then assigning a regular key to 'blackhole' the issuance (standby address) -- which is already included in the proposal.

Then, an added multi-sig weight, favoring the operational address more heavily than the standby address, ought to ensure that the issuer could not decrease the NFT scarcity overtime.

Thus, after minting, the issuer receives a dividend automatically, while losing control of the standby address due to the 'blackhole reg-key generation'.

The sender of the transfer is debited an extra percentage based on the transfer fee, while the recipient of the transfer is credited the intended amount. The difference is the transfer fee, which becomes the property of the issuing address, and is no longer tracked in the XRP Ledger. Transfer-fees

Setting a flag to disable XRP deposits to the issuance address and forcing all future transactions to pay a percentage of revenue through the operational address may be a solution. Shouldn't this ensure scarcity without depriving the issuer of future revenue?

The transfer fee does not apply when sending or receiving directly to and from the issuing account, but it does apply when transferring from an operational address to another user. Transfer-fees.

I may be inter-mixing the 'Operational' and 'Standard' accounts based on current ledger functionality. Or I may be misunderstanding the requirement for 'disabled transfer fee' entirely.

[Wietse-Livingroom]

The same that I just wrote to @RambeauTeasbox applies here, imo. These are good things to discuss and possibly implement, but in another proposal: I wrote this proposal to be entirely limited to the possibilities with today's (existing) XRPL features, so it can be implemented client side only.

Implementing dividends, etc. opens a can of worms when added: what if one doesn't pay the royalty / dividend (in time)? What if a client (eg. wallet) doesn't have a way to interact with the user that has to pay it in time? Etc. This needs a lot of discussion & decisions imo.

"Setting a flag to disable XRP deposits"
That flag is just a flag, and doesn't actively block the transaction on ledger: it's a client warning only.

"Or I may be misunderstanding the requirement for 'disabled transfer fee' entirely."
The TransferFee takes a percentage of the delivered value when sending a transfer of a non XRP token on the XRPL. If we use the smallest possible amount, rounding is risky (and won't even work, it can't be rounded as the value is indivisible).

[RambeauTeasbox]

I agree -- an easy way to do royalty/recurring payments or conditional transactions without escrow would be a great addition. I also apologize for adding clutter to this proposal's discussion.

[WietseWind]

No need to apologise at all, it's definitely related to this discussion, and if you decide to open another standard proposal / pre-standard discussion for it, please reference this discussion as well.

[mDuo13]

We should define and set aside a value for the first 8 bits of a hex currency code for NFTs. The existing hex values are:

• 0x00: general purpose tokens/issued currencies. (format)
• 0x01: (legacy) demurraging/interest-bearing currency. (format)

So how about 0x02 for NFTs? Individual tokens may have varying needs in further specifying the details of their hex codes, and depending on the amount of variety and adoption, multiple prefixes might be needed in the future, but I think it makes sense to use 0x02 for the first gen of NFTs.

[RambeauTeasbox]

I think it's a good idea to mark them. In my experiments, I've used a SHA-1 digest of an IPFS pointer associated with the NFT object. This fits perfectly in the 160-bit currency code space. If we'd want to encourage or require unique currency codes that are linked to the NFT objects, a few suggestions for possibilities:

• 0x02 + first 152 bits of SHA-1 digest (truncation of the last byte)
• 0x02 + 000000 + 128-bit md5 digest (leaves 24 bits open for other NFT-specific flags)
• 0x02 + first 152 bits of IPFS pointer or other unique identifier

[WietseWind]

Completely agree @mDuo13 - I'm updating the proposal.

[mDuo13]

Given the rapidly deteriorating status of both SHA-1 and MD5, I strongly suggest using something a little more modern even for cases like this where hash collisions are not inherently a security problem. At a minimum, a SHA2, SHA3, or SHAKE hash seems prudent.

The XRP Ledger already depends on SHA-512 and truncations thereof, so I think that's the most obvious choice here.

[intelliot]

I was about to chime in and recommend SHA-512, truncated to the length that we desire. 😀

[intelliot]

It would be cool to include 4 chars of ASCII so that the NFT currency code has a human-readable portion. This would make it easy for clients to show something recognizable without needing to do a lookup in an external database. Example:

• 0x02 + 32 bits (4 chars of ASCII) + first 120 bits of SHA-512 hash

[WietseWind]

I like this :)

[mDuo13]

Having the token name encoded would be nice; of course, the question of how many bits to use is a challenging one.

Incidentally, I toyed with ideas like, "the currency code should encode a URL that uniquely identifies the token and also links to an extended definition" but that's not realistic. Even if we assume the scheme is https:// and the domain is set in the issuer's account, 152 bits only gives us about 20 characters. That's not remotely enough for most URLs. Even something like .well-known/tokens/nft-cat-9234871 would require over 30 chars.

Of course, depending on the nature of the encoded token it may be rather difficult to uniquely describe the token in a compact set of characters. Like, you could represent a ChainFace in a few characters, but what code would you even put to represent some other kind of unique object? I think, realistically, you're going to have to refer to some outside definition to fully conceptualize the token.

[intelliot]

Agreed, the human-readable part would just be for convenience. You’d still need to look up the hash to get the NFT’s details. I imagine that the human-readable chars would just give you a general sense of what your various NFTs are (before you do an external lookup).

[mDuo13]

One approach that might be worth considering is: what if a token's currency code is conventionally allowed to contain a variable amount of UTF-8, starting after the type byte and terminated with a null (0x00) byte? Then any remaining bits of the currency code are free to use for things like hashes, counters, unique attributes, or whatever one wants to fit in them. Clients might need to sanitize the UTF-8 before displaying it but that provides a lot of flexibility in terms of token names that can be derived from the on-chain information.

For tokens where you need to know more about them, you can look them up by the full 160-bit ID in the issuer's the xrp-ledger.toml file, which can include stuff like URLs to EIP-1155-compliant metadata JSON files, or paths for rendering the item the token represents as a physical image or something. Later, some or all of the fields that are useful for describing the token could move to an on-chain token definition object if that becomes desirable.

[intelliot]

That's a cool idea. I'm concerned about sanitization, UI display (sizing) issues, and complexity.

4 chars is only enough for a (typically abbreviated) symbol, e.g.

• Erth
• Stem
• CrPk (CryptoPunk)

(To distinguish between editions and other NFTs that share the same code, clients could show some of the beginning/end the hash, e.g. Erth-e04c-78bb)

More text would allow for scams1te.com, as well as strings that don't fit nicely in UIs. It's certainly possible to do securely, but it's more complex. And of course, 8 bits would be used by the null byte, cutting into our already-limited space. I think that by the time you want more than a few letters, it's time to look up the actual metadata, perhaps from a trusted service provider (analogous to niftygateway.com), or from the issuer's web server.

[ftppro]

A few questions:

1. When do you think this proposal will be completed, and an example will be created?
2. Does this proposal have to be approved by any entity, before it is accepted by the community?
3. Does this proposal allow the Ripple API to list all NFT's, and their details (such as last date exchanged, last price, and owner's XRP address)?

Here are a few ideas for uses of XRP NFT's:

1. Songwriters can sell their publishing rights.
2. Coin collectors can sell the ownership of a coin (each coin has a unique ID assigned by the American Numismatic Association).
3. Website owners can sell ad space on their website.

The unique advantage of an NFT is that the purchaser can resell their ownership.

[WietseWind]

Answers:

1. An example being code samples, or an actual implementation? The first is already in my proposal, the second is being added to XUMM as we speak for beta release this month.
2. Nope, we consider it completed if parties/people implementing it agree on the state of the proposal. Amendments / additions can then always be added later, with a follow up proposal.
3. Yes, if Ripple would add that to their API. But that wouldn't even be necessary: the XPRL is public, one can just fetch all of them from a ledger.

[ftppro]

Thank you for your reply.

1. Using your code sample, can I use the Ripple API to actually create and trade an NFT on the testnet at this time, or do I need to wait for the beta release?
2. If the proposal is changed in the future, will it be downwardly compatible? Will the NFT's that I create today still be valid?
3. Does the Ripple API currently allow the ledger to be filtered to display just NFT's, and their details (last date exchanged, last price, and owner's XRP address)? Or do new features need to be added to the Ripple API before I can do that?

[WietseWind]

1. You can already do this today, as the proposal doesn't involve any XPRL changes. Samples included at the end of the proposal.
2. I can't say, as I don't know what will change.
3. No, it doesn't, you will have to get all transactions and filter yourself. I assume you mean a websocket connection to an XRPL node when you say Ripple API.

[ftppro]

Can this proposal include storing data that can be used by the Ripple Data API v2, to filter the ledger for all NFT's, or just one type of NFT (like CryptoPunk)?

Ripple Data API v2 includes the following methods that can accept query parameters to retrieve particular Transactions:

1. https://xrpl.org/data-api.html#get-transactions
   This method can filter transactions for a specific transaction result: https://xrpl.org/transaction-results.html
   Can the transaction result somehow be used to isolate one type of NFT?

2. https://xrpl.org/data-api.html#get-accounts
   This method can filter results to children of the specified parent account. Can that somehow be used to retrieve just one type of NFT?

Without filtering capability, how would one display a list of all NFT's (and a list of just one type of NFT) without storing the data off-chain?

To get all transactions in the ledger, and manually filter, does not seem feasible.

[mDuo13]

1. There's nothing in account_lines specific to NFTs but if you query an address as in this example you can see the list of tokens they've issued. So just query the issuer of a given type of NFTs.

2. account_lines doesn't look up transactions, just the balances of a given account. If you want transactions, use account_tx. If you want prices in the decentralized exchange, use book_offers. I imagine that the APIs for this stuff will improve over time as it gets more adoption. This proposal is barely a week old!

3. This list of public XRP Ledger servers has a column indicating which ones have full history.

[ftppro]

@mDuo13 Thank you for that information; it is extremely useful.
I think I will store the data for my NFT's off-chain (which is what CryptoKitties does).

[raajonb]

@ftppro this thread went way over my head technically but im still enjoying it. How is crypto kitties storing data off-chain in layman's terms?

[ftppro]

@raajonb CryptoKitties disclosed that they store some data in a MySql database, which is referenced by record id's that are stored on the blockchain.

There is nothing wrong with that, other than pissing off some blockchain fanatics who adamantly feel that everything must be 100% decentralized.

[raajonb]

Thank you for the info.

[ftppro]

You indicated that your proposal requires users to "opt in" to receive a specific token from a specific issuer, by explicitly signing a TrustSet transaction.

Will this requirement eliminate the ability to use Ripple to create and manage a project such as the Kings Of Leon album that was just released as an NFT:
https://www.rollingstone.com/pro/news/kings-of-leon-when-you-see-yourself-album-nft-crypto-1135192/

If someone paid for a music album as a Ripple NFT, will the recipient have to go through a process that may be difficult for a novice?

With Ethereum, you can create the NFT without any action from the recipient, and the NFT will immediately appear at etherscan.io. Of course, creating an NFT with Ethereum currently costs more than $20, which is why a Ripple solution would be preferable.

[ftppro]

So the NFT creator must post 20 XRP, and each recipient must post 5 XRP, right?
I don't think a band that wants to release 500 NFT copies of their album will accept the requirement that each recipient must post 5 XRP. Also, that requirement can be increased at any time.

xDAI seems to be a much better way to create and distribute NFT's. Please enlighten me otherwise.

[WietseWind]

Please read https://xrpl.org/reserves.html

This proposal doesn't focus on reserve structure, it does however on the use of existing XRPL capabilities in the context of NFT's. If there are reasons for parties XRPL characteristics are less suitable for their use case, that's another discussion. This discussion should, in my opinion, be about if and how we can instruct and use the XRPL with the capabilities available today to issue, send and receive NFT-like assets.

[ftppro]

Before I invest a lot of time to use xDai to create, distribute, and manage NFT's, I would like to know if there are any
use cases that XRP would be more suitable than xDai.

[Wietse-Livingroom]

Which is perfect, but doesn't belong in a technical standard proposal discussion.

[raajonb]

@WietseWind It is very simple to find certain assets and add them. I saw the interface initially and then again now that Casino Coin is added. Its harder to add when the asset is unsupported and you are a crypto novice like myself. I understand that my concerns do not necessarily represent limitations of the technology. I can see the technology being used, in the manner you are developing it, for a variety of purposes. I am going to keep digging in on this. Sorry to get off track.

[RichardAH]

Throwing this idea into the mix:
The NFT currency code includes a 4 byte unsigned integer which corresponds to the sequence number of a transaction created by the issuing account. That transaction would nominally be a 1 drop payment to a blackhole, containing a memo which contains all the details of the NFT. Thus the combination of the issuer address and this UINT32 stored in the currency code uniquely identifies a payload of data which represents the NFT.
160 bit currency code could be formatted like so
Byte 0: 0x02 -- NFT type
Byte 1 - 5: 0xFFFFFFFF -- sequence number of "NFT definition transaction"
Byte 5:20 <15 bytes of UTF-8 token name>

Edit:
As per further discussions with @WietseWind it might be better to point to a specific TXN by ledger and index number in that ledger like so
Byte 0: 0x02 -- NFT type
Byte 1 - 5: 0xFFFFFFFF -- sequence number of LEDGER of validated "NFT definition transaction"
Byte 5 - 7: 0xFFFF -- index within that ledger's canonical txn order
Byte 7 - 20: <13 bytes of UTF-8 token name>
However this requires some improvement to rippled/xrpld's RPC functions to actually allow a {ledger_seq, canonical_index} to be looked up. Afaik there is no existing way to look this up without parsing a full binary dump of the ledger.

Edit 2:
The above edit gave rise to XLS15d - Concise Transaction Identifier
Now the proposed currency code would look like this:
Byte 0: 0x02 -- NFT type
Byte 1 - 8: < 7 byte CTI uniquely identifying a validated txn containing memo with metadata about NFT>
Byte 8 - 20: <12 bytes of UTF-8 token name>

[mDuo13]

For what it's worth, you don't need to send a 1-drop payment to put a memo into a transaction. You can send an AccountSet with no settings. Heck, the Payment that issues the token could also include such info (but you wouldn't be able to know its index in the ledger's canonical tx order until later, so that approach wouldn't work. The sequence-based approach would work for this though).

Storing relevant information in transaction memos this way is an interesting approach, BTW. You can put a lot of data in a transaction and retrieve it from full-history servers, but—unlike putting all that data into the ledger's state tree—other servers don't need to store that information to keep up with the ledger. But you can only look those things up at full-history servers.

[RichardAH]

But you can only look those things up at full-history servers.

I think this is fine tbh. You probably ultimately need to pull the NFT audio/visual data off ipfs so a full history node lookup first is the least of the issue/burden here

[carlhua]

This is super exciting!

@Wietse-Livingroom do you have a plan to support fractional NFT with perhaps an extension to this proposal? I think fractional NFT would be of tremendous value in the near future. Also, we should consider DEX support of NFT as well. XRPL is uniquely positioned to succeed in the NFT ecosystem IMO and if we can have a standard/plan to support NFT on DEX, that would be great.

I also don't think blackhole steps needed as we inherently trust the NFT issuers already. But that is minor.

Finally, this is not mentioned here, but what if we encoded the NFT's configurations into the currency code vs memo? For example, can this NFT be further divided into fractional NFT?

[WietseWind]

If you want to support the fractional transfer of tokens... Just use issued currencies as is? Like in use for many years? All standards discussed right now, proposed in the future, etc. (eg. #34) can apply on issued tokens as used today (with decimal places) or as proposed in this thread (#30) without decimal places, indivisible.

I guess in this sense one should read the title of this proposal as "indivisible issued tokens on the XRPL, eg. for NFT's"

[RichardAH]

I've written a sample viewer based on my suggestion above https://richardah.github.io/xls14-resolver/
You can view an NFT balance for example on rcoinShpZ8MfUipcfbySaV7rPV82k1SMS

[Silkjaer]

I have spent some time getting acquainted with NFTs on Ethereum, and how they are used today mainly as a way to sell and trade “collectibles”, such as art.

While I fully support and appreciate the work being put into making a standard of how to use the existing XRPL features to support NFTs, here are some of my observations and why I believe it will not be competitive to other chains without amending the XRPL, e.g. with a new token model in addition to the existing trustline/IOU.

With current gas prices on Ethereum, it can easily cost 50+ USD to issue an NFT in an existing contract, and of course even more so to create a custom contract. With smart contracts for bidding/auctioning, submitting bids and accepting bids is also expensive.

The XRPL has a unique opportunity to tap into this market, with speed and low transaction costs, but it will require offering similar or alternative solutions to what people are already used to. Not “just” a workaround :)

Concern 1: To prove immutability, the issuing account will have to be blackholed. This leads to a 1-1 ratio between NFTs and Accounts. While DeletableAccounts was introduced to lower the amount of accounts stored on the ledger, introducing a practice of creating accounts that can’t be deleted to issue tokens, will have the opposite effect. Further, it works against the benefit of the XRPL being cheaper, as it will “burn” the base reserve but leaving it untouchable.

Concern 2: To receive a NFT, a trustline has to be established. This will have the costs of an owner reserve on the holding account, per NFT. Collectors would end up with many trustlines and a growing inaccessible balance.

Concern 3: Data persistence. While the NFTs issued in trustlines will remain, the transactions used to issue it will eventually be “history”, without guaranteed persistence. Separating token payload and token by using a pointer to a transaction pose a risk of loss of token payload. However much unlikely, and admitted a more theoretical than practical concern. It is a real concern however, depending on the value of the NFT (priceless digital art? A house?).

Concern 4: Lack of comparable features. Some of the value of the NFTs on Ethereum comes from things like “collections” (the smart contract), the on-chain bidding systems, royalties (on resale) …

I believe that it should be considered whether NFTs is a party that XRPL wishes to attend – is it here to stay or is it a trend? If the XRPL wishes to join, I think it’s beneficial to look at ways to amend the XRPL with functionality that can support NFTs (and could probably be broken down in smaller features to benefit other things too).

Wishful thinking:

• One account can issue multiple NFT trustlines, and each NFT trustline represents a “collection”.
• Within a NFT trustline, fractionality can be switched on/off.
• The NFT trustline can issue multiple tokens, but once issued, it remains immutable
• The token holds the payload (some set standard as discussed here)
• The token holds a hook executable that can be invoked on triggers such as token transfer or trade?
• Make NFT trustline tokens DEX tradable
• Using Hooks to run auctions?

Eventually I’d like to see support that doesn’t rely on “blackholing” to prove immutability, support some of the scalability from the ERCs, doesn’t end up in 1-1 ratio between accounts and NFTs, and doesn’t require 1 trustline per NFT.

Honestly, without amending the XRPL, the model already discussed could get traction for as long as the costs associated is low compared to other chains. But wouldn’t it be better to “go all in”, if NFTs are here to stay?

For comparison, in 9 months there has been issued more than 50000 NFTs on Rarible alone. Many in the latest months alone, despite the extreme costs associated.

[RichardAH]

Re: Hooks and NFTs.
I think NFTs will eventually mirror wrapped and unwrapped assets on other chains:
An unwrapped NFT is a trustline balance that can interact with the DEX, be sent and received by accounts and potentially participate in rippling (if I want to trade my A for your C but you only want a B, and someone else with a B wants an A we can complete a path).
A wrapped NFT lives inside HookState and is effectively an IOU from that Hook to you. This wrapped NFT can then be manipulated by the Hook for any purpose desired, such as auctions etc.

[hammertoe]

Concern 4: Lack of comparable features. Some of the value of the NFTs on Ethereum comes from things like “collections” (the smart contract), the on-chain bidding systems, royalties (on resale) …

I believe that it should be considered whether NFTs is a party that XRPL wishes to attend – is it here to stay or is it a trend? If the XRPL wishes to join, I think it’s beneficial to look at ways to amend the XRPL with functionality that can support NFTs (and could probably be broken down in smaller features to benefit other things too).

I think royalties/commission is something we have overlooked here. It is a quite unique thing that NFTs bring to, e.g. the art world. The fact that as the original artist I can get a programmed commission from each subsequent sale down the line is something that I think really appeals to artists. In the traditional art world, when an artist sells a piece, they get the initial sale price, but that it is. If they subsequently become famous and their art appreciates in value they see nothing of any future sales of that piece.

I don't think we have a way to replicate that in this proposal, and whilst we might chose that to be out of scope, I think it could be the difference between someone choosing to issue on the XRPL or not.

[RichardAH]

I don't think we have a way to replicate that in this proposal, and whilst we might chose that to be out of scope, I think it could be the difference between someone choosing to issue on the XRPL or not.

If default rippling is disabled and the NFT is issued by an account containing a royalty hook then transfers could be enacted via a standard way to send the nft back to the issuer with instructions to reissue it to another party

[intelliot]

It may be possible to implement royalties/commissions without an amendment by using the Authorized Trust Lines feature. The issuer can require payment of a royalty in order for a buyer to become authorized, and programmatically authorize the trust line when the payment is received. This would be off-ledger business logic. It's sufficient only if users trust issuers, which I'd argue is effectively the case with virtually all Ethereum-based NFTs anyway. (Trust could be reduced using Codius.)

[yxxyun]

How about treat NFT as a new type of account object with auction support, so no trustline needed, but can transfer to other account.

[yyolk]

I think it's possible to leverage mechanics available today to defer delivery of a proposed NFT if you're not using the built-in dex to set an offer.

An application could be written to programmatically take in payments and returns them based on final bid price.

A trust line also can enter your wallet into bidding and the artist / gallery /seller can prove it's them.

[darocha]

Thomas raised valid concerns. I'd like to share some of my views for NFTs on XRPL. I think NFTs are here to stay and will not go away for a long time, but developers will need a really good reason to move away from Ethereum to the XRPL. For mass adoption we'd need to remove all friction and make it as easy as possible for developers. XRPL should also fully support the standards ERC721 and ERC-1155 to maximise compatibility with existing systems. I dislike that a Trustline needs to be established to be able to send/receive a token.

…

On Wed, Mar 10, 2021 at 3:46 AM RichardAH ***@***.***> wrote: Re: Hooks and NFTs. I think NFTs will eventually mirror wrapped and unwrapped assets on other chains: An unwrapped NFT is a trustline balance that can interact with the DEX, be sent and received by accounts and potentially participate in rippling (if I want to trade my A for your C but you only want a B, and someone else with a B wants an A we can complete a path). A wrapped NFT lives inside HookState and is effectively an IOU from that Hook to you. This wrapped NFT can then be manipulated by the Hook for any purpose desired, such as auctions etc. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#30 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABT75EOTB6ZGSTRP4L5XMY3TC4WX3ANCNFSM4YHRDHIA> .

[nbougalis]

I dislike that a Trustline needs to be established to be able to
send/receive a token.

We all dislike that. After discussion with NikB today we concluded an amendment to the Check system should be proposed which allows you to effectively send a trustline balance, as a Check object, to another party who doesn't have the appropriate trustline to receive it, which they will automatically generate if and when they Cash it.
This would solve the issue I believe.

I don't think we actually need an amendment: I can send you a Check for any currency right now, even one you don't have a trust line for. To cash the check, you would need to first create the trustline first, and that is something we could change^†, but a change is not required; that means that a Check can be used and, as a bonus, it's usable not just by the issuer of an asset but by anyone. Also, a Check has cool features like an expiration date.

"But wait," you say. "People will have to use these fancy new checks, and getting people to use new things is hard." Yes, they'll have to use new functionality, absolutely. But there's no getting around that. Any changes to trustlines would be new too, and clients would have to adopt and use them, so why not just adopt and use checks instead, which are already coded and already active on the network.

As a sidenote, this higlights the fact that the XRPL already has a LOT of features that are underused (or even entirely unused) but which are flexible and powerful enough to be used as building blocks for other features. We, as developers, should be mindful of and take advantage of that.

---

^† Automatically creating the trust line would be convenient, and there's precedent for this: if you place an offer to buy Gateway.IOU, then the trustline will be automatically created for you when your offer executes. This won't necessarily eliminate the need for a second transaction: like the offer-based trustline autocreation, the limit of the automatically created trustline will be 0, so the user won't be able to receive any further funds, unless (s)he chooses to manually adjust the limit.

[RichardAH]

To cash the check, you would need to first create the trustline first, and that is something we could change

I think we should change it. It's a cumbersome UX to have a wallet first create a trustline and ask you to sign it then create a CheckCash txn and ask you to sign that. The double signing UX is bad UX.

[nbougalis]

Agreed: XRPLF/rippled#3790

[yyolk]

From my own perspective in dealing with art objects, provenance is crucial for art sales.

Your trust line, that trust line and it's trust line can be pretty important in art and collectibles.

What is laid out in the proposal also gives the suggestion to black hole the issuing account, so the Trustline serves as a certificate of authenticity in a sense.

I also see it as a means to sign up for a piece prior to it listing for an auction. (Which can then be resold ad-infinitum to any interested party by creating a trust line)

An issuing account can deal with more than one asset / NFT and I think we'll see both single use issued accounts and in time UX around that.

[raajonb]

@yyolk exactly. It already lends well to certain high end use cases where ppl pay for access to exclusive buying opportunities. Ppl should not discount that.

Ability to set up trust lines between various high end NFT Issuers and subscribers who want to pay for access to buying opportunities is a powerful tool in itself.

[RetirePerspired]

Was having some "shower thoughts" surrounding this proposal. I could see a lot of use cases for XRPL NFTs as an "I already paid for this" marker. If I have an app that has a free version, but you need to pay me 20 XRP for the premium content. Once the fee is paid, an NFT would be issued which would would be the key that unlocks the premium content. You would have access the the paid content wherever your wallet was integrated and could even sell your premium access by selling the token to someone else once you're done with it.

Let me know if this sounds plausible. I've been chewing on NFTs for a little bit since they seem to be the current hotness, but I can't shake the feeling that the current use cases (like selling a tweet or an NBA highlight) are very nascent and are more speculative than actually useful.

[mDuo13]

I agree that sounds like an interesting use case and you're on to something regarding the nature of some of the existing uses.

For me one of the biggest question around NFTs relates to resale. If you can't resell the item then it's not really an NFT, and putting the item on a blockchain is probably not much improvement over other ways of digitally selling access to things. But, if anything, the trend over the last twenty years of business models has been towards making things not resaleable, which lets you claim more primary sales revenue. (For example: digital music, movies, and games; in-app purchases that grant "virtual currency" or "battle passes" that can never leave that one game/app; some companies are even trying to claim that they're only selling a license to use their physical goods.)

So any terms or conditions on resale (for example, royalties to the original artist) are going to be a major factor in NFTs, and that's something I don't think the XRP Ledger protocol as it exists today is well-equipped to handle.

That said, it's not necessarily bad to start experimenting with this stuff now and figure out what works best as we go.

[shortthefomo]

Love all the effort put into trying to bring this to the XRPL, however im not a fan of making something work simply because the underlying code does not support it. Having worked on projects over multiple decades, you will eventually work your self into a corner. It would be better to support a new IOU type and extra fields on that type for its meta data than try patch together a solution stuffing extra fields here and there.

It would be better for the ecosystem if this was to be natively supported.

Is my thinking.

[arbiswap]

NFTs are here to stay... games have the best use-case for them rn. Many gamers would love to own own rare in-game land, characters or props. As long as the game is fun or makes people money it will motivate them to own the NFTs. As far as digital art in itself. There is not much value there imo it's more of a fad. I don't think game NFTs are a fad. Digital art must be put to a use to be worth money imo.

XRP has a large community ready to jump on any opportunities. I am currently working on an NFT marketplace as well as a game that will follow. I would love to work with any freelancers who believe they can help me create this on the XRPL.

[SurvX]

Would love to chat! thanks