Thoughts about Simple Tokens on Iota

Peaq is a project that aims to bring ERC20 like tokens to the Iota platform. It intends to work on the Tangle as it is today. This means:

  • no standard for determining timestamps
  • no Qubic

Out of curiosity, I thought it would be interesting to think about how you could implement a dead simple fixed supply token if you didn’t have these constraints. These are not full featured ERC20 tokens. Just the simplest imaginable tokens.

My goal for this exercise is to make transferring tokens as close as possible as transferring Iotas.

To avoid confusion or unintentionally misrepresenting peaq, I will adopt my own terms.

Let’s start.


Most Ethereum Wallets have direct support for ERC20 tokens. So it seems reasonable to have special Iota wallets & nodes that understand about an important standard token format in Iota.

Say we had a modified Iota node (or one built on top of an IRI node) that would create and validate transactions for these tokens. Lets call them T-nodes and T-transactions.

My assumption is that users that are interested in these tokens would run these special T-nodes and accompanying T-wallets.

Given that our goal is to make the token transfers as close as possible to Iota transfers, hopefully this would not require large changes to current node software.

Token Creation

Let’s allow anyone to create a new token from any address that they control. The identifier for the token will be the address of the input transaction in the token creation bundle.

The bundle contains


From: "ABC....",
Message: {
"tokenCreation": {
"totalSupply": 100000


To: "XYZ....",
Message: {
"tokenAddress": "ABC....",
"value": 100000

This creates a token with a unique identifier of “ABC….” (the address of the input transaction) with a supply of 100000 tokens and sends all those to address “XYZ….”.

We probably don’t need the output transaction, but I think it simplifies reasoning about it if the end result of the creation bundle is a normal token transfer output transaction.

Token Transfers

Token Transfer bundles would be as follows


These are normal iota inputs with an Iota value of 0 and a token value in the message.

From: "XYZ....",
Value: 0,
Message: {
"tokenAddress": "ABC....",
"value": 100


Similarly these are normal Iota outputs with a 0 Iota value and the same message format as per inputs

To: "BBB....",
Value: 0,
Message: {
"tokenAddress": "ABC....",
"value": 100


To: "CCC....",
Value: 0,
Message: {
"tokenAddress": "ABC....",
"value": 99900

Notice that all we have done is replace the normal Iota value field with a message body that contains a token identifier + a value.

Similarly to normal Iota transactions, addresses can only be used once as inputs. So all the tokens need to be transferred to outputs.

For safety we will store token balances on different addresses to Iota balances, as normal nodes won’t know that they need to move token balances to new addresses when they spend Iotas from that address.

Double Spend

Normal Iota nodes will see these as data transactions and so not enforce the same rules they do for transferring of Iotas.

As such we will have T-transactions confirmed on the tangle that are invalid for our tokens.

Our T-nodes need to reject the invalid T-transactions somehow. We need an approach that ensures all T-nodes will come to the same decision about which T-transactions are valid.

If we could determine absolute ordering of T-transactions then we could simply apply them in order and reject any that cause an address balance to go negative for a token.

However, ordering on the tangle is not always objectively deterministic for transactions submitted close together in time.

Option 1: Timestamps & T-blocks

timestamps.pdf describes the problem of reliably determining ordering and timestamps in the tangle. As discussed at the end of, Qubic is likely to adopt a standard algorithm for determining timestamps.

If we assume our T-nodes use such a standard algorithm and that it gives partial ordering with some ambiguities (i.e. some cases where we can’t objectively decide which T-transaction came first) then can we make use of that for our tokens?

In all cases where we can objectively determine an ordering of T-transactions, we apply those transactions, in order, to their accounts and reject any that cause a token balance to go negative. As long as all T-nodes will come to the same conclusions about the partial ordering then they will reject the same T-transactions.

Where we hit T-transactions that we can’t determine the order of, we group them into what we call a T-block. For the T-transactions in this T-block we treat them has having the same timestamp.

We process this entire T-block as a single unit. We apply all the T-transactions in this block in any order.

If at the end of processing this block, we hit any addresses that result in a negative token balance, then we reject all T-transactions for that address within the T-block.

We could refine this approach by holding off judgement on these T-transactions for a period of time. If within this time the account balances return positive we could accept them.

T-transactions that are confirmed Iota transactions and have been processed as above are considered confirmed T-transactions. T-transactions should confirm fairly soon after their corresponding Iota transactions.

The key to this working is that all T-nodes must be able to reliably follow this process and come up with the same token balances. If not then the scheme won’t work.

If it does work, then the nice thing about this is that it should require little additional logic to what nodes already do. Best of all, these tokens are transferred in essentially the same way as iotas and confirm in a similar timeframe.

No additional machinery is required.

Option 2: Arbiter Qubic

If we can’t reliably get our T-nodes to arrive at the same state of the token balances using timestamps, then we could implement a special qubic that acts as an arbiter of which T-transactions are valid.

This qubic would operate similarly to the COO.

It acts on confirmed Iota transactions and adds milestone transactions to T-transactions that it deems valid according to it’s rules. In effect it confirms the T-transactions from the confirmed Iota transactions.

The downside, is that someone needs to pay for the qubic and it is a more centralised solution.


There are no doubt many complications that I have overlooked, so it may be that neither option is viable or desirable.

Still I really like the idea of making token transfers as similar as possible to Iota transfers.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store