-
Notifications
You must be signed in to change notification settings - Fork 23
KIP-0031: Fungible token Metadata #63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,107 @@ | ||||||
| --- | ||||||
| KIP: "0031" | ||||||
| Title: fungible-meta-v1 | ||||||
| Author: CryptoPascal | ||||||
| Status: Early Draft | ||||||
| Type: Standard | ||||||
| Category: Chainweb / Fungible | ||||||
| Created: 2024-09-28 | ||||||
| --- | ||||||
|
|
||||||
| ## Abstract | ||||||
|
|
||||||
| Define and implement a new way for tokens creators to export their Meta-Data to Wallets, Frontends, and Other services. | ||||||
| While this is currently handled off-chain, this proposal is intended to take a an "on-chain" approach. | ||||||
|
|
||||||
|
|
||||||
| ## Rationale | ||||||
|
|
||||||
| While `fungible-v2` provides technical functions to allow "technical on-chain" interoperability between tokens, meta-data and information about fungible tokens are missing. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
|
||||||
| Currently, listing tokens for Wallet, Frontends, Exchanges, and other third parties is a cumbersome process. Maintainers have to manually contact tokens issuers to retrieve logos, names, and other useful information to display to users. This ends up with disparities between different wallets or frontends. Users complain that they don't have reliable information about their investment. | ||||||
|
|
||||||
| Moreover, token issuers have no clean and defined way to inform wallets when some changes happen with their token (Rebrand, new issuance, ...) | ||||||
|
|
||||||
| And finally, since Kadena is multichains, wallets need to be informed on how to use the token, regarding chains deployment: | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
| - Some tokens may not be available on all chains. | ||||||
| - Some tokens may have a single issuance chain where supply is accounted | ||||||
|
|
||||||
| The proposal is **to create an optional interface that can be implemented by token modules** to automatically inform third parties about their meta-data, and displayable information to users. Wallets, frontends, ... are expected to make local calls to the `kip.fungible-meta` implemented functions. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
|
||||||
| #### Trustability | ||||||
|
|
||||||
| Information (especially supply) relies **only** on token issuers and module writers good faith. Clients should not blindly trust them. Sorting legitimate tokens from illegitimate ones is not in the scope of this KIP. | ||||||
|
|
||||||
| #### Non-Obligability | ||||||
| For being compliant with this KIP, token issuers have no obligation to provide all data. | ||||||
| And clients (Wallets, Frontends), have no obligation to show everything. | ||||||
|
|
||||||
| #### Supply considerations | ||||||
|
|
||||||
| One important piece of information required by investors is the total and circulating supply. | ||||||
| Kadena being multichain, when dynamic minting/burning tokens are considered, a new issue arises: | ||||||
| - Usually, minting / burning / emission happens on a single chain. | ||||||
| - **But other chains are not aware**: they just receive X-chain transfers. | ||||||
|
|
||||||
| As a consequence, it's highly probable that supply information won't be accurate on most chains. That's why this KIP proposes the concept of **main-chain** => The module itself informs the client where an accurate value of supply amounts can be found. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Supply will be accurate on individual chains if there as a chain-level supply noted in the interface for a token's metadata, just not a "total supply" across all the network. I think here, we need to separate the idea of what is autonomous metadata, as in facts that a ledger can keep about itself, vs dependent metadata - facts that require some kind of oracle to contribute. A main chain being an example of this oracle, but not the only valid kind out there. |
||||||
|
|
||||||
|
|
||||||
| ### API | ||||||
|
|
||||||
| The interface `kip.fungible-meta`, which should be implemented by token modules, provides the following functions. | ||||||
|
|
||||||
| ##### (general-info) | ||||||
| -> *object:{kip.fungible-meta.info-schema}* | ||||||
|
|
||||||
| Return general information about a token: | ||||||
| - `symbol` *string*: Token Ticker symbol. Usually a short name in uppercase. | ||||||
| - `name` *string*: Token name. Usually a relative short name composed of 1 or 2 words. | ||||||
| - `description` *string*: Longer description of the token. Not mandatory | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. proposing a maxchar cap on this to avoid spamability |
||||||
| - `img` *string* : URL of the graphical representation of the token. Not mandatory | ||||||
| - `logo` *string* : URL of a small (res max of 192x192) graphical representation of the token. Not mandatory. Can be the same as `img` | ||||||
| - `color` *string*: A CSSv4 compatible color (https://www.w3.org/TR/css-color-4/#typedef-color). Not mandatory. Can be used by wallets or frontends for some graphical displays (charts ...) | ||||||
| - `socials` *[object:{kip.fungible-social-schema}]*: A list of tuples (`type` *string*, `url` *string*). The list of allowed types (non limitative): "discord", "twitter", "website", "telegram", "reddit", "github" | ||||||
|
|
||||||
| **Note:** All optional fields must use an empty string if the information is not provided. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. which ones are optional? Is this the same as "not mandatory"? Why are |
||||||
|
|
||||||
| ##### (main-chain) | ||||||
| -> *string* | ||||||
|
|
||||||
| Return the main chain (if any) of the token. Usually, it's the issuance chain. This chain is expected to have the most reliable information about total and circulating supply. All compliant wallets should request this chain before displaying supply information to the user. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now, considering what I wrote above, is this something that implementors are expected to update with market data on a day to day? What's the good faith expectation here? |
||||||
|
|
||||||
| ##### (supported-chains) | ||||||
| -> *[string]* | ||||||
|
|
||||||
| Return the list of chains supported by the token. This is important for wallets, for retrieving balances, and correctly managing available X-chain transfers. | ||||||
|
|
||||||
|
|
||||||
| ##### (total-supply) | ||||||
| -> *decimal* | ||||||
|
|
||||||
| Return the total Supply of the token. If unknown 0.0 can be returned. | ||||||
|
|
||||||
| ##### (circulating-supply) | ||||||
| -> *decimal* | ||||||
|
|
||||||
| Return the total circulating supply. If unknown, 0.0 can be returned. This information might be relevant only on the main chain. | ||||||
|
|
||||||
| **Important note:** All those functions implementations must be "Read-Only pure". They are not allowed to write data or have any side effects. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that the level of relevance here is why i'm advocating not having |
||||||
|
|
||||||
|
|
||||||
| ## Backwards Compatibility | ||||||
|
|
||||||
| Since this interface may be implemented in addition to `fungible-v2`, "non compliant" tokens will continue to work as usual. | ||||||
| Hence, no backward compatibility issues are expected. | ||||||
|
|
||||||
|
|
||||||
| ## Specification | ||||||
|
|
||||||
| See [fungible-meta-v1.pact](kip-0031/fungible-meta-v1.pact) | ||||||
|
|
||||||
| ## Example | ||||||
|
|
||||||
| Implementation example: | ||||||
| See [example-token.pact](kip-0031/example-token.pact) | ||||||
|
|
||||||
| ## References | ||||||
| * KIP-0005: Fungible v2 | ||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,47 @@ | ||
| (load "fungible-meta-v1.pact") | ||
|
|
||
| (module bro-token G | ||
| (defcap G () | ||
| (enforce false "No")) | ||
|
|
||
| (implements kip.fungible-v2) | ||
| (implements kip.fungible-meta-v1) | ||
|
|
||
|
|
||
| (defconst _SUPPORTED_CHAINS ["0", "1", "2" ]) | ||
| (defconst _MAIN_CHAIN "2") | ||
|
|
||
| (defun general-info:object{info-schema} () | ||
| {'symbol: "BRO", | ||
| 'name: "$BRO", | ||
| 'description: "Token of Kadena Brothers DAO", | ||
| 'img: "https://raw.githubusercontent.com/brothers-DAO/bro-token/refs/heads/main/graphic-assets/basic/BRO_3000_3000.png", | ||
| 'logo: "https://raw.githubusercontent.com/brothers-DAO/bro-token/refs/heads/main/graphic-assets/basic/BRO_192_192.png", | ||
| 'color: "#eec2a1", | ||
| 'socials:[{'type:"website", 'url:"https://bro.pink"}, | ||
| {'type:"github", 'url:"https://github.com/brothers-DAO"}]} | ||
| ) | ||
|
|
||
| (defun main-chain:string () | ||
| _MAIN_CHAIN) | ||
|
|
||
| (defun supported-chains:[string] () | ||
| _SUPPORTED_CHAINS) | ||
|
|
||
| (defun total-supply:decimal () | ||
| 100.0) | ||
|
|
||
| (defun circulating-supply:decimal () | ||
| (if (= _MAIN_CHAIN (at 'chain-id (chain-data))) | ||
| (- (total-supply) (get-balance "issuance-account")) | ||
| 0.0) | ||
| ) | ||
|
|
||
| ; Usual fungible-v2 functions ===> | ||
|
|
||
| ; ... | ||
|
|
||
| ; ... | ||
|
|
||
| ; .... | ||
| ) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,34 @@ | ||
| (interface fungible-meta-v1 | ||
| @doc "Provides several meta-data informations for the token" | ||
|
|
||
| (defschema social-schema | ||
| type:string | ||
| url:string | ||
| ) | ||
|
|
||
| (defschema info-schema | ||
| symbol:string | ||
| name:string | ||
| description:string | ||
| img:string | ||
| logo:string | ||
| color:string | ||
| socials:[object{social-schema}] | ||
| ) | ||
|
|
||
| (defun general-info:object{info-schema} () | ||
| @doc "Return general information about a token") | ||
|
|
||
| (defun main-chain:string () | ||
| @doc "Return the main chain (if any) of the token") | ||
|
|
||
| (defun supported-chains:[string] () | ||
| @doc "Return the list of chains supported by the token") | ||
|
|
||
| (defun total-supply:decimal () | ||
| @doc "Return the total supply of the token") | ||
|
|
||
| (defun circulating-supply:decimal () | ||
| @doc "Returns the circulating supply of the token") | ||
|
|
||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.