Skip to main content

Determining your blockchain connection

📝In this article, we cover:
  • What is a blockchain connection and why is it important
  • Three types of blockchain connections
  • How to choose a blockchain connection based on your game mechanics


Blockchain connections refer to how games read/write information on blockchains.

Connections are important because they can determine the technical requirements for powering game mechanics, how often games communicate with blockchains, and the types of interactions that are possible. While they do not directly translate to specific components of a web3 stack, they guide future architectural decisions so are important to keep in mind. We will cover three types of connections:

  • Read only
  • Read and write
  • Read write constant

Start with your game mechanics

Game mechanics determine how assets will be used in and outside the game, the response rate required from the blockchain, and ultimately the connection type that is needed. The first step to choosing a connection is answering ‘what mechanics will my game include’.

Here’s how different mechanics can map to different connections:

  • When simple game mechanics that only involve one-way communication between the game and blockchain, read-only is sufficient. Examples of this are viewing the cards a player has in their inventory or checking the skins a player has of a certain character.
  • When game mechanics require uploading some information to a blockchain at certain times or at a low frequency, read and write is more appropriate. For instance, winning a tournament in the game may mint new cards to the top 10 players' wallets.
  • If your game relies on complex, unpredictable, high-frequency game mechanics, then read-write constant is best. For example, if you have built an open-world game, where trading cards is a mini-game within the game world (similar to Pokemon Go). Here, gameplay depends on frequent unpredictable modification or addition to a player’s assets.

Connection types can be applied to each mechanic individually (e.g. in an FPS game you might put skins on the blockchain, but may decide not to put every bullet on the blockchain).

Choosing a connection type

Connection TypesCharacteristicsExamples
Read only
  • Game reads assets from collections only and uses in game
  • Minting and sale happens outside of core game
  • Cosmetics or skins for characters or equipment
  • In Gods Unchained, NFT cards can be purchased on external marketplaces. These are read into the game based on a player’s wallet addresses and used in gameplay.
Read and write
  • Games can read and write to blockchain on periodic or triggered basis
  • Writing is not part of core gameplay (e.g. items can be minted after a session. These do not impact the session experience.)
  • Minting and sale happens outside of core game
  • Rewards after session based games - duels in card games, rounds or matches in PvP games.
  • In Guild of Guardians, assets are minted to a player’s wallet after clearing a dungeon
Read write constant
  • Game can read and write to blockchain in near-real time
  • Writing is part of core gameplay (eg items directly impact gameplay and this must be reflected instantly)
  • Illuvium Overworld is an example of a read-write constant game. For example, a player might burn a shard in the game to capture an Illuvial, and this information is update in near-real time on the blockchain.

Once you determine which connection type is required for each of your game mechanics, note this down as it will influence future architecture requirements.

IMX Whitepaper IMX Tokenomics Block Explorer Careers Contact Us