We know that SUDT is a minimal standard,and the relevant information about issuing SUDT, such as the initial total amount of issuance, token name, token identification, decimal number, and so on, is not globally on-chain consensus in the SUDT standard. In practice, different SUDTs may have different minimum divisible decimal places when exchanging tokens on DEXs, so we need a supplementary extension of SUDT information on the chain, i.e. SUDT Info, which only serves the purpose of declaring and displaying on the chain and making the sudt-related information readable.
SUDT Info Cell
A SUDT Info cell in specification looks like following:
data: decimals: uint8 tokenname：Laxxx symbol:LAX //totalSupply：100.00(optional) type: code_hash: sudt_info type script args: sudt type script hash lock: <user_defined>
- decimals: (uint8 type)the number of decimal digits used by the token, if decimals is 8 it means that the token can be divided to 0.00000001 at least.
- tokenname: name of token
- symbol: identifier of the token, such as “HIX”
- totalSupply: (Optional) the initial total amount of issuance
- Other: Support for custom field expansion
This operation enables issuing new SUDT/SUDT_Info.
// Issue new SUDT/SUDT_Info Inputs: <... one of the input cell must have owner lock script as lock> Outputs: SUDT_Cell: Data: amount: uint128 Type: code_hash: simple_udt type script args: owner lock script hash (...) Lock: <user defined> **SUDT_Info_Cell:** Data: decimals: uint8 tokenname： symbol: //totalSupply：(可选) Type: code_hash: sudt_info type script args: sudt type script hash Lock: <user defined>
The following rules should be met in a SUDT Info Cell(Type Script):
Rule 1: In constructing a transaction, the output must exist in a SUDT Cell ( SUDT ID ) that matches the type script_args parameter field.
Rule 2: extracts the type script_args field parameter of output this SUDT cell (i.e. owner lock script hash), at least one input cell uses the owner lock script specified by this SUDT.
Data storage format common standards: except (the first field) using uint8 type (1 byte), all using UTF-8 encoding, with a newline character “0x0a” to separate each field, of which the first three fields (the first three lines) are fixed default fields (in order for decimals, tokenname，symbol). The following fields (starting from the fourth line) are custom fields, using kv pair format to store “field name: value”.
Examples of data standards are as follows.
SUDT_Info Cell Data: //UTF-8: 6 //uint8 USD Coin USDC Totalsupply:10000000.000000 Official Site:<https://www.centre.io/> Description:XXXX ------------------------------------------ //Hex: 0x060a55534420436f696e0a555344430a546f74616c737570706c793a31303030303030302e3030303030300a4f66666963616c20536974653a68747470733a2f2f7777772e63656e7472652e696f2f0a4465736372697074696f6e3a78787878
About the uniqueness of the SUDT Info Cell
By looking at the SUDT specification , the uniqueness of sudt-type script hash(SUDT) inherits from the owner lock script hash, and the current sudt issuance of the owner lock script uses the default Lock (secp256k1_blake160), i.e. Based on the issuer’s publickey (Lock_args) being unique on chain, the sudt_info_type script inheriting from the sudt-type script hash is similarly unique.
And through the rules of the sudt_info_type script it is ensured that only the corresponding SUDT issuer can generate and modify the SUDT Info Cell.
But the sudt issuer can still issue multiple SUDT_ Info Cells with different data contents:
Currently, the default ckb lock is used as the owner lock script for issuing sudt, and the issuer can issue as many sudt as they want without any rule restriction, so the prerequisite for trusting this type of sudt is to believe that the issuer is self-disciplined. Therefore, it is not necessary for the issuer to issue multiple sudt info cells with different information.