MLD-20: Fungible Tokens

MLD-20 is a token standard on the MELD Blockchain, directly mirroring the ERC-20, the most prevalent Ethereum token standard. It serves as a framework for tokens, outlining rules for their issuance, transfer, and handling. Given its replication of the ERC-20 standard, MLD-20 ensures compatibility with a wide range of existing Ethereum-based infrastructures and tools.

Originally designed for the MELD Blockchain, the MLD-20 standard offers developers a versatile template for introducing various types of tokens. These tokens can embody diverse assets, ranging from company shares to fiat-backed stablecoins.

Additionally, MLD-20 facilitates the creation of native assets or the bridging of tokens from other blockchain ecosystems, allowing them to operate seamlessly on the MELD Blockchain. This includes the possibility of creating MLD-20 versions of other cryptocurrencies, similar to the concept of "wrapped" tokens in other blockchains.

Like its counterparts in other blockchain networks, transactions involving MLD-20 tokens incur network fees. These fees are essential for compensating validators who process and record transactions on the blockchain.

The MELD Blockchain's integration of MLD-20 tokens is part of its broader strategy to support decentralized applications and interoperability with other blockchain systems. This approach aims to enhance the blockchain's utility without overburdening it, thereby maintaining efficient and rapid processing capabilities.

Emphasizing cross-chain interaction, the MELD Blockchain allows for seamless transitions between MLD-20 tokens and their equivalents on other networks. This interoperability is a key feature, offering users and developers expanded flexibility and reach.

To see all MLD-20 Tokens supported in the MELDapp, please visit https://tokens.meld.com/, select "Mainnet", and scroll down to the "Meld" section.

The following covers a complete list of events and methods associated with the MLD-20 standard, a mirror copy of the widely recognized ERC-20 token standard tailored for the MELD blockchain.

Methods

NOTES:

• The following specifications use syntax from Solidity 0.4.17 (or above)

• Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned!

name

Returns the name of the token - e.g. "MyToken".

OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

function name() public view returns (string) 

---

symbol

Returns the symbol of the token. E.g. “HIX”.

OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

function symbol() public view returns (string)

---

decimals

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

OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

function decimals() public view returns (uint8)

---

totalSupply

Returns the total token supply.

function totalSupply() public view returns (uint256)

---

balanceOf

Returns the account balance of another account with address _owner.

function balanceOf(address _owner) public view returns (uint256 balance)

---

transfer

Transfers _value amount of tokens to address _to, and MUST fire the Transfer event. The function SHOULD throw if the message caller’s account balance does not have enough tokens to spend.

Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

function transfersol(address _to, uint256 _value) public returns (bool success)

---

transferFrom

Transfers _value amount of tokens from address _from to address _to, and MUST fire the Transfer event.

The transferFrom method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies. The function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism.

Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)

---

approve

Allows _spender to withdraw from your account multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.

NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn’t enforce it, to allow backwards compatibility with contracts deployed before

function approve(address _spender, uint256 _value) public returns (bool success)

---

allowance

Returns the amount which _spender is still allowed to withdraw from _owner.

function allowance(address _owner, address _spender) public view returns (uint256 remaining)

---

Events

Transfer

MUST trigger when tokens are transferred, including zero value transfers.

A token contract which creates new tokens SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created.

event Transfer(address indexed _from, address indexed _to, uint256 _value)

---

Approval

MUST trigger on any successful call to approve(address _spender, uint256 _value).

event Approval(address indexed _owner, address indexed _spender, uint256 _value)