Token-based Transaction Model


everiToken uses token-based transaction model for non-fungible tokens.

In short, in a token-based ledger, for each token, we create independent data space to store the full change history of the token's ownerships. In this way it's very easy to do sharding and multi-core paralleling because the data space of every token has nothing to do with the space for another token, so operations of different tokens could be done parallelly easily without conflicts. This makes super high performance become possible, and improving TPS is easy by sharding or adding more CPU cores.

Token-based transaction model is invented by several core team members of everiToken (Hengjin Cai, Ceeji Cheng, Harry Wang and etc.), and is proved to work perfect for NFTs on everiToken. A related candidate IEEE article has been submitted and is being reviewed.

Technical Detail

everiToken could be considered as a status machine that changes its status when and only when executing actions on every irreversible block.

For a blockchain based on token-based transaction model, like everiToken, it might divide the database into two parts, one is Token DB, and another is Block DB. The first one is where the token-based transaction model works, storing and managing data spaces of all the non-fungible tokens. The Block DB, the second one, stores the original blocks.

Both Token DB and Block DB should be a versionized DB for fast rollback when a block is reversed. For example, everiToken uses RocksDB for Token DB.

Both Token DB and Block DB are append-only databases. So whenever someone writes data into them, new data will be appended, the version of DB will be increased, but old value won’t be removed.

Token DB

Token DB is a indexed DB for quickly searching and changing the newest status of the blockchain such as the ownership of tokens and the balance for fungible tokens of accounts on the chain.

Token DB could be considered a key-value database. The key indicates the id of tokens, and the value represents current ownerships of tokens. Since the database is append-only, so there will be many values for each key, but only the latest value represents current ownership status of the token, others are only for history reference and rollback. So for each token, there will be a independent data space including all the ownership change history, just like a seperate chain.

The first value of the chain is the initial ownership. When one executes a transaction which includes an action transferring this token, new ownerships will be appended. Old versions could be used to rollback the value if the block is reversed and will eventually be garbage collected.

Because each token has a independent data space, so sharding becomes very easy. For example, if we have two computers for one node, we could let each computer process only half of the tokens. Suppose there are 100 tokens, so for token 1 - 50, the first computer will process, and for token 51 - 100, the second computer will process. Because changing the owner of one token will almost not impact other tokens, so two computers could process parallelly.

Block DB

Block DB is in charge of storing all the original irreversible blocks of the chain. Each Block stores all the detail information including the name and parameters of actions executed, the signatures that is on the block and some extra information.

The following graph shows how do two kinds of databases work together for NFT tokens:

Token-Based Model

Comparing to other transaction models


In the UTXO model, each token owner transfers a coin they own to another by digitally signing the hash of a previous transaction and the public key (address) of the next owner and adding these to the end of the coin. The mechanism is essentially a continual transaction of inputs and outputs where the owner of tokens actually does not directly own the tokens, but rather owns the output to a specific number of tokens that can then be signed over as an input to a new owner who then controls the new outputs.

UTXO Model

As you can see, UTX is great for avoiding double-spending as it is obvious that any input could only be used once. But it also has some disadvantages:

  1. BTC is not a kind of NTF, it is a FT. It is useless to keep a unique id for every UTXO. (everiToken moves it to NFT use.)
  2. UTXOs are one-off. It's a waste of computing resources and disk volume to store that huge amount of UTXOs.


Balance-based transaction model is just like what does a bank do. You create a account in a bank and then save money into the account, then the bank changes the balance of your account. It's more efficient than UTXO because it only changes a number in the database. But obviously it is not suitable for NFTs.

Moreover, balance-based model is not good at sharding, because when transffering something to other people, you need two steps: first is to modify the account of the old holder, second is to modify the account of the new holder. For safety, you must do two steps as one atomic operation, but in a sharding environment it's difficult and the performance is bad. But in token-based transaction model, there will be only one step, which is to append the new ownership of the token.