Taking Games Multichain

Socket’s recent workshop with Game7 on multichain game development got me thinking more about the implications of multichain - especially for gamefi:

For starters, multichain DOES feel like the future. See, games have many moving parts. Blockchain games, even more so. It is established that Ethereum has severe scalability issues: low throughput, slow confirmations, and high, erratic gas fees.

Hence, it’s natural that game devs would opt for more scalable alternatives, i.e., L2s, app-chains, or subnets. These alternatives provide cheap and fast txns, helping games to scale and onboard the next billion players faster. Some chains also have chain-specific features, which contributes positively to either the gameplay or game development. BUT solving for scalability is breaking composability and access to users and liquidity.

The problems

As more and more chains come into the picture, the ecosystem starts to fragment. Compared to a single chain world, a multichain world will have games, assets, and users spread across different chains, marooned from each other. This isolation creates multiple problems from players. For starters, games are now stuck on their deployed chain - unable to access liquidity nor users from other chains. In a world where Ethereum and other major chains are losing their dominance, liquidity and users to L2s/app-chains, this is nothing short of a death knell.

Additionally, users and liquidity get fragmented across multiple chains, reducing the amount of players and TVL that a game can potentially access. Imagine losing out on players from Optimism or Arbitrum simply because you launched on BSC. Even subnets are not immune - Defi Kingdoms on AVAX’s subnet has a TVL of just $4.4M, a far cry from Avalanche’s total of almost $2B.

But the biggest challenge that will come is broken composability. The creation of multichain silos, where different games are deployed on different chains, prevents them from being truly composable. For example, most of the high-value NFTs like BAYC lie on Ethereum and are chain- restricted. If Yuga Labs decides to have a BAYC-led game, the game has to be on Ethereum mainnet (unscalable for games), or its own chain (added problem of figuring out how to bridge assets there). Hence if a game is not on Ethereum or own app-chain, it will not be able to leverage BAYC in its gameplay. Even TreasureDAO, the poster boy for interoperable games, is restricted to Arbitrum’s liquidity and users, and is composable only with Arbitrum-native apps.

All of these problems also culminate into bad UX for the player. Even Axie - if you are a user on Polygon, you will not be able to access the game directly. You will first need to figure out a way to bridge assets from Polygon to Ronin (there are no direct bridges, you will have to move assets via Ethereum), and then set up a brand new wallet to access your assets on the Ronin network. Not fun.

Considering all of this, interoperability/cross-chain communication protocols could be a possible solution. Interoperability protocols like Socket [https://docs.socket.tech/] helps apps on separate blockchain interact with each other, enabling users to move assets freely across different chains. Similarly, Cosmos has IBC for relaying data across supported chains.

We already see apps moving to their own app-chains, and there are so many bridges and cross-chain protocols coming up today. It does feel like people are preparing for the multichain future. When so many chains exist, and each chain has its own trade-offs, apps that are chain-agnostic will definitely become the norm.

In fact, the more I thought about this, I realised that blockchains aren’t special - they’re just distributed databases. A moonshot that I think about very often: maybe in the future, we won’t even have to think about which chains to choose. Game developers will only need to consider if they want to be on-chain, and then deploy their game to an interop layer like Socket, which will automatically ensure that the services and contracts are being deployed on the chains most suited to them.

In essence, interoperability protocols are definitely one way to future-proof your game - both in terms of gameplay and players. Personally, these are the questions I’m most curious about:

  • What are the cool new game mechanics that can be created with the composability enabled by cross-chain communication? We might have to rethink game design from the ground up.

  • If games are natively multichain, does that mean they’ll qualify for grants and incentives from all chains?

  • Would we actually see games turn into an entrypoint for first-time crypto users? Good web3 games with acceptable UI = better onboarding to crypto for the masses


To be honest this was a question that i always had. Is a game limited to the users of those chains where they have deployed? No matter how cool the game might be, if there are no users on a chain, its growth will be limited. A system like the IBC of Cosmos is indeed the go to. Even if i don’t know how that technically works, it’s easy to picture the future. If users can access projects on different chains from a single point, that it’s the game changer and the future. Sadly i have missed the voice chat yesterday. Will now jump in to read more about Socket. Thanks for this recap!

1 Like

Hi! I somewhat disagree with this notion, and here’s why…
The ASSET in the Yuga example is on Ethereum, which means a game need only to integrate any of the wallets which support Ethereum, and use a service to get info on the asset (and possibly, the collection). IMHO chains should not be PART of games. All that messaging and communication has no business on a public chain as doing so exposes the project to exploits of any unknown nature. The motivation is constant, unlike with a game with no on-chain communication apart from assets.

To me, making a game cross-chain means simply to support wallets of the chains you want, and integrate the proper data services into the backend. ie Alchemy, Moralis, OpenSea, Quicknode, etc. When you have that pattern nailed down, you just worry about the assets and you can support any collection out there. Deeper integrations with the assets mean you’d have some support from the parent contract to begin with. We’re using this technique effectively to do LOTS of things with chains.

Accessing liquidity also becomes an exercise in implementing transfer requests with a cross-chain payment system. I haven’t encountered a scenario yet where cross-chain communications or asset bridging is necessary at all. I don’t doubt that the technology is awesome, but a valid use case is still non-obvious for me at least. Would love to hear some!

1 Like