Token-based Transaction Model


everiToken employs the token-based transaction model in regards to non-fungible tokens within our system.

In short, for each token in a token-based ledger, we create independent data space to store the full history of a token's ownership. In this way it's very easy to do sharding and multi-core paralleling because the data space of a given token has no relationship with other tokens. As a result, operations of various tokens can be done easily in a parallel manner without conflict. This enables a super high performance and constantly improving TPS by easily sharding or adding more CPU cores.

The Token-based transaction model was invented by several core team members of everiToken and has been proven to work perfect for NFTs on everiToken.

Technical Detail

everiToken could be considered a state machine because it changes its state every time when actions on an irreversible block are executed.

For a blockchain based on the token-based transaction model like everiToken, databases can be divided into two parts: Token DB and Block DB. The token database is where the token-based transaction model works, storing and managing data spaces of all the non-fungible tokens. The Block DB 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 and the updated version of DB will increase in value, but the old value won’t be removed.

Token DB

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

Token DB could be considered a key-value database. The key indicates the ID of the tokens, and the value represents current ownerships of tokens. Since the database is append-only, there will be many values for each key, but only the latest value represents the current ownership status of the token, while the others are only for historical reference and rollback. For each token, there will be an independent data space that includes all the ownership history, just like a separate chain.

The first value of the chain is the initial ownership. For example, when one executes a transaction, the new ownership will be appended in the database. Old versions could be used to roll back the value if the block needs to be reversed and eventually will be garbage collected.

Because each token has an independent data space, sharding becomes very easy. For example, if we have two computers for one node, we could let each computer process half of the tokens. If there were 100 tokens, the first computer would process tokens 1 - 50, and the second for tokens 51 – 100. Because changing the owner of one token will not impact other tokens, the two computers could process in a parallel manner.

Block DB

Block DB is in charge of storing all the original, irreversible blocks of the chain. Each block stores all the detailed information including names, parameters of actions executed, signatures on the block, and more.

The following graph shows how two kinds of databases work together for NFTs:

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, adding these to the end of the coin. The mechanism is essentially a continual transgression 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, UTXO 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 NFT, it is a FT. It is useless to keep a unique ID for every UTXO. (everiToken supports both NFT and FT)
  2. UTXOs are one-off. It's a waste of computing resources and disk volume to store that huge amount of UTXOs.


The account-based transaction model is just like what a bank does. You create an account at a bank and then save money into the account, changing the balance. This is completely different from the way UTXO works. It's more efficient than UTXO because it only has to update the balance in the database, not create new UTXOs. As a result, the UTXO model is not suitable for NFTs.

Moreover, the balance-based model is not good at sharding because when transferring something to another person, it requires two steps: the first is to modify the account of the old holder, and second is to modify the account of the new holder. For safety reasons, you must do two steps as one atomic operation, but in a sharding environment it's difficult and the performance level is poor. However, in the token-based transaction model there is only one step, which is to append the new ownership of the token.

Continue Reading: Consensus Algorithm