XRPLF
XLS-35d: URITokens — Lightweight first-class NFTs
URITokens are Non-Fungible Tokens (NFTs) that exist as first-class on-ledger objects. They are uniquely identified by the hash of their issuer and Uniform Resource Identifier (URI), and can point to any digital content. Only one object per URI per account can exist on the ledger. The Issuer can set a flag to enable burning of the object in the future. Each owner's reserve is locked up as well upon ownership of the URIToken. They include the transaction types; mint, burn, buy, create sell offer, and cancel sell offer. Additionally, when minting a URIToken, users can choose whether or not to include a SHA-512 Half hash of the URI's contents to ensure data integrity.
See the spec (in Files changed) for full details.
Proposed implementation: https://github.com/XRPLF/rippled/pull/4456
Could you write a one-paragraph explanation of what URITokens are, from first principles, without mentioning XLS-20?
Could you write a one-paragraph explanation of what URITokens are, from first principles, without mentioning XLS-20?
URITokens are Non-Fungible Tokens (NFTs) that exist as first-class on-ledger objects. They are uniquely identified by the hash of their issuer and Uniform Resource Identifier (URI), and can point to any digital content. Only one object per URI per account can exist on the ledger. The Issuer can set a flag to enable burning of the object in the future. Each owner's reserve is locked up as well upon ownership of the URIToken. They include the transaction types; mint, burn, buy, create sell offer, and cancel sell offer. Additionally, when minting a URIToken, users can choose whether or not to include a SHA-512 Half hash of the URI's contents to ensure data integrity.
Only one object per account can exist on the ledger.
I think you mean "Only one object per URI per account can exist on the ledger." ?
Additionally, when minting a URIToken, users can choose whether or not to include a SHA-512 Half hash of the URI's contents to ensure data integrity.
Aside from "data integrity", does this also make the JSON document immutable?
Only one object per account can exist on the ledger.
I think you mean "Only one object per URI per account can exist on the ledger." ?
Additionally, when minting a URIToken, users can choose whether or not to include a SHA-512 Half hash of the URI's contents to ensure data integrity.
Aside from "data integrity", does this also make the JSON document immutable?
It would essentially make the json immutable but only through a verification. If I used a URI that pointed to an IPNS then I could essentially change the json data, but then the digest check would be incorrect. So I don't know if saying "makes it immutable" is right.
Also, I updated the uri duplicate nomenclature.
I see. The explanation is helpful and looks good to me. I recommend adding it to the spec near the top in a section called "Abstract".
The Abstract is a summary of the contents of the spec. The Abstract is part of the recommended template.
What about being able to create an Offer at the same time during URITokenMint?
It would be possible to set the sfAmount and sfDestination when creating the URIToken object.
@dangell7 - feel free to review the comments/questions above, at your convenience
It looks like Amount and Destination fields are implemented in URITokenMint on Xahau.
https://docs.xahau.network/technical/protocol-reference/transactions/transaction-types/uritokenmint
If the reserves for ledger objects stay at 2 XRP per, this seems like it would be cost prohibitive.
If the reserves for ledger objects stay at 2 XRP per, this seems like it would be cost prohibitive.
As of 2 December 2024, the Mainnet "reserve_inc_xrp" has reduced to 0.2.
