Interoperability is a Myth

The Myth of Interoperability in Games‍

ETHDenver, the largest and longest running Ethereum conference in the world, kicked off in Denver this week. While the conference was founded to focus on Ethereum, it does have a “rising tide raises all boats” approach to holding panels and discussions on different protocols and technologies that are not directly related to Ethereum. This is driven by the belief “in a future where blockchain interoperability and collaboration create limitless possibilities” (Source).

While blockchain interoperability is possible, we do not believe that complete interoperability in video games is realistic. This will certainly put constraints on aspirations for a truly open metaverse. Here are 5 key limitations:

1) Ownership & Transferability: Currently, the transfer of assets across chains is done through bridges. Blockchain bridges enable token transfers, smart contracts, and the exchange of data, feedback, and instructions between two chains. As each chain has a different token and operates on different rulesets, the bridge serves as a neutral zone for transactions. As an example, if you owned ETH and wanted to transfer some of it to Solana, you lock the amount of ETH you want to transfer into a smart contract and gain access to an equal amount of wrapped ETH that you can use on the Solana network. When you want to convert back to the Ethereum network, the wrapped ETH you own gets burned and an equal amount of ETH goes back to your wallet (Liquid). Binance Bridge is an example of a cryptocurrency bridge and Portal by Wormhole is an example of an NFT bridge.

The problem with this is that these bridges do not enable actual transfer and are not a true acknowledgment of value and ownership across chains. The asset is not literally moved from one chain to another. Instead, the assets are frozen in smart contracts and a new version is minted on the other chain (Wormhole). A cross-chain asset is essentially a copy of the original, and while only one can exist at a time, this has the potential for exploitable loopholes of the original smart contract if cross-chain transferability conditions are not explicitly written. For example, if the creator of an NFT on Ethereum writes that they receive 1% of every transaction but do not explicitly write that this rule is transferable across all chains, when the NFT is bridged to Solana and then transacted, the creator of the NFT would not receive 1% of the transaction. This is a shortcoming of cross-chain technology.

2) Identity / Footprint: While identity in the digital universe has many different connotations, for the purpose of this argument, we define identity as one’s “footprint” or interaction history. On chain, this is usually defined as the assets you own and the transactions you have completed. We have already determined that checkpoints for acknowledgement of ownership cross-chain is currently only done when assets are bridged - simple communication across bridges does not exist. If a game (or other web3 entity) wanted to piece together the identity of a player across all chains, they would need to create a centralized location where a player could tie their Metamask, Phantom, Ronin, etc wallets together.

3) Visuals: While this is the most obvious to traditional game developers, this is an area that we have often seen overlooked and under-analyzed. In order for an asset to be interoperable across games, a visual representation of that asset needs to be created. Homogeneity of art styles across different games is rare, thus each asset must be redesigned/morphed into the new art style which may include a conversion from 2D to 3D or vice versa. Developers also need to consider physics and the way that the asset will interact with the environment. For example, should a sword on fire move with the wind or get doused when walking in the rain? This limitation will continue to hold back seamless interoperability across virtual worlds.

4) In-Game Utility and Properties: In addition to the visual representation that must be re-created across each experience, developers also need to intentionally program asset properties in their game. The bridges enable communication of metadata at the point of transaction, but each game developer has to set how the properties change across each game. If a sword has an attack value of 100 in Ember Sword, what would the attack value be in Star Atlas? While the most scalable way to introduce this would be something like skill multipliers for weapons and armor, this does not address the vast breadth of assets that have been marketed as interoperable and each needs to have a customized impact on each new environment. Multiplied times the hundreds if not thousands of games that we anticipate will emerge in the space - allowing for non-cosmetic interoperable assets is not scalable.

5) Adherence to Protocols: One way to solve these issues is to define standardized protocols across the industry, similar to HTTP with the internet and SMTP with email. These protocols could take the form of standardized skill multipliers, object physics, or art-style transfers for example. If developers put in the effort to adhere to such protocols, the friction of transferability across chains and games would be significantly reduced. It acts as a shared language and over time, with critical mass adoption, becomes an entrenched norm. This is not the current state of the industry, yet it could certainly emerge in the coming years.

Another way developers can support interoperability is by enabling various zones with different rulesets for interoperability within their centralized platforms. Developers may have a standard zone with minimal interoperability catered to the majority of their user base. They may enable the spawning and management of new zones by players to self-moderate with different rulesets on interoperability and adherence to protocols as well. A multi-zone approach of this nature would help keep platforms open while ensuring a controlled quality experience for users. This approach is not dissimilar from the restricted environments described in Neal Stephenson’s novel Snow Crash, where the “metaverse” term was originally coined. Protocol adherence, paired with spectrums of openness on platforms will make it easier for platforms in the metaverse to foster interoperability.

Takeaway: Though adherence to standardized protocols would help solve for some of these issues, none exist today and not all game developers would choose to opt-in. True interoperability, as defined as successfully executing on every dimension above is not realistically possible. As a result, the concept of a truly open metaverse, though technically possible, is practically unattainable. However, it is possible for individual games and centralized platforms to push towards decentralization with enablement of some interoperable aspects on a much smaller scale. This would entail:

• Create a centralized profile so players can link each of their wallets to allow for cross-chain communication and ownership acknowledgement
• Limit the number of projects that will have a physical representation in game (e.g. limit asset to be a small asset, utility token, 2D artwork, etc) to allow for scale
• Prioritize projects with themes that have a scalable transferability of utility