Fungible Token Standard for Dune Network

Photo by Markus Spiskey

This blog post presents a Fungible Token Standard Origin Labs has been working on for the Dune Network. These tokens can be used to represent any kind of fungible asset and allow wallets, block explorers, dApps and Smart Contracts developers to interact with these tokens.

This standard specifies a minimal but powerful interface for fungible
token implementations, by leveraging previous existing experience with
the use of such token standards on the Ethereum platform, namely
ERC20, ERC223 and ERC777. In particular it does not exhibit some of the problems that ERC20-like standards have. There is only one way to do a token transfer, which is to call the transfer entry point, from the sender. Its advantages are:

• No two-steps approve / transferFrom schemes. (The approve entry point was added to ERC20 to handle token transfers to smart contracts, but is pretty useless as a base function outside of this particular scheme.)
• No double spending attack.
• Possibility to send data with transfer (just like with the base currency).

In this sense, this standard is closer to ERC777 than to ERC20 (which is meant to be a replacement for ERC20).

The following excerpt is a reference implementation for the transfer entry point (the function perform_transfer does the balances bookkeeping in the accounts map).

let%entry transfer (dest, tokens, data) storage =
  no_base_currency ();
  let accounts = perform_transfer (dest, tokens, storage.accounts) in
  let ops =
    match [%handle TokenReceiver.receiveTokens] dest with
    | Some dest -> 
      [dest.receiveTokens (Current.sender (), tokens, data)
                          ~amount:0DUN]
    | None -> match data with
      | None -> []
      | Some _ -> failwith "Cannot send data to a non TokenReceiver contract"
  in
  ops, storage.accounts <- accounts

Once the balances are updated, we check if the destination has an entry point named receiveTokens (with the appropriate signature). If so, the contract is called with this callback entry point, and information about the token transfer together with the data parameter is passed on. This way, the receiving contract is notified immediately of an incoming token transfer and can perform actions based on the given data, the token sender, and the amount (such as forwarding the tokens to a manager account, or calling a piece of code to provide a service in exchange for the tokens).

The current proposal can be viewed here https://gitlab.com/dune-network/dune-network/merge_requests/131, together with Liquidity and Michelson reference implementations. We are open to remarks and encourage discussion on this proposal!

Connect with us

Discord: https://discord.gg/JBUGqFg
Telegram: https://t.me/dune_network
Medium: https://medium.com/dune-network
Twitter: https://twitter.com/dune_network
Reddit: https://www.reddit.com/r/dune_network/
Gitlab: https://gitlab.com/dune-network
Website: https://dune.network
Email: contact@dune.network