Skip to content

Latest commit

 

History

History
87 lines (61 loc) · 7.5 KB

eip-0004.md

File metadata and controls

87 lines (61 loc) · 7.5 KB
Raw

Assets standard

  • Author: catena2w,kushti,oskin1
  • Status: Proposed
  • Created: 07-Oct-2019
  • License: CC0
  • Forking: not needed

Motivation

This standard provides a uniform way to issue Ergo tokens. A standard interface allows any tokens on Ergo to be re-used by other applications: from wallets to decentralized exchanges.

Ergo tokens background

Ergo supports custom tokens as first-class citizens. Namely, a special register (R2) of a box contains (tokenId -> amount) pairs. A box can contain at most 255 of secondary tokens. However, there are also indirect limits: a box could be no more than 4 kilobytes, and also tokens add the computational cost of the transaction.

A transaction can create out-of-thin-air tokens in its outputs if the token identifier is equal to the identifier of the first input box of the transaction. As the box identifier is cryptographically unique, there's no chance to have the second token with the same identifier while the hash function being used is collision-resistant. This rule also means that only one new token per transaction can be created.

Unlike ergs, other tokens can be burnt: the total amount for a token in transaction inputs should be no less than the amount of the outputs. Storage rent component allows a miner to collect (or burn) all the tokens inside a box if it is expired, and there are not enough Ergs in the box to pay the storage rent fee.

Ergo tokens standard

Though this is not required by the protocol, we propose the following structure for the box that issues a token:

Register Description Example Encoded
R2 Token id and amount pair [("7d...09", 100000)]
R4 Token verbose name (UTF-8 representation) "USD" "0e03555344"
R5 Token description (UTF-8 representation) "Nothing backed USD token" "0e184e6f7468696e67206261636b65642055534420746f6b656e"
R6 Number of decimals "2" "0e0132"

Note, that additional registers (R4-R6) are encoded as Coll[Byte] type of ErgoScript and their encoded representation is received as '\x0e' + intToVlq(byteArray.length) + byteArray where byteArray is UTF-8 representation of the original string. The example above issues one thousand tokens called "USD" with two decimals each. The transaction that issues such a token was included in block 98288 and may be found in block explorer)

Ergo asset types

This standard is an extension of token standard:

In the asset type standard, R7 is a required two-byte value encoded as Coll[Byte]. The first byte represents the asset category, for example, NFT or Share Tokens. The second byte specifies the exact subcategory, for example, Picture Artwork NFT or ErgoMixer's Share Tokens. The second byte can be omited so that the issuance only specifies the catagory and not the subcatagory, for example, Share Tokens. Also, the remaining R8 and R9 registers can be used by each individual asset types based on their needs.

The standardization of various asset types can be found below:

Asset type R7 R8 R9
NFT - picture artwork [0x01, 0x01] - i.e., "0e020101" SHA256 hash of the picture Optional - link to the artwork (UTF-8 representation)
NFT - audio artwork [0x01, 0x02] - i.e., "0e020102" SHA256 hash of the audio Optional - link to the audio encoded as Coll[Byte] or (link to the audio, link to the image cover) encoded as (Coll[Byte], Coll[Byte]) (UTF-8 representation)
NFT - video artwork [0x01, 0x03] - i.e., "0e020103" SHA256 hash of the video Optional - link to the video (UTF-8 representation)
NFT - Artwork collection [0x01, 0x04] - i.e., "0e020104"
NFT - File Attachments [0x01, 0x0F] - i.e., "0e02010F" Collection of SHA256 hashes of the files encoded as Coll[Coll[Byte]] NFT File Attachment (see encoding below)
Membership token - threshold signature [0x02, 0x01] - i.e., "0e020201" Number of required signatures (Integer) - i.e., 4 in case of 4-of-10 threshold signature Deposit address of the funds controlled by the threshold signature (Ergo tree byte array)

The above registers (R7-R9) are also encoded as Coll[Byte] type unless stated otherwise.

NFT File Attachments

NFT File attachments can be used to attach any number of files of any file format to an Ergo token.

An NFT File Attachment should have a multi-attachment content type as per the EIP-29 Standard, with the following structure:

  • Attachment 0: contentType = 2 (plain text) - Comma seperated list of file formats of the attached files
  • Attachment 1: contentType = 2 (plain text) - Link to the first file (the sha256 hash of this file should be in index 0 of R8 and the file extension should be given as the first file extenstion in attachment 0)
  • Attachment 2 (Optional): contentType = 2 (plain text) - Link to the second file (the sha256 hash of this file should be in index 1 of R8 and the file extension should be given as the second file extenstion in attachment 0)
  • Attachment n (Optional): contentType = 2 (plain text) - Link to the nth file (the sha256 hash of this file should be in index n-1 of R8 and the file extension should be given as the nth file extenstion in attachment 0)

NFT File Attachment Example

Files to be attached:

File Format File Link File Hash
glb ipfs://link1 c5286e4a262c0a25e776124bfb09a961bfb6daf20b95fc201d2ac06b3134c199
png ipfs://link2 eb56a7800112669108ef13b1e8bd2c00e3941775f0b5a6dcb091606e649146f3
png ipfs://link3 39abad7b6e825b93d708b300434971fb62353441fd8690fa5596faa57a02cbf5

Registers (Rendered Values):

R7 R8 R9
0201FF [c5286e4a262c0a25e776124bfb09a961bfb6daf20b95fc201d2ac06b3134c199, bbfcfc944bffd3fe35cd94b44f5df2e96685baf27856a89fba29263b72469356, 39abad7b6e825b93d708b300434971fb62353441fd8690fa5596faa57a02cbf5] (505250, ( 1,[
(2,676C622C706E672C706E67),
(2, 697066733A2F2F6C696E6B31),
(2, 697066733A2F2F6C696E6B32),(2, 697066733A2F2F6C696E6B33)] )