0010 XLS-10d: Non-Transferable Token (NTT) standard

[RichardAH]

An updated version of this spec can be found here: XLS-8: Tickets.

The earlier version can be found by looking at the edit history.

[JoelKatz]

Anyone who has had an Ethereum account for a long time knows that you accumulate a large amount of garbage from people trying to attract your attention or scam you. The 5 XRP reserve doesn't really prevent this because the reserve can be recovered by removing the token so in effect it really only costs you two transaction fees, 20 drops.

I'd have no objection to this if you had to do something to indicate that you were willing to accept the non-fungible token. But a trust line is too heavy to use just to mark an account for an arbitrary purpose.

It's also not really accurate to call this a non-fungible token standard because a non-fungible token would be expected to be transferable by its owner. I'm not quite sure I fully understand what problem it's expected to solve, but with a better understanding, I could perhaps suggest some ways to address these issues.

[RichardAH]

Hi David
Thanks for the reply

I'd have no objection to this if you had to do something to indicate that you were willing to accept the non-fungible token. But a trust line is too heavy to use just to mark an account for an arbitrary purpose.

I think it's up to wallets how they want to handle spam. Points 6 and 7 propose a whitelist feature that could be pretty tight. Explicitly opting-in the user makes an extra step for the user they may not want to take. That is similar to having to create a trustline first, and sort of defeats some of the benefits of these tokens.

It's also not really accurate to call this a non-fungible token standard because a non-fungible token would be expected to be transferable by its owner. I'm not quite sure I fully understand what problem it's expected to solve, but with a better understanding, I could perhaps suggest some ways to address these issues.

Our intention is that a smart contract controls the issuing account (via multi-sig). In most, but not all cases, that contract would expose some manipulation mechanics for the tokens including the ability to transfer or destroy them.

Effectively these tokens represent:

1. Some small piece of important per-account data
2. That strongly benefits from being public record, distributedly stored, and auditable
3. That multiple contracts and parties can see and somehow interact with

I realise this is fairly broad so I'll provide a few examples of specific use-cases:

1. Account tagging:
   E.g. Identity token (Something we're currently working on.) Notary X issuer certifies that you user are unique person #XYZ according to a standardised short input hashing of your name, dob, place of birth, and birth certificate number. This provides anti-sybil mechanism. (In addition would include a pointer on how to retrieve your stored identity documents.)
2. Hidden but verifiable data:
   E.g. Privacy coin. A smart contract running on 8 codius/hotpocket nodes controls the issuer account through multi-sig (one key per node). According to its programming it can assign or remove coins from your account by modifying your token. I won't get into specifically how this could work (probably using ZKP and trap door functions) but assume for the sake of argument it would. If the contract nodes disappear someone else can spin it up again under a new issuer account and provide an import mechanism for the old contract's coins. Thus the hidden data being public provides continuity.
3. Other public data:
   E.g. Persistent inter-game state. Suppose we play some game like d&d regularly. We invite smart contract X issuer to watch or umpire that the game was played correctly. Our progress is recorded publicly. Any other game can read our token and use our character state in their own games, then those too could be played back to the smart contract and allowed to update token state.

There are thousands of other use cases. Essentially combined with codius/hp smart contracts this enables some Ethereum-like behaviour on XRPL.

[RichardAH]

If it's of any interest to anyone here I'm currently building out a node library for processing XLS-10 tokens: https://github.com/codetsunami/libxls10

[amalagaura]

Won't the non-fungible token only need extra metadata space to allow the uniqueness of a transferred asset?

The current standard only allows a currency code. So is the addition of extra optional data enough to create a non-fungible asset?

[RichardAH]

Changed the title of the standard to just 'issuer controlled XRPL token standard' as not to confuse with xls-14[d]

[intelliot]

Consider renaming this spec to Non-Transferable Tokens (NTTs) which is a name that has gained some traction in other contexts.

[fersmi]

The idea for a Non-Transferable Token seems good to me. I can imagine that institutions, schools will issue certificates or diplomas to XRPL. Or I can imagine a certificate that I was vaccinated against covid. But I agree with David, that good spam protection is needed.

[mvadari]

@RichardAH should this spec be moved into PR and kept in the repo or should it be closed? Note that this does not mean that the spec has been accepted/implemented/finalized.

I will move it to PR by copy-pasting the existing draft if there is no response in the next week.