0019 XLS-19d (DEPRECATED) Wallet based Proof of Digital Asset Property and Rights (NFT)

[calvincs]

DEPRECATION NOTICE

This proposal is DEPRECATED and should not be used. It served as a proof of concept. XLS 20 should be used instead.

---

A pseudo Non-Fungible "Token" or otherwise described below as a "Proof of Digital Asset Property and Rights" object on the XRP Ledger.

Many are familiar with NFTs, a type of cryptographic token representing a unique, non-divisible asset, having a defined limit on their verifiable availability via a given blockchain.

The definition and application of NFTs have been well discussed here for XRP as reference: (#30)

However, we would like to add a standard for possible consideration with unique properties from the standards thus far discussed why having an XRP wallet server as a pseudo Non-Fungible "token" may have significant value as well.

Let us refer to this pseudo Non-Fungible "token" as a pseudo token for brevity in the remainder of this document, where the pseudo token implies an XRP wallet-based NFT.

Advantages

• A pseudo token can utilize multisign ownership, giving multiple organizations or people control of the digital asset(s).

• A pseudo token can be dissolved once it has served its purpose, reducing the cost of minting said tokens.

• A pseudo token can take advantage of ILP and micropayments directly.

• A pseudo token can interact with any assets issued on the ledger, both receiving and sending.

• A pseudo token can issue tokens on the ledger.

• A pseudo token can use the messageKey feature to sign and cryptographically prove additional metadata or clauses associated with the original attached works, granted by the owner(s).

• A pseudo token is easily transferred by updating the regular key.

• A pseudo token does not require full history nodes to exist in order to preserve metadata / the pointer.

• A pseudo token does not add additional digital assets to the ledger for tracking.

• A pseudo token does not require a user to opt-in to receive the asset, nor does it require the use of a TrustSet.

• A pseudo token can be created today without any amendments to the ledger, or tooling.

Implementation

To issue a pseudo token, the digital objects and the metadata bundled within those must contain a link back to the pseudo token address they are attached to, in this case, the XRP wallet address.

It is advantageous for the various objects in the bundle to contain watermarks or updated metadata containing the XRP Wallet address.

The pseudo token, the XRP ledger Wallet, must also refer back to the digital objects. To accomplish this, we compute the hashes for the content bundle we want to publish with the pre-determined XRP wallet address contained within.

We then determine the off-chain storage mechanisms we wish to use to access or otherwise validate ownership of said digital property, our pointers.

In this example, lets use IPFS, Torrent, and a web URL:

  @iso:debian-10.8.0-amd64-netinst
  btih:4090c3c2a394a49974dfbbf2ce7ad0db3cdeddd7
  ipfs:QmS5cuAL9wCbphUFXDKsoE6qkvPV6hfbdaxVuMgJG7T5YB
  http:cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.8.0-amd64-netinst.iso

184 of 256 available bytes used

Where [service]:[resource] is provided in the Domain field of the Wallet
The url could be made shorter by the issuer to allow for additional pointers.
(Proposal: #44 )

The hashes of the pointers for IPFS and the Torrent services can serve to validate local, offline copies of the files by any given software if desired.
Or a sha256 hash could be used alone for offline storage.

@iso:debian-10.8.0-amd64-netinst
 sha256:396553f005ad9f86a51e246b1540c60cef676f9c71b95e22b753faef59f89bee

This data is then added to the Domain field of the pseudo token via an AccountSet, and must be no more than 256 bytes.

Once the Domain field is set, the pseudo Wallet is valid. The Wallet and the digital content both reference each other, providing proof of ownership on the XRP ledger. This also establishes the time in which the ownership between the Wallet and digital content was established.

Disadvantages

• A pseudo token does require 20 XRP to open and additional fees to set the domain field. This could make it cost-prohibitive in some cases for the initial issuance of pseudo tokens.

• A pseudo token cannot be traded on the existing XRP dex.

• A pseudo token can have its domain field updated by a given owner. This could be a pro or con, depending on the desired functionality. Ideally, an amendment would allow for a new specific blob field that cannot be updated once set, but that is another proposal.

Example proof of concept, work in progress.

• Here: https://github.com/calvincs/xrpl-nft-creator
• Video: https://www.twitch.tv/videos/960265121

[nixer89]

Hey Calvin, I really like the idea of having an Account as "NFT". It opens up more possibilities and, as you said, a big "+" would be no FullHistory, TrustLine, ....

2 points:

"A sudo token can have its domain field updated by a given owner. This could be a pro or con, depending on the desired functionality. Ideally, an amendment would allow for a new specific blob field that cannot be updated once set, but that is another proposal."

-> If I buy something like art, and hang it to my wall, I am free to destroy that art at any time because I am the owner. I think same applies (and should apply?) to NFTs. Whether it's by changing the domain field or even deleting the account?
Same problem faces the other proposal of NFTs (with issued token(s) on the XRPL): one could just sent back the token to the issuer and therefore destroy it.

"A sudo token cannot be traded on the existing XRP dex."

-> I just had this crazy idea where the owner of a sudo token (account) creates an actual token on the XRP Ledger. Next he creates an offer for this token on the XRPL Dex for the price he wants to sell his sudo token (account). If someone is willing to buy the sudo token, he has to accept the offer on the XRPL Dex. A Hook at the sudo token listens on the account if someone has accepted the offer.
If the offer was accepted it sets the regular key to the account which accepted the offer (and therefore bought the NFT account).

I am not sure if Hooks are allowed to change such settings as the RegularKey of an account. But if so, you could even trade Accounts on the XRPL Dex :) @RichardAH ?

Edit: Just had a convo in the MM Hook room and yes, Hooks can do that (execute SetRegularKey transactions based on some conditions). So you could indeed trade an XRPL account on the XRPL Dex :)

Best,
Daniel

[calvincs]

That's fantastic, I would love to see hooks enable that ability! Thanks for looking into that :-)

[mDuo13]

For what it's worth, I think this is a really good approach: very powerful and flexible, and solves many of the problems with NFTs without needing changes to the XRPL protocol nor

The only major drawback is the reserve cost, but I think it's worth it since an on-ledger account can store so much more data.

[francisrosario]

These are some projects that utilize @calvincs XLS-19d...
Standalone NFT Wallet Based Creator: intelliot/xrpl-ideas#18
NFT Wallet Based Indexer: intelliot/xrpl-ideas#15
NFT Marketplace (WIP): intelliot/xrpl-ideas#17