💬 This week I’m highlighting an older discussion that’s picking up steam again — a draft SEP for user-friendly asset addresses.
On Stellar, assets issued by a specific entity can be tricky to find and reason about within applications. For example: If you wanted to find NGNT issued by Cowrie, you’d have to know that their issuing address is: GAWODAROMJ33V5YDFY3NPYTHVYQG7MJXVJ2ND3AOGIHYRWINES6ACCPD. If you wanted to get data from Horizon about this asset/issuer, you’d have to send a GET request to: https://horizon.stellar.org/assets?asset_code=NGNT&asset_issuer=GAWODAROMJ33V5YDFY3NPYTHVYQG7MJXVJ2ND3AOGIHYRWINES6ACCPD. Then you’d use the response to provide information about the asset and the issuer (via the account’s home domain) to users.
Ultimately, this proposal wants to define a common format to define user-friendly asset addresses that resolve to the issuer address — similar to federated addresses! So instead of searching for NGNT issued by GAWODAROMJ33V5YDFY3NPYTHVYQG7MJXVJ2ND3AOGIHYRWINES6ACCPD; I can search for NGNT issued by cowrie.exchange — much better!
Taken from the Abstract of the SEP:
This proposal defines a format for specifying memorable addresses that contains a domain (e.g. `example.org`) instead of a Stellar address for the issuing account. The domain hosts a `stellar.toml` containing information about the asset which is already a common practice of asset issuers. A client parses the `stellar.toml` of the domain in the asset address and retrieves from the file the issuer address for the asset.
Reverse verification of an asset issuer address and domain can be performed by comparing the home domain of the issuer address with the issuer address in the domains `stellar.toml` file to confirm that the domain and issuer both claim to issue the asset.
👉 If this is a solution that interests you, don’t hesitate to hop in to the discussion here!
