0020 XLS-20d Non-Fungible Token Support (native) #46
Replies: 74 comments 145 replies
-
|
Digesting this, but from my initial read, looks pretty awesome! |
Beta Was this translation helpful? Give feedback.
-
|
Should we allocate a draft number? Looks like |
Beta Was this translation helpful? Give feedback.
-
|
Good one. Done :) |
Beta Was this translation helpful? Give feedback.
-
|
I suspect we need to clarify rules for the
In general the details on the |
Beta Was this translation helpful? Give feedback.
-
|
you are 100% correct. Any chance you were able to integrate it? I am actually a novice coder. I am using NFT tester as my point of reference but unfortunately it doesn't have the details of AccountRoot and MintAccount. Do you have any code example you could share or any reference, really would help. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
The details for the AccountRoot changes don't appear to be available on the documentation site yet. So here's an example of an Note two important features:
Once the Note the I hope that helps. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding the question of the identifier of an Use the |
Beta Was this translation helpful? Give feedback.
-
|
Interesting NFT spec:
One general comment - as we scale we should consider allowing for off-chain message signing for use on-chain. This means we will be able to do offchain orderbooks and onchcian execution to reduce offercreate noises. |
Beta Was this translation helpful? Give feedback.
-
|
I see. I think being able to do native transfer like IOU is an important feature we should consider. |
Beta Was this translation helpful? Give feedback.
-
|
I second this, there could be a lot of new use-cases for NFTs which might want to arrange payment off-ledger or just want to pass ownership of a certain NFT to someone they know. Transfering NFTs like an IOU should be a feature you want to provide to the users. |
Beta Was this translation helpful? Give feedback.
-
|
The problem with a transfer is that there are no trustlines for this so there's no way for a recipient to indicate that they wish to hold an NFT. The seller offering it to the recipient for 0 cost seems to achieve the same thing: if the recipients wants the token, he claims it for free; otherwise he cancels the offer and all is well. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, understood! That was what I was looking for. |
Beta Was this translation helpful? Give feedback.
-
|
This makes sense Nik, though my hesitation is still that this is a rather non-conventional way of doing things and might hurt the adoption rate. Perhaps we can abstract this away from the end user. |
Beta Was this translation helpful? Give feedback.
-
|
It feels like this standard is very close to enabling an on-ledger software licensing model. @WietseWind have you considered what issuing a XUMM Pro license via NFT would look like? I don't think that you could pull off a subscription based licensing model with this standard, but the ability to profit off of every secondary market transaction seems very appealing. |
Beta Was this translation helpful? Give feedback.
-
|
This is really interesting! I like the idea of the native support of NFTs on the XRPL. |
Beta Was this translation helpful? Give feedback.
-
|
I still like the idea where mutable data can be stored in the Domain Field (if required): #44 With the additional fields given in this proposal (URI), the fields given could be reduced in the Domain field. I do have questions on the URI Blob field size, would this also be 256 Bytes? It my opinion we should stay away from relying on data put in memo fields, as this will require the use of full history nodes. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I really like the idea of using the CTI. I'll look back and see how we can leverage that. |
Beta Was this translation helpful? Give feedback.
-
|
I too like the idea of the CTI, just not storing it in a memo field :-) |
Beta Was this translation helpful? Give feedback.
-
|
CTI could be trivially referenced via the URI field (e.g. |
Beta Was this translation helpful? Give feedback.
-
Really wrestling with this part. I don't have any experience with the IPFS, so that's probably slowing me down. I can envision a NFT's that are "minimally invasive" that the ledger should be able to accommodate directly on chain. I don't know what that limit is (128 characters?) but I can easily see something like ownership of virtual land being nothing more than a hash and some coordinates. Seems a shame to necessitate a pointer off-ledger for something so simple. |
Beta Was this translation helpful? Give feedback.
-
|
If the URI field is the same size as the Domain field (which would make sense), you should get ~256 ASCII chars. Some info on what IPFS is: https://docs.ipfs.io/concepts/what-is-ipfs/#content-addressing |
Beta Was this translation helpful? Give feedback.
-
|
Think of the URI as a more general version of a URL. It can be used in many different ways. Your example could be well-served by a URI that uses the |
Beta Was this translation helpful? Give feedback.
-
|
IPFS hasn't necessarily proven itself and has already burned artists and buyers. IMO imgur or archive.org (both free, forever) would be better recommendations for newcomers who don't wish to burn potential buyers while navigating this new space, where buyers have found their works have been lost because the artist's closest node didn't propagate it. Most aren't aware you may not win the popularity contest and never reach propagation beyond your closest node. I'd point this out in the docs, but I'm unable to view them because I block certain IPs coming from certain countries on my lab network, and their docs are apparently coming from that range. |
Beta Was this translation helpful? Give feedback.
-
|
The paper sounds plausible in itself, but I think the part with the external references still needs to be clarified. Offchain data storage in particular has some pitfalls in the context of data management, such as trustworthiness, rights management, data integrity and data security. A simple link is usually not enough. You should therefore pay particular attention to the secure connection to external data services. IPFS sounds promising at first, especially for NFTs (Hash of Content eq. Address), but I am currently not clear about how IPFS itself regulates data access restrictions. I think it is unfavorable if all data content is publicly available one way or another. But in the end this is also part of the NFT's rights policy and order of responsiblity. |
Beta Was this translation helpful? Give feedback.
-
|
What is the primary concern here, keeping data out of the hands of others. Like behind a paywall or inaccessible by others (its encrypted?). With IPFS, you can run gateways that only server CIDs you desire to host. You can easily build in checks to validate who is requesting what resources from you. This assumes you are running a private IPFS network of course. You could encrypt the data, however, once you start passing that NFT around, and give them the key, now all of you have access to that data. Once the cat is out of the bag, its out, IMHO. This is an idea that I am currently exploring as well, so very open to hearing others opinions. |
Beta Was this translation helpful? Give feedback.
-
|
IPFS is also new territory for me. As I understand the gateway concept under How one can apply ACL or the like to a single object is not yet fully apparent to me. As I have understood, the security concept of IPFS relies on trust in the gateway through corresponding certificates on the entire gateway. If you just want to prove NFT ownership via XRPL and the referenced data can be viewed by everyone, then a public gateway is certainly sufficient. However, it does not prevent external data from being accessed by other applications or "pirated copies" via other channels. (Although this cross-ledger NFT validation also represents a new business opportunity .. So many ideas ...) It gets a little more complicated if you want to assign specific access rights more precisely because the data is externalized. This could then perhaps be done via private IPFS gateways, which then add a DRM-like concept on top of the pure data storage. This would also be conceivable in conjunction with XRPL hooks. But I would first have to play through the whole thing as a prototype in my spare time in order to fully understand it. It remains exciting. |
Beta Was this translation helpful? Give feedback.
-
|
@enricohomann i would love to expand on your ideas a bit, because you're touching on points i definitely agree with IPFS has no acl - an object once uploaded can not be deleted. this is problematic is most cases, and it doesn't implicitly mean permanence. If an object doesn't win the popularity contest it doesn't get to exist anymore, if it's not picked up by a node other than your closest node, it will no longer exist. An NFT mint is permanent, the underlying uri should be just as permanent. I'd recommend someone uploading an image to archive.org which has a mandate already to store our most precious assets. Unfortunately it's slow, and works on a budget that should last for decades. Object storage is cheap, and has arguably better incentives in the competitive sphere of cloud storage; already housing most of the objects on the internet. GitHub, Imgur also provide, and have mandated permanence beyond what IPFS has shown thus far. I've been thinking about this a lot, and there's far better ways to deliver content in an (optionally) immutable way, where the underlying asset, the digital Art, is precious. You can add in ACL yourself, regardless of host - if you're pushing a static file In regards to your idea about proving access to an object, one might think about how asymmetric key encryption works, where you have a private and public key pair. If you wanted to think about encrypting an image like a private message, you'd want to scramble the image against the key. The simplest way i can think of is sequentially XOR'ing all the bytes against some equally long length of random bytes. A more efficient method would use a small fraction of the overall image byte length and use it over and over. If you store this key in some way, where you can then prove you are logging in with your wallet (signing a txn on xrpl). You show you own what you own to the "picture frame", which then vends the scrambled image (embedded in the NFT, the URI embedded in the NFT) with the known private key, doing a XOR of the bytes again, which will undo the scrambling. Note: There are better methods to do this! The service can itself not know anything about the image or the NFT, but there would be only one key if the image / asset itself is immutable. If the asset is like how buckets work today, where you must authenticate to retrieve it, or in a simpler sense; with basic http auth; where you'd get a <200: Content-Type: image/png> if you're authorized Another way to prove an original would be with steganography, where you may hide some piece of arbitrary data in the header of an image, that can then later proven as an original if the image itself is re-rendered, resized, lossless, or not where this particular data wouldn't carry over, unless it was 1:1 bytes. |
Beta Was this translation helpful? Give feedback.
-
|
If social media platforms checked an exif field on the asset containing the wallet signature, any asset uploaded could be rejected if the user uploading the asset didn't have access to the wallet that owned the asset. This is what I believe will happen over the next 3 to 5 years. You should NOT be able to upload assets that you can't prove ownership of.. Just my thoughts. |
Beta Was this translation helpful? Give feedback.
-
That's a fascinating concept, but given how many of our current social media networks built their current position on the basis of the exact opposite, I can't see it catching on. But also, how would brand-new assets be marked? Are you going to configure your digital camera with signing keys? Your scanner? Not to mention every piece of software out there that people use to make digital art. And if it's just an EXIF field, it seems like it would be trivial to remove the field and replace with one that has a different signature. Not to mention the complicating and chilling effects that any such restriction could have on the creation of legally-allowed derivative works, licensing agreements including time-limited licenses, and so on. Certainly, there are way too many difficult challenges (social and legal ones, which are not so quickly resolved as technical ones) for a restriction like that to be put in place in 5 years. |
Beta Was this translation helpful? Give feedback.
-
|
Excited to see the possibilities of NFTs on XRPL. I am working on CO2 Bonds/Conservation NFTs and would love to learn if something like this https://github.com/BooneTB/CO2StakingBonsai/blob/main/CarbonBOND |
Beta Was this translation helpful? Give feedback.
-
|
Sorry I haven't been able to review your GitHub link. I'll try to take a read this weekend and follow up. |
Beta Was this translation helpful? Give feedback.
-
|
I've got an Social Media prototype using ethereum hybrid 721's.... Every asset uploaded is a "721" contract but can also hold a token balance. I call my tokens SAMY. Every view on the asset reduces the token balance by one, paid to the "viewer" Every comment/like, adds a token to the balance, paid by the "commenter/liker". A simple basic decentralized way to measure engagement and reward users. I stripped the ETH protocol today and I'm going to try to add the XRP protocol features for NFT. I did have one question. Smart Contracts on ethereum can hold value, I view this feature in XRPL as just the wallet that holds the value. Sure, the functionality of the code doesn't reside inside the wallet on XRPL, but by using multi sign, I can basically create the same idea and did this using a swift class if anyone is interested. Is there a better way to achieve this? I know you just released hooks but to be honest I've been head down in my ethereum private blockchains. I like XRP more tho. Would love to discuss. |
Beta Was this translation helpful? Give feedback.
-
|
Hooks has not been released; there is a test network operated by the amazing team at XRPL Labs, but I believe that they are still actively developing the Hooks feature. I don't want to speak for them, but I suspect they'd characterize it as an alpha release. Beyond that, I'm not quite sure what you're asking. If you want to lock up value, you can look at Escrow, which includes support for preimage cryptoconditions. If I'm understanding your question, it may be a good analog. |
Beta Was this translation helpful? Give feedback.
-
|
I'll checkout hooks. I think that solves my problem. Also, are these just specs for later development or can I actually start testing these features in the testate? |
Beta Was this translation helpful? Give feedback.
-
|
I think there's a devnet that you can use for hooks. I found these links. https://hooks-testnet.xrpl-labs.com/ https://github.com/XRPL-Labs/xrpld-hooks/blob/hooks-ssvm/README.md XLS-20 (this page) isn't in devnet yet, but my guess it that some version of it will be very soon. |
Beta Was this translation helpful? Give feedback.
-
|
Looking forward to it. Hooks + NFT is going to bring some really cool features. |
Beta Was this translation helpful? Give feedback.
-
|
Would it be possible for a |
Beta Was this translation helpful? Give feedback.
-
|
Great question. That would be a neat feature but it's a little tricky to implement directly; the challenge is that we want to keep the size of an individual NFT object minimal. Implementing this suggestion would increase the complexity and the size of the object. Despite that, I think that what you're describing is useful and I wonder if it could be a good use case for the Hooks amendment that @RichardAH is working on. |
Beta Was this translation helpful? Give feedback.
-
|
When minting an NFT it looks like there are 2 routes that can be taken from a 3rd parties perspective. Example: Website A wants to offer the ability for users to create NFTs. Website A must either:
Is this correct? What are the downsides for setting User B, User C, User D, as issuers when they mint their own NFTs and not setting Website A as the issuer? |
Beta Was this translation helpful? Give feedback.
-
|
So, it depends. If website A wants to allow the minting under its own account, the no; it doesn't need to do anything special. If it wants to allow user A to mint with their own account then either user A must set their |
Beta Was this translation helpful? Give feedback.
-
|
Great proposal! I think this is a solid step towards supporting NFTs on XRPL. I have a question about These objects are updated automatically with If so, what possible use cases could there be for having the ability to change this object outside of a mint or burn transaction? |
Beta Was this translation helpful? Give feedback.
-
|
These pages hold collections of NFTs. Because we need the ability to transfer NFTs from one user to another, the transaction makes that possible must be able to:
|
Beta Was this translation helpful? Give feedback.
-
|
Ah I see. That makes sense. Are these transfer operations quantified? For e.g. an |
Beta Was this translation helpful? Give feedback.
-
|
I've been thinking a little more about this proposal and would like to suggest a change that should make NFT objects even more lightweight. Currently, an NFT contains both a 20-byte issuer and a 32-byte hash, for a total of 55 bytes. The 32-byte hash is meant to distinguish this NFT from any other, but in reality it only adds trouble. For example, an issuer could "double-issue" a token, and there's no way for the ledger to detect this, much less prevent it. Maybe that's fine, of course; maybe issuers shouldn't shoot themselves in the foot, but the spec is meant to allow for "non-fungible" tokens and yet it allows for the creation of binary-identical objects. What does it mean when have two "non-fungible" tokens that are identical and cannot be distinguished? What if we were to add an additional field: a "serial number" of sorts. But what to set it to? Well, the transaction's sequence number seems reasonable. It's never reused, so it works. It means that even if the issuer reuses the hash, the two resulting NFTs are distinct. This causes trouble with the mint account, but we can solve this by adding a new optional field to the account root: a 64-bit number But if we're going to do that, why even have a 256-bit identifier? Why not just treat the pair And this also enables something else that's really neat: we can create semi-fungible tokens. We can simply add an optional 32-bit field to an NFT, let's call it So, now we can use Let's say the issuer wants to issue an NFT to represent a limited edition album. They can assign that album a unique 32-bit number, and issue any number of tokens which are all "linked": |
Beta Was this translation helpful? Give feedback.
-
|
I like this. Lightweight is good. I think we should use existing standards and build upon them, not adding new standards & not by storing a lot of data on ledger. These NFT's are probably going to live on the ledger forever. All kinds of meta data stored in e.g. URI Blob fields aren't supposed to live on the ledger imo. I would propose to even scratch the URI field, and simply use:
|
Beta Was this translation helpful? Give feedback.
-
|
I agree with this, less is more :-) I am concerned that using HTTP domains create a possible issue, like said person looses the domain. Creates a *possible centralized point of failure. Proposed solution: IPNS/Domain Owner creates an IPNS key pair, gets address and then registers a domain w/ the same name. Both the IPNS location and domain can be updated, aka keep the toml file updated with the latest information. If the user looses control over either one, they have a fall back they can use. The IPNS key can be generated in such a way as to be easily stored away in case it needs to be recovered. There are downsides to this of course. |
Beta Was this translation helpful? Give feedback.
-
|
Agree with Wietse, the URI fields invites issuers to bad practice, and you could imagine the XRPL being cluttered with alot of dead-link NFTs in the future. Dropping it would
|
Beta Was this translation helpful? Give feedback.
-
|
There is no way given this spec. I have a PR in review that will add this
ability to clio - it will let you query by tokenid and see the owner, as
well as the decrypted uri and other fields.
If you’re unfamiliar With clio, it’s a reporting/performance layer on top
of rippled.
We are planning to have this feature ready soon and available for query.
…On Mon, Apr 11, 2022 at 20:52 Mahiros ***@***.***> wrote:
Hello, I want to get owner account info from NFTokenID, how can I get
account info?
I can get NFTs list from the account using account_nfts.
—
Reply to this email directly, view it on GitHub
<#46 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABXUFDK7W2WTK3JKL7PUBLLVETCL3ANCNFSM45N47IJA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Here's the Github link to Clio. CJ Cobb, one of the lead developers for Clio, gave a very good breakdown of the motivations behind Clio's development link |
Beta Was this translation helpful? Give feedback.
-
|
Clio seems like a great tool but arguably looking up who a given NFT belongs to seems to be something that is so common that it would be great if it was natively supported. |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys - Just to keep systems/docs updated, I'd like to suggest a few edits...
|
Beta Was this translation helpful? Give feedback.
-
|
Feature Request This feature request describes absent yet essential functionality on the XRPL, with regards to fetching Account Objects for a particular address. It is currently possible to request certain types of Account Objects by providing the type of such objects in the parameters of an “account_objects” request, as indicated here. For example, adding { type: “escrow” } to an “account_objects” request will exclusively return Account Objects of the escrow type. Such functionality, however, does not exist with regards to the new NFTokenOffer objects that have been introduced through the XLS-20 amendment. Indeed, the only possible means by which to retrieve all NFTokenOffers related to an account is to query for all of the Account Objects associated with an account, and filter against their type field. As a consequence, there exists no efficient way to retrieve only NFTokenOffer objects related to one account. Ultimately, this calls for a revision that enables the provision of a relevant type such as { type: “nftoken_offer” } or similar. |
Beta Was this translation helpful? Give feedback.
-
|
Although it's not mentioned in the spec, the implementation provides an RPC command, Just to clarify, are you asking that |
Beta Was this translation helpful? Give feedback.
-
|
@scottschurr, I think he is referring to offers on an NFT. |
Beta Was this translation helpful? Give feedback.
-
|
NFTokenOffer objects related to one account. |
Beta Was this translation helpful? Give feedback.
-
|
Yes exactly, not only for token, but for account. Its in account_objects, but can't be filtered in RPC. |
Beta Was this translation helpful? Give feedback.
-
|
@ledhed2222 https://github.com/XRPLF/clio |
Beta Was this translation helpful? Give feedback.
-
|
@bashash and @dangell7, thanks for your corrections. I mis-read the concern. |
Beta Was this translation helpful? Give feedback.
-
|
@bashash and @dangell7, my tests suggest that the |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately that is not possible given the directory structure of NFTs.
That structure was chosen for performance, and to reduce reserve
requirements for end-users. This is just an example of dev tradeoffs, but
Clio is able to fill in the gap.
…On Wed, Apr 20, 2022 at 4:19 PM Julian Gums ***@***.***> wrote:
Clio seems like a great tool but arguably looking up who a given NFT
belongs to seems to be something that is so common that it would be great
if it was natively supported.
—
Reply to this email directly, view it on GitHub
<#46 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABXUFDOSR5MBJD6BHDANFSLVGBRERANCNFSM45N47IJA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Owner test with regards to accepting buy offers. The following describes a simple flow to demonstrate the somewhat counterintuitive role of the Owner field with regards to the creation of NFToken Buy Offers on the XRPL. This counterintuitive behaviour can be attributed to the premise that the requirement of an Owner field in the NFTokenCreateOffer transaction ensures that such an offer may only be accepted by the address specified in the owner field. The flow described below, however, reveals that this is not the case: Account 1 creates offer for 100 XRP with owner Account 3 Account 2 creates offer for 100XRP with owner Account 3 Account 3 accepts Account 2’s offer Account 2 accepts Account 1’s offer Following from the above described premise, Account 2 should not have been able to accept Account 1’s offer on the principle that Account 1’s offer was made with the Owner field specified as the address of Account 3. The conclusion, thus, is that the Owner field is significant only when a buy offer is being created. Assigning the Owner field with an address that is not the current owner of the NFT prevents that offer from being successfully made, but does not appear to have any further behaviours or interactions. That is to say, the Owner field does not prevent buy offers from being accepted by a ‘new’ owner whose address is different from the ‘original’ owner address which was used to create that buy offer. |
Beta Was this translation helpful? Give feedback.
-
|
@bashash, thanks for reporting this concern. I've reproduced the scenario you've described. Yes, it's confusing, but it is the way things currently work. The I'm not particularly concerned about the issue you raise because, under most situations, the value of an NFT that you own should be a reflection of the NFT itself, not who you bought it from. In all cases the buyer spent the amount of money that they committed to in their offer. In summary, what you are seeing is expected behavior, even if it is not intuitive. I hope that helps. |
Beta Was this translation helpful? Give feedback.
-
|
@scottschurr When transferring an NFT would all the past orders for that token id owned by XYZ be "destroyed" or is it up to the user client or rpc indexing to handle this? |
Beta Was this translation helpful? Give feedback.
-
|
@Andrewkasko, when an The former owner of the transferred However any buy offers in the ledger for that |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys, I have written up a new proposal to expand on the XLS-20d proposal for NFTs. The change would help owners manage the NFT's they have in there wallets and also mitigate some potential bad user experience and negative feedback on how NFT's work in XRPL. It would be good if you take a look, comment and hopefully up-vote my proposal. |
Beta Was this translation helpful? Give feedback.
-
|
Suggested edits to align the standard with the implementation, prior to moving XLS-20d from draft to final: 1.2.1.1.1.4 Example
Example TokenPage JSON
The NFTokenMint transaction
Example NFTokenMint transaction
The NFTokenBurn transaction
1.3. Account Root modifications
1.3.3 BurnedNFTokens
1.4.1.1. NFTokenOfferID Format
1.5.4.1. Fields
|
Beta Was this translation helpful? Give feedback.
-
|
Should also update to remove the |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if that should be left in the standard and documentation, but be updated with a deprecation notice, as it's basically fixed in a fix amendment? |
Beta Was this translation helpful? Give feedback.
-
|
I minted NFTs on behalf of other account. I used Account A and minted for Account B. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
If I create sell offers with price 0, they will go to another account, not account B. |
Beta Was this translation helpful? Give feedback.
-
|
@mahiros-tech - no, this is the purpose of the More generally though, what is the purpose of this flow? If you want B to own them then why don't you just mint them from B in the first place? |
Beta Was this translation helpful? Give feedback.
-
|
Minting from B is possible, but when minting bulk nfts, it's terrible to mint one by one from the client or user side. |
Beta Was this translation helpful? Give feedback.
-
|
Hello |
Beta Was this translation helpful? Give feedback.
-
|
I've come across an issue. It is very easy to create buy offers from unfunded accounts. Here is one I have done for 250M XRP. Obviously I don't have that, even in devnet. https://xls20.bithomp.com/explorer/18B9E787507DD6EA61874BD1E8EA6C61E41825B343542F3FCE97C1666CD899F0 These buys orders generate a tech unfunded error on the sell side. |
Beta Was this translation helpful? Give feedback.
-
|
You can create a similar situation by creating a purchase offer for 10,000 XRP while holding 10,000 XRP and then sending 10,000 XRP to another address. We have to check in our auction system if the bidder has enough balance for the winning bid amount. Alternatively, the |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure how the NFTokenPage concept works on an atomic level but I noticed that they never get completely filled with NFTs. Initially, I thought they always fill up to 32 but I'm seeing token pages with 17-29 NFTs in them when I mint. If I mint the same things twice, I get the same amount of pages so it does not seem random but there seems to be a deterministic algorithm for it. But how? How can I work out if I am going to mint x amount of NFTs, how much reserve I will need? Or does this depend on the exact NFTokenIDs as it seems like this is some kind of indexing issue and an NFTokenID can either fit into a page or it can't, based on how high/low it is and a new one needs to be created? Anyone that can explain? |
Beta Was this translation helpful? Give feedback.
-
|
Good questions, thanks for asking. Looking forward to someone's insights! |
Beta Was this translation helpful? Give feedback.
-
|
@juliangums, FWIW, NFToken pages do get filled to 32, but on average they will tend to contain about 23 to 24 NFTokens per page on average. This is observed experimentally and there is some intuition for how this ends up being the case. Following are some details for the curious. The implementation is struggling with four different things that need to be optimized:
The implementation does this by following a few simple rules:
So the very first page will always fill to 32 NFTokens. Then there will be two pages with 16 and 17 each. From there it depends on which page each newly added token is added to. Once any page exceeds 32 it will split into two pages of 16 and 17 each. Given an account that owns more than 16 NFTokens, it should be a fairly unusual circumstance where one NFTokenPage contains fewer than 16 NFTokens. I hope that helps, even though it does not give you a predictable algorithm to follow. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @scottschurr - gives us some understanding of what we're seeing, but it's very, very hard to explain this to end users. Who do want to know why their reserve changed. Being as unpredictable as it is right now, this is resulting in quite a lot confusion. I don't have the answer yet, but I do feel more predictable behaviour would be very welcome, as it would allow clients to inform users what will happen to their reserve before support tickets are being sent about 2 XRP being 'stolen', etc. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @WietseWind. I sympathize with your position. I feel motivated to point out that even though I described the current implementation, it is not my design. I've simply spent enough time working with the current design (occasionally being surprised by it) that I can describe the design fairly succinctly. It seems likely, although I haven't tested this, that if we tell people to expect to pay one owner reserve for every 16 NFTokens, then they may be pleasantly surprised that their actual owner reserve is somewhat less. I think that guidance should usually keep people from running up against reserve limits. That should probably be tested before actually offering it as guidance. I may be missing a corner case or two. Beyond a heuristic like the one above, re-designing how NFTokens are packed into pages so the result is more predictable would take some serious work. I don't have immediate suggestions for how to approach that. |
Beta Was this translation helpful? Give feedback.
-
|
In my communication with marketplace start-ups (not the same kind of user), I also use Scott's heuristic. IE as long as the user knows that we're talking about averages here, we can say that roughly every 24th NFT increases your reserve. |
Beta Was this translation helpful? Give feedback.
-
|
I know that this is already active/enabled on mainnet, but just for the sake of having this documentation correct, I propose following changes to original post:
That is actually not true. So actually the transfer fee is wrong. Also, in the same section, you are showing how tokenId is calculated. With flags as first for characters etc. 000B => Flags: 11, not 12. We cannot have flags with value of 12. |
Beta Was this translation helpful? Give feedback.
-
|
+1 on this |
Beta Was this translation helpful? Give feedback.
-
|
Note for future readers: This spec has been implemented and adopted, and is being updated and approved here: #95 |
Beta Was this translation helpful? Give feedback.
and others
-
Latest version: XLS-20 Non-Fungible Tokens
A previous version of the spec follows:
1. Non-Fungible Token Support
1.1. Abstract
The XRP Ledger offers support for tokens (a.k.a. IOUs or issued assets). Such assets are, primarily, fungible. They can be easily traded between users for XRP or other issued assets on the XRP Ledger's decentralized exchange. This makes them ideal for payments.
Such objects can also be used to implement non-fungible tokens (NFTokens), as seen in an example implementation by the XRPL Labs team.
Non-fungible tokens serve to encode ownership of physical, non-physical or purely digital goods, such as works of art and in-game items.
This proposal introduces extensions to the XRP Ledger that would support a native non-fungible token type, along with operations to enumerate, purchase, sell and hold such tokens.
While other proposals (some of which are extremely interesting) have been made, the authors believe that this proposal represents a strong commitment to supporting NFTs on the XRP Ledger, and adds a rich set of flexible primitives that can be used by token issuers.
The non-fungible tokens proposed are:
1.1.1. Advantages and Disadvantages
Advantages
Disadvantages
1.2. Creating and Transferring Tokens on XRPL
1.2.1. On-Ledger Data Structures
We propose two new objects and one new ledger structure:
NFTokenis a new object that describes a single NFT.NFTokenOfferis a new object that describes an offer to buy or sell a singleNFToken.NFTokenPageis a ledger structure that contains a set ofNFTokenobjects owned by the same account.1.2.1.1. The
NFTokenobjectThe
NFTokenobject represents a single NFT and holds data associated with the NFT itself. NFTs are created using theNFTokenMinttransaction and can, optionally, be destroyed by theNFTokenBurntransaction.1.2.1.1.1. Fields
An
NFTokenobject can have the following required and optional fields. Notice that, unlike other objects no field is needed to identify the object type or current owner of the object, because NFTs are grouped into pages that implicitly define the object type and identify the owner.NFTokenIDstringUINT256This composite field uniquely identifiers a token; it contains a set of 16 bits that identify flags or settings specific to the NFT, 16 bits that encode the transfer fee associated with this token, if
any, the 160-bit account identifier of the issuer, a 32-bit issuer-specified taxon, and an
(automatically generated) monotonically increasing 32-bit sequence number.
The 16-bit flags and transfer fee fields, and the 32-bit taxon and sequence number fields are stored in big-endian format.
1.2.1.1.1.1
FlagsA set of flags indicating properties or other options associated with this
NFTokenobject. The type specific flags proposed at this are:These flags are immutable: they can only be set during the
NFTokenMinttransaction and cannot be changed later.📝 The
lsfTrustLinefield is useful when the token can be offered for sale for assets other than XRP and the issuer charges aTransferFee. If this flag is set, then a trust line will be automatically created, when needed, to allow the issuer to receive the appropriate transfer fee. If this flag is not set then an attempt to transfer for token for an asset that the issuer does not have a trustline for will fail.1.2.1.1.1.2
TransferFeeThe value specifies the fee, in tenths of a basis point, charged by the issuer for secondary sales of the token, if such sales are allowed at all. Valid values for this field are between 0 and 50,000 inclusive and a value of 1 is equivalent to 1/10 of a basis point or 0.001%, allowing transfer rates between 0% and 50%. A
TransferFeeof 50,000 corresponds to 50%.1.2.1.1.1.3 Taxon Scrambling
An issuer may issue several NFTs with the same taxon; to ensure that NFTs are spread across multiple pages we lightly mix the taxon up by using the sequence (which is not under the issuer's direct control) as the seed for a simple linear congruential generator.
From the Hull-Dobell theorem we know that
f(x)=(m*x+c) mod nwill yield a permutation of[0, n)whennis a power of 2 ifmis congruent to1 mod 4andcis odd.This proposal fixes
m = 384160001andc = 2459. Changing these numbers after this proposal is implemented and deployed would be a breaking change requiring, at a minimum, an amendment and a way to distinguish token IDs that were generated with the old code.1.2.1.1.1.4 Example
For example, the
NFTokenID000B013A95F14B0E44F78A264E41713C64B5F89242540EE2BC8B858E00000D65would uniquely identify the token withTaxon146,999,694 andSequence3,429, issued byrNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2. TheTransferFeeis 3.14% and theFlagsassociated with the token are:lsfBurnable,lsfOnlyXRPandlsfTransferable:ℹ️ Notice that the scrambled version of the taxon is
0xBC8B858E: the scrambled version of the taxon specified by the issuer. But the actual value of the taxon is the unscrambled value.URIstringBLOBA URI that points to the data and/or metadata associated with the NFT. This field need not be an HTTP or HTTPS URL; it could be an IPFS URI, a magnet link, immediate data encoded as an RFC2379 "data" URL, or even an opaque issuer-specific encoding. The URI is NOT checked for validity, but the field is limited to a maximum length of 256 bytes.
📝 In the interest of reducing the size of NFT objects and their impact on the ledger as a whole as well as maximizing flexibility, this implementation recommends (but does not require) that this field be avoided. Not only does this field increase the amount of data that must be stored on ledger, but it is also immutable, which means that, if specified, it commits the issuer to hosting the data and/or metadata associated with the NFT at the specified location. See the Retrieving NFToken Data and Metadata section below for details on alternatives.
1.2.1.1.2.1. Example NFToken JSON
Retrieving NFToken Data and Metadata
In the interest of (a) minimizing the footprint of an NFT but without sacrificing utility or functionality; and (b) imposing as few restrictions as possible, this specification does not allow an NFT to hold arbitrary data fields. Instead, such data, whether structured or unstructured, is maintained separately and referenced by the NFT. This proposal recommends using one of the following two approaches to provide external references to obtain
NFTokendata and/or metadata.URIfield: We propose an optionalURIfield in theNFTokenobject. Implementations MAY choose to use this field to provide an external reference to:Hash.NFTokenobject.The
URIfield is especially useful for referring to non-traditional Peer-to-Peer (P2P) URLs. For example, aNFTokenMinterwishing to storeNFTokendata and/or metadata using the Inter Planetary File System (IPFS) MAY useURIfield to refer to data on IPFS in different ways, each of which is suited to different use-cases. For more context on types of IPFS links that can be used to store NFT data, see here.Domainfield: Alternative to the above approach, issuers ofNFTokenobjects may set theDomainfield of their issuing account to the correct domain and offer an API for clients that want to lookup the data and/or metadata associated with a particular NFT. This proposal recommends the use of DNSTXTrecords as a customization point, allowing the issuer to specify the URL to be used by providing a properly-formatted TXT record.Note that using this mechanism requires the
NFTokenMinterto acquire a domain name and set the domain name for their minting account, but does not require theNFTokenMinterto necessarily operate a serveror other service to provide the ability to query this data; instead, a
NFTokenMintercan easily "redirect" queries to a data provider (e.g., to a marketplace, registry or other service).Implementations should attempt to check for the presence of
URIfield first to retrieve the associated data and/or metadata. In caseURIfield does not exist, implementations should check for the presence ofDomainfield. Nothing happens, if neither of the fields exist. Implementations should be prepared to handle HTTP redirections (e.g., using HTTP responses 301, 302, 307 and 308) from the URI.TXT Record Format:
The string
{:NFTokenID:}should be replaced with the requested tokens'NFTokenID, as a 64 byte hex string when attempting to query information.Implementations should check for the presence of
TXTrecords and use those query strings if present. If no string is present, implementations should attempt to use a default URL. Assuming the domain was example.com, the default URL this proposal recommends would be:https://example.com/.well-known/xrpl-nft/{:nft_id:}The
NFTokenPageledger entryThis object represents a collection of
NFTokenobjects owned by the same account. It is important to note that theNFTokenobjects themselves reside within this page, instead of in a dedicated object entry in theSHAMap. An account can have multipleNFTokenPageledger objects, which form a doubly-linked list (DLL).In the interest of minimizing the size of a page and optimizing storage, the
Ownerfield is not present since it is encoded as part of the object's ledger identifier (more details in theNFTokenPageIDdiscussion).Fields
An
NFTokenPageobject may have the following required and optional fields:LedgerEntryTypestringUINT16Identifies the type of ledger object. This proposal recommends the value
0x0050as the reserved ledger entry type.PreviousPageMinstringUINT256The locator of the previous page, if any. Details about this field and how it should be used are outlined below, after the construction of the
NFTokenPageIDis explained.NextPageMinstringUINT256The locator of the next page, if any. Details about this field and how it should be used are outlined below, after the construction of the
NFTokenPageIDis explained.PreviousTxnIDstringHASH256Identifies the transaction ID of the transaction that most recently modified this
NFTokenPageobject.PreviousTxnLgrSeqnumberUINT32The sequence of the ledger that contains the transaction that most recently modified this
NFTokenPageobject.NFTokensobjectTOKENThe collection of
NFTokenobjects contained in thisNFTokenPageobject. This specification places an upper bound of 32NFTokenobjects per page. Objects should be stored in sorted order, from low to high with the low order 96 bits of theNFTokenIDused as the sorting parameter.TokenPage ID Format
Unlike other object identifiers on the XRP Ledger, which are derived by hashing a collection of data using
SHA512-Half,NFTokenPageidentifiers are constructed so as to specfically allow for the adoption of a more efficient paging structure, ideally suited for NFTs.The identifier of an
NFTokenPageis derived by concatenating the 160-bitAccountIDof the owner of the page, followed by a 96 bit value that indicates whether a particularNFTokenIDmay be contained in this page.More specifically, and assuming that the function
low96(x)returns the low 96 bits of a 256-bit value, an NFT withNFTokenIDAcan be included in a page withNFTokenPageIDBif and only iflow96(A) >= low96(B).For example, applying the
low96function to the NFT described before, which had an ID of000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65the functionlow96would return42540EE208C3098E00000D65.This curious construct exploits the structure of the SHAMap to allow for efficient lookups of individual
NFTokenobjects without requiring iteration of the doubly-linked list ofNFTokenPages.Example TokenPage JSON
How do
NFTokenPageobjects work?The page within which an
NFTokenentry is stored will be formed as described above. This is needed to find the correct starting point in the doubly-linked list ofNFTokenPageobjects if that list is large. This is because it is inefficient to have to traverse the list from the beginning if an account holds thousands ofNFTokenobjects in hundreds ofNFTokenPageobjects.Searching an
NFTokenobjectTo search for a specific
NFToken, the first step is to locate theNFTokenPage, if any, that should contain thatNFToken. For that do the following:Compute the
NFTokenPageIDusing the account of the owner and theNFTokenIDof the token, as described above. Then search for the ledger entry whose identifier is less than or equal to that value. If that entry does not exist or is not anNFTokenPage, theNFTokenis not held by the given account.Adding an
NFTokenobjectAn
NFTokenobject can be added by using the same approach to find theNFTokenPageit should be in and adding it to that page. If after addition the page overflows, find thenextandpreviouspages (if any) and balance those three pages, inserting a new page as/if needed.Removing an
NFTokenobjectAn
NFTokencan be removed by using the same approach. If the number ofNFTokensin the page goes below a certain threshhold, an attempt will be made to consolidate the page with apreviousor subsequent page and recover the reserve.Reserve for
NFTokenPageobjectEach
NFTokenPagecosts an incremental reserve to the owner account. This specification allows up to 32NFTokenentries per page, which means that for accounts that hold multiple NFTs the effective reserve cost per NFT can be as low as R/32 where R is the incremental reserve.The reserve in practice
The value of the incremental reserve is, as of this writing, 2 XRP. The table below shows what the effective reserve per token is, if a given page contains 1, 8, 16, 32 and 64 NFTs:
Transactions
This proposal introduces several new transactions to allow for the minting, burning and trading of NFTs. All transactions introduced by this proposal incorporate the common transaction fields
that are shared by all transactions. Common fields are not document in this proposal unless needed because this proposal introduces new possible values for such fields.
Transactions for minting and burning NFTs on XRPL
We define two transactions:
NFTokenMintandNFTokenBurnfor minting and burning NFTs respectively on XRPL.The
NFTokenMinttransactionThe
NFTokenMinttransaction creates anNFTokenobject and adds it to the relevantNFTokenPageobject of theNFTokenMinter. A required parameter to this transaction is theTokenfield specifying the actual token. This transaction is the only opportunity theNFTokenMinterhas to specify any token fields that are defined as immutable (e.g., theTokenFlags).If the transaction is successful, the newly minted NFToken will be owned by the account (the
NFTokenMinteraccount) which executed the transaction. If needed, a newNFTokenPageis created for this account and a reserve is charged as described earlier.Transaction-specific Fields
TransactionTypestringUINT16Indicates the new transaction type
NFTokenMint. The integer value is25.AccountstringACCOUNT IDIndicates the account which is minting the token. The account MUST either:
Issuerfield in theNFTokenobject; orNFTokenMinterfield in theAccountRootof theIssuerfield in theNFTokenobject.IssuerstringACCOUNT IDIndicates the account that should be the issuer of this token. This value is optional and should only be specified if the account executing the transaction is not the
Issuerof theNFTokenobject. If it is present, theNFTokenMinterfield in theAccountRootof theIssuerfield must match theAccount, otherwise the transaction will fail.NFTokenTaxonnumberUINT32Indicates the taxon associated with this token. The taxon is generally a value chosen by the
NFTokenMinterof the token and a given taxon may be used for multiple tokens. Taxons have a valid range range from 0x0 to 0xFFFFFFFF.FlagsnumberUINT32Specifies the flags for this transaction. In addition to the universal transaction flags that are applicable to all transactions (e.g.,
tfFullyCanonicalSig), the following transaction-specific flags are defined and used to set the appropriate fields in the NFT:TransferFeenumberUINT16The value specifies the fee to charged by the issuer for secondary sales of the Token, if such sales are allowed. Valid values for this field are between 0 and 50,000 inclusive, allowing transfer rates of between 0.000% and 50.000% in increments of 0.001.
The field MUST NOT be present if the
tfTransferableflag is not set. If it is, the transaction should fail and a fee should be claimed.URIstringBLOBA URI that points to the data and/or metadata associated with the NFT. This field need not be an HTTP or HTTPS URL; it could be an IPFS URI, a magnet link, immediate data encoded as an RFC2379 "data" URL, or even an opaque issuer-specific encoding. The URI is NOT checked for validity, but the field is limited to a maximum length of 256 bytes.
Embedding additional information
If
NFTokenMintersneed to specify additional information during minting (for example, details identifying a property by referencing a particular plat, a vehicle by specifying a VIN, or other object-specific descriptions) they should use thememofunctionality that is already available on the XRP Ledger as a common field. Memos are a part of the signed transaction and are available from historical archives, but are not stored in the ledger.Example
NFTokenMinttransactionThis transaction assumes that the issuer,
rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2, has set theNFTokenMinterfield in itsAccountRoottorvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B, thereby authorizing that account to mint tokens on its behalf.Execution
In executing, this transaction will examine the
MintedNFTokensfield in the account root of theIssuerand use it to construct theNFTokenIDfor the token being minted. If the field does not exist, the field will be assumed to have the value 0; the value of the field will then be incremented by exactly 1.The
NFTokenBurntransactionThe
NFTokenBurntransaction is used to remove anNFTokenobject from theNFTokenPagein which it is being held, effectively removing the token from the ledger ("burning" it).If this operation succeeds, the corresponding
NFTokenis removed. If this operation empties theNFTokenPageholding theNFTokenor results in the consolidation, thus removing anNFTokenPage, the owner’s reserve requirement is reduced by one.Transaction-specific Fields
TransactionTypestringUINT16Indicates the new transaction type
NFTokenBurn. The integer value is26.AccountstringACCOUNT IDIndicates the
AccountIDthat submitted this transaction. The account MUST be either the presentownerof the token or, if thelsfBurnableflag is set in theNFToken, either theissueraccount or an account authorized by the issuer, i.e.,NFTokenMinter.NFTokenIDstringUINT256Identifies the
NFTokenobject to be removed by the transaction.Example
NFTokenBurnJSON1.3. Account Root modifications
This proposal introduces 3 additional fields in an
AccountRoot:NFTokenMinterfield;MintedNFTokensfield; and theBurnedNFTokensfield.1.3.1
NFTokenMinterIt is likely that issuers may want to issue NFTs from their well-known account while, at the same time wanting to delegate the issuance of such NFTs to a mint or other third party. To enable this use case, this specification introduces a new, optional, field in the
AccountRootobject.NFTokenMinterstringAccountIDThe
NFTokenMinterfield, if set, specifies an alternate account which is allowed to execute theNFTokenMintandNFTokenBurnoperations on behalf of the account.The
AccountSettransaction should be augmented to allow the field to be set or cleared.Note: Previous versions of this spec used the term
MintAccountfor this field.1.3.2
MintedNFTokensTo ensure the uniqueness of
NFTokenobjects, this proposal introduces theMintedNFTokensfield. This field is used during theNFTokenMinttransaction and used to form theNFTokenIDof the new object. If this field is not present the value 0 is assumed.1.3.3
BurnedNFTokensTo provide a convenient way to determine how many
NFTokenobjects issued by an account are still active (i.e., not burned), this proposal introduces theBurnedNFTokensfield. If this field is not present the value 0 is assumed. The field is incremented whenever a token issued by this account is burned. So this field will be present and non-zero for any account that has issued at least one token and one or more of those tokens have been burned.📝 An account for which the difference between the number of minted and burned tokens, as stored in the
MintedNFTokensandBurnedNFTokensfields respectively, is non-zero cannot be deleted.1.4. Transferability of Tokens (NFTs)
Tokens which have the
lsfTransferableflag set can be transferred among users. This is achieved by way of offers.1.4.1. The
NFTokenOfferledger entryThe
NFTokenOfferledger entry represents an offer to buy, sell or transfer anNFTokenobject. AnNFTokenOfferobject is created as a result ofNFTokenCreateOffertransaction by the owner of theNFToken.1.4.1.1.
NFTokenOfferIDFormatThe unique ID, a.k.a
NFTokenOfferIDof theNFTokenOfferobject is the result ofSHA512-Halfof the following values concatenated in order:NFTokenOfferspace key; this proposal recommends using the value0x0074;AccountIDof the account placing the offer; andSequence(orTicket) of theNFTokenCreateOffertransaction that will create theNFTokenOffer.Fields
OwnerstringAccountIDIndicates the
Ownerof the account that is creating and owns the offer. Only the currentOwnerof anNFTokencan create an offer to sell anNFToken, but any account can create an offer to buy anNFToken.LedgerEntryTypestringUINT16Indicates the type of ledger object. This proposal recommends using the value
0x0074.FlagsnumberUINT32A set of flags associated with this object, used to specify various options or settings. This proposal only defines one flag at this time, used to determine if this is a
Buyor
Selloffer:PreviousTxnIDstringHash256Indicates the identifying hash of the transaction that most recently modified this object.
PreviousTxnLgrSeqnumberUINT32Indicates the index of the ledger that contains the transaction that most recently modified this object.
NFTokenIDstringUINT256Specifies the
NFTokenIDof theNFTokenobject being referenced by this offer.AmountobjectorstringAMOUNTIndicates the amount expected or offered for the
NFToken. If the token has thelsfOnlyXRPflag set, the amount MUST be specified in XRP.Sell offers that specify assets other than XRP must specify a non-zero amount. Sell offers which specify XRP can be 'free' (i.e., the
Amountfield may be equal to"0").ExpirationnumberUINT32Indicates the time after which the offer is no longer active. The value is the number of seconds since the Ripple Epoch.
DestinationstringAccount IDOnly allowed if the
lsfSellTokenflag is set. Indicates theAccountIDthat this sell offer is intended for (either a buyer or a broker). If present, only that account can accept the sell offer.OwnerNodestringUINT64Internal bookkeeping, indicating the page inside the owner directory where this token is being tracked. This field allows of the efficient deletion of offers.
NFTokenOfferNodestringUINT64Internal bookkeeping, indicating the page inside the token buy or sell offer directory, as appropriate, where this token is being tracked. This field allows of the efficient deletion of offers.
1.5. How does
NFTokenOfferwork?Unlike regular offers on XRPL, which are stored sorted by quality in an order book and are automatically matched by an on-ledger mechanism, an
NFTokenOfferis not stored in an order book and will never be automatically matched or executed.A buyer must explicitly choose to accept an
NFTokenOfferthat offers to buy anNFToken. Similarly, a seller must explicitly choose to accept a specificNFTokenOfferthat offers to buy anNFTokenobject that they own.1.5.1. Locating
NFTokenOfferobjectsEach token has two directories, one containing offers to buy the token and the other containing offers to sell the token. This makes it easy to find
NFTokenOfferfor a particular token. It is expected that off-ledger systems will be used to retrieve, present, communicate and effectuate the creation, enumeration, acceptance or cancellation of offers. For example, a marketplace may offer intuitive web- or app-based interfaces for users.1.5.2.
NFTokenOfferReserveEach
NFTokenOfferobject costs the account placing the offer one incremental reserve. As of this writing the incremental reserve is 2 XRP. The reserve can be recovered by cancelling the offer. The reserve is also recovered if the offer is accepted, which removes the offer from the XRP Ledger.1.5.3.
NFTokenOfferTransactionsThere are three defined transactions:
NFTokenCreateOfferNFTokenCancelOfferNFTokenOfferAcceptAll three transactions have the generic set of transaction fields, some of which may be ommitted from this proposal for the sake of clarity.
1.5.4.
NFTokenCreateOffertransactionThe
NFTokenCreateOffertransaction creates either a newSelloffer for anNFTokenowned by the account executing the transaction or a newBuyoffer forNFTokenowned by another account.Each offer costs one incremental reserve.
1.5.4.1. Fields
TransactionTypestringUINT16Indicates the new transaction type
NFTokenCreateOffer. The integer identifier is27.AccountstringAccountIDIndicates the
AccountIDof the account that initiated the transaction.OwnerstringAccountIDIndicates the
AccountIDof the account that owns the correspondingNFToken.Account(since an offer to buy a token one already holds is meaningless).Account(since an offer to sell a token one doesn't already hold is meaningless).FlagsnumberUINT32A set of flags that specifies options or controls the behavior of the transaction. This proposal only defines one flag at this time:
Note that the
Flagsfield includes both transaction-specific and generic flags. This proposal only specifies the transaction-specific flags; all currently valid generics flags (e.g.,tfFullyCanonicalSig) are applicable, but not listed here.The transactor SHOULD NOT allow unknown flags to be set.
NFTokenIDstringHash256Identifies the
NFTokenIDof theNFTokenobject that the offer references.AmountCurrency AmountAMOUNTIndicates the amount expected or offered for the
Token.The amount must be non-zero, except where this is an offer is an offer to sell and the asset is XRP; then it is legal to specify an amount of zero, which means that the current owner of the token is giving it away, gratis, either to anyone at all, or to the account identified by the
Destinationfield.ExpirationnumberUINT32Indicates the time after which the offer will no longer be valid. The value is the number of seconds since the Ripple Epoch.
DestinationstringAccountIDOnly valid if the
tfSellTokenflag is set. If present, indicates that this offer may only be accepted by the specified account (either a broker or a buyer). Attempts by other accounts to accept this offer MUST fail.If succesful,
NFTokenCreateOffertransaction results in the creation ofNFTokenOfferobject.1.5.5.
NFTokenCancelOffertransactionThe
NFTokenCancelOffertransaction can be used to cancel existing token offers created usingNFTokenCreateOffer.1.5.5.1 Permissions
An existing offer, represented by an
NFTokenOfferobject, can be cancelled by:NFTokenOffer;Destinationfield of theNFTokenOffer, if one is present; orNFTokenOfferspecifies an expiration time and the close time of the parent ledger in which theNFTokenCancelOfferis included is greater than the expiration time.This transaction removes the listed
NFTokenOfferobject from the ledger, if present, and adjusts the reserve requirements accordingly. It is not an error if theNFTokenOffercannot be found, and the transaction should complete successfully if that is the case.Fields
TransactionTypestringUINT16Indicates the new transaction type
NFTokenCancelOffer. The integer identifier is28.NFTokenOffersarrayVECTOR256An array of ledger entry IDs, each identifying an
NFTokenOfferobject, which should be cancelled by this transaction.It is an error if an entry in this list points to an object that is not an
NFTokenOfferobject. It is not an error if an entry in this list points to an object that does not exist.1.5.6.
NFTokenOfferAccepttransactionThe
NFTokenOfferAccepttransaction is used to accept offers tobuyorsellanNFToken. It can either:directmode.NFTokenand the other offering to sell the sameNFToken, to be accepted in an atomic fashion. This is calledbrokeredmode.1.5.6.1. Brokered vs. Direct Mode
The mode in which the transaction operates depends on the presence of the
NFTokenSellOfferandNFTokenBuyOfferfields of the transaction:NFTokenSellOfferNFTokenBuyOfferIf neither of those fields is specified, the transaction is malformed and shall produce a
temclass error.The semantics of
brokeredmode are slightly different than one indirectmode: The account executing the transaction functions as a broker, bringing the two offers together and causing them to be matched but does not acquire ownership of the involved NFT, which will, if the transaction is successful, be transferred directly from the seller to the buyer.1.5.6.2. Execution Details
1.5.6.2.1. Direct Mode
In
directmode,NFTokenOfferAccepttransaction MUST fail if:NFTokenOfferagainst whichNFTokenOfferAccepttransaction is placed is an offer tobuythe
NFTokenand the account executing theNFTokenOfferAcceptis not, at the time of execution, the current owner of the correspondingNFToken.NFTokenOfferagainst whichNFTokenOfferAccepttransaction is placed is an offer tosellthe
NFTokenand was placed by an account which is not, at the time of execution, the current owner of theNFToken.NFTokenOfferagainst whichNFTokenOfferAccepttransaction is placed is an offer tosellthe
NFTokenand was placed by an account which is not, at the time of execution, theAccountin the recipient field of theNFTokenOffer, if there exist one.NFTokenOfferagainst whichNFTokenOfferAccepttransaction is placed specifies anexpirationtime and the close time field of the parent of the ledger in which the transactionwould be included has already passed.
NFTokenOfferagainst whichNFTokenOfferAccepttransaction is placed to buy or sell theNFTokenis owned by the account executing the
NFTokenOfferAccept.If the transaction is executed successfully then:
NFTtokenwill change ownership, meaning that the token will be removed from theNFTokenPageof the existingownerand be added to theNFTokenPageof the newowner.NFTokenOffer. If the correspondingNFTokenoffer specifies aTransferRate, then theissuerreceives the specified percentage, with the balance going to the seller of theNFToken.1.5.6.2.2. Brokered Mode
In
brokeredmode,NFTokenOfferAccepttransaction MUST fail if:buyNFTokenOfferagainst whichNFTokenOfferAccepttransaction is placed is owned by the account executing the transaction.sellNFTokenOfferagainst whichNFTokenOfferAccepttransaction is placed is owned by the account executing the transaction.NFTokenis not, at the time of execution the current owner of the correspondingNFToken.buyorsell) specifies anexpirationtime and the close time field of the parent of the ledger in which the transaction would be included has already passed.1.5.6.3. Fields
TransactionTypestringUINT16Indicates the new transaction type
NFTokenOfferAccept. The sequence number of a previousNFTokenCreateOffertransaction. The integer identifier is29.NFTokenSellOfferstringUINT256Identifies the
NFTokenOfferthat offers to sell theNFToken.📝 In direct mode this field is optional, but either
NFTokenSellOfferorNFTokenBuyOffermust be specified. In brokered mode, bothNFTokenSellOfferandNFTokenBuyOfferMUST be specified.NFTokenBuyOfferstringUINT256Identifies the
NFTokenOfferthat offers to buy theNFToken.📝 In direct mode this field is optional, but either
NFTokenSellOfferorNFTokenBuyOffermust be specified. In brokered mode, bothNFTokenSellOfferandNFTokenBuyOfferMUST be specified.NFTokenBrokerFeeobjectorstringAMOUNTThis field is only valid in brokered mode and specifies the amount that the broker will keep as part of their fee for bringing the two offers together; the remaining amount will be sent to the seller of the
NFTokenbeing bought. If specified, the fee must be such that, prior to accounting for the transfer fee charged by the issuer, the amount that the seller would receive is at least as much as the amount indicated in the sell offer.This functionality is intended to allow the
ownerof anNFTokento offer their token for sale to a third party broker, who may then attempt to sell theNFTokenon for a larger amount, without the broker having to own theNFTokenor custody funds.📝 If both offers are for the same asset, it is possible that the order in which funds are transferred might cause a transaction that would succeed to fail due to an apparent lack of funds. To ensure deterministic transaction execution and maximimize the chances of successful execution, this proposal requires that the account attempting to buy the
NFTokenis debited first and that funds due to the broker are credited before crediting the seller or issuer.:note: In brokered mode, The offers referenced by
NFTokenBuyOfferandNFTokenSellOffermust both specify the sameNFTokenID; that is, both must be for the sameNFToken.Beta Was this translation helpful? Give feedback.
All reactions