SRC-20; Token Standard

[bitzoic]

Abstract

The following standard allows for the implementation of a standard API for Native Assets using the Sway Language. This standard provides basic functionality as well as on-chain metadata for other applications to use.

Motivation

A standard interface for Native Assets on Fuel allows external applications to interact with the token, whether that be decentralized exchanges, wallets, or Fuel's Scripts and Predicates.

Prior Art

The SRC-20 Fungible Token Standard naming pays homage to the ERC-20 Token Standard seen on Ethereum. While there is functionality we may use as reference, it is noted that Fuel's Native Assets are fundamentally different than Ethereum's tokens.

There has been a discussion of the Fungile Token Standard on the Fuel Forum. This discussion can be found here.

There has also been a Fungible Token Standard and Non-Fungible Token Standard implementations added to the Sway-Libs repository before the creation of the Sway-Standards repository. The introduction of this standard in the Sway-Standards repository will deprecate the Sway-Libs Fungible Token Standard.

Specification

Required Public Functions

The following functions MUST be implemented to follow the SRC-20 standard:

fn name(asset: AssetId) -> String

Returns the name of the asset, such as “Ether”.

fn total_supply(asset: b256) -> u64

Returns the total supply of tokens that have been minted for an asset.

fn total_assets() -> u64

Returns the total number of assets that have been minted for this contract.

fn decimals(asset: AssetId) -> u8

Returns the number of decimals the asset uses - e.g. 8, means to divide the token amount by 100000000 to get its user representation.

fn symbol(asset: AssetId) -> String

Returns the symbol of the asset, such as “ETH”.

Non-Fungible Token Restrictions

Non-Fungible Tokens(NFT) on Fuel are Native Assets and thus follow the same standard as Fungible Tokens with applied restrictions. For a Native Asset on Fuel to be deemed an NFT, the following must be applied:

• Non-Fungible Tokens SHALL have a total supply of one per asset.
• Non-Fungible Tokens SHALL have a decimal of 0u8.

Rationale

As the SRC-20 Token Standard leverages Native Assets on Fuel, we do not require the implementation of certain functions such as transfer or approval. This is done directly within the FuelVM and there is no smart contract that requires updating of balances. As Fuel is UTXO based, any transfer events may be indexed on transaction receipts.

Following this, we have omitted the inclusion of any transfer functions or events. The provided specification outlines only the required functions and events to implement fully functional tokens on the Fuel Network. Additional functionality and properties may be added as needed.

Backwards Compatibility

This standard is compatible with Fuel's Native Assets. There are no other standards that require compatibility.

Security Considerations

This standard does not introduce any security concerns, as it does not call external contracts, nor does it define any mutations of the contract state.

Example ABI

abi MyToken {
    #[storage(read)]
    fn total_supply(asset: b256) -> u64;
    #[storage(read)]
    fn total_assets() -> u64;
    #[storage(read)]
    fn decimals(asset: b256) -> u8;
    #[storage(read)]
    fn name(asset: b256) -> String;
    #[storage(read)]
    fn symbol(asset: b256) -> String;
}

This draft standard is to be released as v0.1.

[mpoplavkov]

Does it make sense to add a function for getting token metadata as an extension of the standard? One of the fields in the metadata might be token icon, for example. This might be helpful for dapps and wallets to properly display arbitrary tokens

[chlenc]

Hi guys I can suggest this token standard

configurable {
    DECIMALS: u8 = 9,
    NAME: b256 = str[32],
    SYMBOL: b256 = str[8],
    OWNER = Address::from(ZERO_B256),
    MINT_AMOUNT: 64 = 0, 
}

storage {
    minted: StorageMap<Address, bool> = StorageMap {},
    admins: StorageMap<Address, bool> = StorageMap {}, // for testnet only
}

abi FRC20 {
    #[storage(read)]
    fn total_supply() -> U256;
    fn decimals() -> u8;
    fn name() -> str[64];
    fn symbol() -> str[32];

    fn mint_amount() -> u64; // everyone can mint mint_amount only one time
    fn is_minted(address: Address) -> bool;

    fn is_admin(address: Address) -> bool; // only admins can call fn _...

    fn _transfer(coins: u64, address: Address); //transfer coins from contract address

    #[storage(read, write)]
    fn mint();
    fn _delete_admin(address: Address);
    fn _add_admin(address: Address);
    fn _burn_coins(burn_amount: u64);
    fn _mint(amount: u64, recipient: Address);
   
}

[mpoplavkov]

Hey @chlenc, is it possible to use dynamic length strings instead of str[]? Also, I think that we need to have a mainnet ready standard without any testnet related functions (like administration, one-time minting etc). All features designed for testnet only might be added as a separate extension for the standard. There is an example of extensions in the nft standard.

[chlenc]

Hey @chlenc, is it possible to use dynamic length strings instead of str[]? Also, I think that we need to have a mainnet ready standard without any testnet related functions (like administration, one-time minting etc). All features designed for testnet only might be added as a separate extension for the standard. There is an example of extensions in the nft standard.

1. maybe it’s possible, we should try
2. every mainnet project will be created through testnet, I guess we will think about mainnet token standard a bit later
   Btw to make mainnet standard we need just delete a few lines and also I'm sure we need mint functional (maybe a bit reengineered) in mainnet

[SwayStar123]

Is there any reason for the methods other than total_supply to be #[storage(read)]? All of them can be pure functions

[bitzoic]

Is there any reason for the methods other than total_supply to be #[storage(read)]? All of them can be pure functions

name() and symbol() are returning Strings which works with the StorageString type. Once conversions between str and String are introduced, then these could be removed.

[chlenc]

@bitzoic Please look at this code

https://github.com/compolabs/src-20/blob/master/contarct/src/main.sw

[bitzoic]

Please note that the standard has been updated to reflect the changes to the VM and the introduction of multi-token contracts.

[chlenc]

Please note that the standard has been updated to reflect the changes to the VM and the introduction of multi-token contracts.

?

[chlenc]

Please note that the standard has been updated to reflect the changes to the VM and the introduction of multi-token contracts.

So, to launch a new version of swaylend we need a token standard, please can you help me to figure out what can I do to make the process faster?

[bitzoic]

Please note that the standard has been updated to reflect the changes to the VM and the introduction of multi-token contracts.

?

Relevant issues are FuelLabs/fuel-specs#491 and FuelLabs/sway#4644