0014 XLS-14d: (DEPRECATED) Non fungible tokens (indivisible NFT's) on the XRPL #30
Replies: 23 comments 78 replies
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
Most interesting, good onya @WietseWind. Buidl-on. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
lost me along time ago, |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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". |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
I've gone through your JSON @WietseWind and I made my first NFT on XRP …titled, "Y̴O̴L̴K̴" 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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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". |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. At the very least an EIP-1155 "metadata URL" (including 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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
Wow! That's super cool to hear, good thinking ;) - if I can say so myself, haha. Using the Account |
Beta Was this translation helpful? Give feedback.
-
|
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) |
Beta Was this translation helpful? Give feedback.
-
|
After reviewing how the data is presented it might be best to convert to a DDEX related platform. |
Beta Was this translation helpful? Give feedback.
-
|
Would using PayString IDs suffice as an identifier for an NFT? This would likely look like Issuer = wietsewind$xumm.app, NFT = wietsewind+nft$xumm.app |
Beta Was this translation helpful? Give feedback.
-
|
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:
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.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
This could likely be solved by having a 'best practice' of client software checking for any existing conflicting trustlines before creating a new one. |
Beta Was this translation helpful? Give feedback.
-
|
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 👌 |
Beta Was this translation helpful? Give feedback.
-
|
I'm looking forward to reading more about NFT, AMM from JoelKatz too. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
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 ;) |
Beta Was this translation helpful? Give feedback.
-
|
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'.
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?
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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
So how about |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
Completely agree @mDuo13 - I'm updating the proposal. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I was about to chime in and recommend SHA-512, truncated to the length that we desire. 😀 |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
I like this :) |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
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 ( 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. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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. (To distinguish between editions and other NFTs that share the same code, clients could show some of the beginning/end the hash, e.g. More text would allow for |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
A few questions:
Here are a few ideas for uses of XRP NFT's:
The unique advantage of an NFT is that the purchaser can resell their ownership. |
Beta Was this translation helpful? Give feedback.
-
|
Answers:
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your reply.
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@mDuo13 Thank you for that information; it is extremely useful. |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the info. |
Beta Was this translation helpful? Give feedback.
-
|
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: 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. |
Beta Was this translation helpful? Give feedback.
-
|
So the NFT creator must post 20 XRP, and each recipient must post 5 XRP, right? xDAI seems to be a much better way to create and distribute NFT's. Please enlighten me otherwise. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Which is perfect, but doesn't belong in a technical standard proposal discussion. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
Throwing this idea into the mix: Edit: Edit 2: |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
|
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? |
Beta Was this translation helpful? Give feedback.
{{title}}
{{editor}}'s edit
{{editor}}'s edit
-
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
XRPcan 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
Issuing tokens on the XRPL
A simple issue procedure of a token on the XRP Ledger:
AccountSettransaction, setting flag8: "Default Rippling". This is required for future Trust Lines set up by users, to allow them to send the token to each other.TrustSettransaction, trusting the token code to be issued by the Issuing account (this process should be repeated by all future recipients of this token)Paymenttransaction to issue X amount of the token code to the Receiving Hot WalletSetRegularKeyto an account that can't be accessed by anyone, eg.rrrrrrrrrrrrrrrrrrrrBZbvjiAccountSetto disable the native key of the keypair to that accountThe 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.0000000000000000000000000000000000000000000000000000000000000000000000000000000010.{80 zeroes}1This 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':
0.0000000000000000000000000000000000000000000000000000000000000000000000000000000010.00000000000000000000000000000000000000000000000000000000000000000000010.0000000000000000000000000000000000000000000000000000000000000000000000|00000000001As 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
Domainvalue (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.0x02prefix 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 theDomainvalue + a appended value (to be determined, eg. a.well-knownsetup / extension of the XRPL TOML /EIP-1155, ... (needs another proposal)Issuer (issuing account) best practices
1000000000000000e-96) of each token, create unique tokens for unique objectsEmailHashvalue (AccountSet). Possibly use eg. Gravatar to list your email address and attach a logo, so explorers like Bithomp show a logoImplementation
This sample implementation in Javascript can:
PaymenttransactionVice versa, when composing a transaction, amounts (possibly user input) should be converted to NFT representation:
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-96owns 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:
3100000000000000e-95is represented as31).Paymenttransaction) the user input should be converted to NFT-like scientific notationIssuer (issuing account) requirementsabove)1000000000000000e-85This issue contains the planned changelog for adding support for XLS-14d to XUMM Wallet.
Advantages
Potential disadvantages:
Paymenttransactions will work.Sample (issuing, sending)
Here's a sample issue + NFT sending sequence containing XPRL JSON template transactions.
Beta Was this translation helpful? Give feedback.
All reactions