0026 XLS-26: IOU Token Metadata via xrp-ledger.toml

[Mwni]

An updated version of this spec can be found here: XLS-26: IOU Token Metadata.

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

[mDuo13]

I support this extension. Some thoughts:

You've got a typo, [[CURRENCIS]]. It should be [[CURRENCIES]], of course.

You list code and issuer as "extensions" to the [[CURRENCIES]] array, but those fields are already part of the standard along with some other fields you didn't mention. I suggest only listing the actually new fields, to avoid confusion. Similar situation for [[ACCOUNTS]]. Also, note that not all accounts in [[ACCOUNTS]] are issuers, so the descriptions should not assume that. (I think the field definitions are generally fine though.)

In my opinion "airdrops" should not be a separate array but deadline_date and airdrop_date could be optional fields of entries in the [[CURRENCIES]] array. The description and links can reflect that the token has not yet been issued and provide information about the airdrop. Then you can update the token's entry in the toml file after the airdrop begins.

[Mwni]

Thank you for the feedback. I want to note, this proposal has since been outdated and a revision is on the way.

Regarding the redundant fields, these are indeed not extensions, but act as identifiers for the stanza, so I feel they should definitely be included. Perhaps with a better declaration of what they are. The issue with coupling airdrops with the currency stanza is that a token can have multiple airdrops.

I was considering introducing a new stanza called ISSUERS instead of using the existing accounts stanza, and your comment made clear that that's the way to go.

[gadget78]

do you have a link to this newer proposal ?

[gadget78]

if we are going to change this, lets make this into a MUCH more usefull data point and maximise the data held here...
i had very hard, and time consuming time finding some of what i see as basic info,
so this going to be heavily weighted on the info that i could never find easily, and people wanted..

ok so 1st of, we must already know their domain, as we would'nt be at this stage, and domain is taken from from the ledger account settings..

something that would be good to see in [[PRINCIPALS]] is country of origin....
i also propose we either have a new [[SOCIAL]] section ?
or have it officially under the [[PRINCIPALS]] which is where i have seen them already listed in some accounts ...

so for eg ..

[[SOCIAL]]
discord = "https://discord.gg/KTNmhJDXqa"
linktree = "https://linktr.ee/gadget78
instagram = ""
linkedin = ""
telegram = ""
ticktock = ""
twitter = "https://twitter.com/gadget78"
youtube = ""

i like the icon info in the [[TOKENS]] ✅
would also be good to have dedicated section for listing their "distrubution accounts"
which i know is normally the address that initially received to created tokens, but this isn't always as easy to find as you 1st think!
also how about we have dedicated fields for; whitepaper, roadmap, there business info, and XUMM xAPP links,
and also at a push how about a cex (centralised exchange links)

[[TOKENS]]
issuer = "rCSCManTZ8ME9EoLrSHHYKW8PPwWMgkwr"
currency = "CSC"
name = "CasinoCoin"
desc = "CasinoCoin (CSC) is a digital currency, developed specifically for the regulated gaming industry."
icon = "https://static.xrplmeta.org/icons/csc.png"
whitepaper = ""
roadmap = ""
registered_business = ""
xAPP = ""

also in the [[VALIDATORS]] does this include, standard node info ??

although to be honest, 99% of token creators dont even care about this stuff,
in the 240 odd tokens i have listed on gadget78.uk only 7 make use of this .toml file :(
in your example you used Casino Coin, they dont have one, nor does other big players like https://www.aesthetes.art

[Mwni]

I agree on the point of adding a way to link distribution or other associated accounts. The reason why I opted against creating hard keys for every possible web link, is because you can never cover everything. It's then even harder to adapt to new trends.
In your [[SOCIAL]], where is wechat, where is facebook, where is THE_NEXT_BIG_THING? Same goes for litepaper, github, audit_certificate in the tokens stanza? All of these things are just web links. Hence the [[WEBLINKS]] stanza.

[Mwni]

Oh, and on the point why this standard has found nearly no adoption so far: It hasn't been advertised, yet. There will be an announcement this week from Xumm, which will mark the official roll out of this standard and its accompanying project xrplmeta.org, so to say 🚀

[gadget78]

for additional social accounts you would just add in lower case .. so using your examples,

[[SOCIAL]]
wechat = ""
facebook = ""
zerpcraft = ""

do appreciate that they are just weblinks still, but having them categorized is nicer/neater ...
as yes they are still weblinks, but having dedicated categories, is better to maintain
and quicker to parse if all your interested in is social links etc ..

plus its more about having a pre-set standard of listing these items, with examples from the outset,
so that it gets used in a uniform way, from the beginning

so if we set out that the basic items like litepaper, and audit_certificate...
with it spelt out and shown that this is how the standard way WILL be...
as in no spaces, with underscores, with no dashes, whitepaper not litepaper, in the tokens section ...

the [[WEBLINKS]] can be stated as a useable section, and used going forward as a future proof method of adding other things that we dont see as "standard" now ...

if we dont state these things, we will be back at the same mess we have now, in not easily being able to gather this information uniformly.

[ledhed2222]

I like this proposal a lot! Can we move it to a PR?

[Mwni]

A PR to where?

[ledhed2222]

Into this repo. Check out the CONTRIBUTING.md and the other open pull requests here :)

[Mwni]

I will polish the standard and make a PR in the coming days.

[LIFTGEARBOY]

came across this and yes please...I’m a dev building my first XRPL project (LIFTGEAR / LFG) and learning as I go — honestly a lot of this still looks and sounds like hieroglyphics to me 😂 — but this proposal makes sense and would help small builders like me a lot.

Right now, trying to get a token listed everywhere (XPMarket, Xaman, Sologenic, Bithomp, etc) is super manual and confusing. Especially when you have to fix mistakes or reissue (like I just did). Having a standard TOML structure with clear fields — asset_class, icon, social, distribution accounts, etc — would make life so much easier for us smaller devs, and help users know what’s legit.

Our LFG token is a UTILITY token for the LIFTGEAR.FIT fitness ecosystem — I’d love to see this standard go through so all wallets and explorers can pull the same clean data. Great idea — please push this — and I’m happy to test or help however I can (still learning!).

my toml file

[[CURRENCIES]]
code = "LFG"
issuer = "rJ37aqt2NDZVvqnb8HLN1YC5BrsSBHbeBJ"
name = "LIFTGEAR"
desc = "LIFTGEAR is a fitness-driven token built on the XRPL. Unleash your potential, earn your gains."
url = "https://liftgear.fit"
image = "https://liftgear.fit/assets/LFGlogo.png"

[METADATA]
website = "https://liftgear.fit"
twitter = "https://x.com/LIFTGEARBOY"
THANKS GUYS KEEP DOING YALL THING!

[goldbrand77]

We need more required keys here in order to level-up quality of IOU meta data!

[Mwni]

What keys?

[goldbrand77]

[[ISSUERS]]

address * (like contact to connect for requests, that could be everything, a social account, email or something usefull)

[[TOKENS]]

icon * (should be required)
desc * (should be required)
name * (should be required)

Too many meme launch pads does not require an domain. That's the biggest issue at all. The best way would be a change on the ledger. NO IOU WITHOUT VALID DOMAIN! That would fix a lot of chaos in the future.

Also I would think on it to connect other issuer here. For Utility or liquidity information. like:

[[AMM]]

native * (should be required) the XRP/IOU 
          Issuer * (should be required)  
          currencyHex * (should be required) 
          status open/blackholed

[[NFT]]

    [0]
      collection
          Issuer  

    [1]
      collection
          Issuer