Token Parameter Hub


One of the benefits of using Blockchain technology in a service is for interoperability.
A world built with regional currencies and various types of tokens is called a token economy, and it enables services to connect to each other through the value called a token.
For example, let’s consider a local government that has issued local currency. This local currency may only be provided for limited use cases in a very limited economic sphere. The users of course will not be able to use this currency if they leave the area. However, if they have access to an exchange, where they can exchange the local currency for external currency, then the users gain access to a much wider variety of services. This is the value of interoperability.

Interoperability in games

Just like in the regional currency example above, Blockchain games allow applications to be connected to each other through the axis of characters and items.
Interoperability in games allows exactly this usage, and here are some examples that are being discussed around the world.

1. Enjin Coin
When characters are created, they are minted on the basis of Enjin Coin. Items minted based on Enjin Coin can be turned back into Enjin Coin. Users can turn Enjin Coin into items, and then back again, and by doing so they can use their assets across multiple applications.

2. KittyVerse
KittyVerse is structured to allow the reading in of asset data used in CryptKitts from multiple games, and in participating games, it is possible to call the KittyVerse API to get cat color, material ID, and other information as json data.

Benefits of interoperability

What exactly are the benefits of being able to exchange assets across multiple game titles?

(For users)
Even if a game shuts down, characters can be used in different game applications.
If there is interoperability with a market, then characters, including those trained by users, can be bought and sold on the market.

(For game publishers)
Using well-known IP is reassuring for game users, and it makes it easier for game publishers to make exciting games.

Challenges for interoperability in games

As in the KittyVerse example above, there are proposals for having common parameters shared across multiple games, but in the actual implementation there are a few issues.

One issue is that for all characters (tokens) already issued, the entity introducing assets must generate all parameters for their game. If a game admin has thousands or more issued assets, then setting the parameters one by one is very costly. It’s even more challenging to manage assets from another game that could be minted at any time.

Also, depending on if a game is an action game, a shooter, or a fighting game, the required parameters will differ, and having the provider set parameter variables for all those possibilities in advance is impossible.

Treating fairly using contracts

If there were a mechanism to fairly manage character asset parameters, then it is easier for those on the game side to relax and bring external assets into their game without worrying about management costs.
Specifically, what kind of mechanism would be required to manage parameters fairly?

One is managing parameters by owner agreement (vote).
However, for assets and characters not voted on, there would need to be a default value. If this is for a game with a large user population then that is fine, but it gets tricky when it is a non-popular character in a game that is also non-popular itself. In this case, it is hard to assign default setting values.

To achieve good transaction liquidity with a small currency base (called the double coincidence of wants problem), the Bancor Protocol employs the concept of a reserve, and has a mechanism to automatically calculate the fair price in a smart contract based on the token price, supply, and reserve ratios.

In the same way, if it were possible to calculate fair parameter values using fair values such as the contract price or supply, and then use the contract itself to automatically generate the values, then it would be possible to build an environment where character assets could be used across multiple games at low cost.

Values that form the basis for parameters

One possible variable between games could be the game’s popularity. Popularity shall be defined here as the funds held in the game contract and the number of transactions. Let us assume that there is a Game A and a Game B, with Game A being more popular, making the parameter strength A > B.

Further, to set parameters for the assets in Game A, the rarity information can become the basis for parameter strength. If the number of the item A-10 issued is 32, while the number of the item A-3584 issued is 3584, then the parameter strength would be A-32 > A-3584.

But what about A-3584 vs. B-32? A-3584 is a low rarity item, but in the more popular Game A, while B-32 is a high rarity item in the less popular Game B.
Looking at the diagram below, depending on the rarity of A-3584 and B-32 on the whole, either A-3584 > B-32 or A-3584 < B-32 could be possible.

In either case, it should be possible to set this up by having functions to define parameters on the basis of game popularity (held funds, number of transactions, etc.) and the rarity of each token (number of the item issued).

For the seed, which forms the basis of the number that will be obtained, we are considering a method that would convert numbers from the string of the parameter variable name. In essence, from the string “hp” the number 100 would be obtained, and from the string “attack” the number 120 would be obtained.

Using this method, depending on the game, things like hp and hitpoint would have the same meaning, but as they are different strings different numbers would be obtained, but we have deemed this acceptable.

Relationship between market price and strength

You may think that paying money should be required to strengthen a character, just as in pay-to-win games.

For TokenParameterHub, you may imagine that since parameters fluctuate based on the token value and number of transactions, valuable characters would have more impact in the market. Currently, we believe that the most effective method for measuring user excitement and character popularity is the monetary amount and number of transactions. (In the future, it is possible that something like an Oracle that measures user excitement could come out)

Another technique for building strong characters in an application could be to make a large deposit into the character, or to make quasi-transactions. Measures to prevent these kinds of actions will likely become necessary going forward, but at this point on many review sites for DApps, the revenue and number of transactions for a game are read in directly from the data written in Blockchain.


In a world created by interoperability, just as in the real world, there are issues associated with allowing others in that must be considered. For example, if someone else’s token system is too strong, that could have too strong an impact on your own game.

In the real world, if produce imported from abroad could impact a country’s agricultural sector, then tariffs can be imposed to reduce that risk. By setting the variable TariffRate (0–100%) in TokenParameterHub, it is possible to limit the ability value for parameters.

As the degree to which a game is influenced by external factors is a setting entrusted to each individual game, that setting will determine the parameter rate.

It may seem contradictory to set a TariffRate on parameter values that we set equally, but this is a measure that is necessary to allow multiple game titles and content other than games to participate on the same standard.


As mentioned in the introduction, interoperability is one significant value Blockchain can provide to a service, but there are many ways to approach it depending on the field and business philosophy.

Whether excellent content accumulates because there is a good platform, or if excellent content draws in other excellent content to form a platform is a chicken or egg conundrum with no quick or easy answer, but we aspire to having liquid interoperability between applications on the basis of TokenParameter Hub, and creating a better user experience as a result.



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
Fumitoshi Ogata

Fumitoshi Ogata

SoftwareEngineer@DeNACo.,Ltd, developping in R&D, Gaming, Blockchain, NFT, Flutter, Server, father, motorsport.