Literally a moat
There is a misconception about cross-protocol interoperability.
Many think that in an interoperable future, developers will build dapps that can be used on any protocol. This is only half true. Value will likely transact freely across protocols, allowing users to pay and get paid in whatever token they want (let’s call this “token interoperability”). However, it’s not clear whether smart contracts will run freely across protocols, allowing smart contract functions to be called from any protocol (let’s call this “contract interoperability”).
Token interoperability is a win-win for users and developers. The traditional app analog here is accepting multiple payment types (e.g. cash, various credit cards, crypto, etc.). You can think of it like Stripe or Paypal but the payment options are all the tokens.
Users get more choice with no additional costs. Developers are able to offer users a better experience with minimal additional cost (denominated in developer time). Atomic swaps and interoperability protocols like Cosmos aim to enable this and there are EIPs out to add this to Ethereum.
Contract interoperability is a unknown-lose(probably) for users and devs. The traditional app analog here is releasing the same app on multiple platforms like desktop, iOS, android, TV, etc.
Users technically have more choice, but they probably don’t care. They’d prefer for all the guts to get abstracted away so they can use the app with as little friction as possible. Developers are in for a headache. Contract interoperability means (1) deploying the same contract to every protocol you want to support and then (2) developing a way to propogate updates to all of those contracts every time a function is called in one of the contracts–in other words, managing state.
Some projects are working on elegant ways to manage state across protocols. Polkadot, for instance, uses the concept of a “relay chain” to send messages back and forth between different protocols. In theory, a developer could write a set of smart contracts, deploy them to n protocols including Polkadot, and rely on the “relay chain” to keep track of state.
Support for contract interoperability is a lot of work for a developer compared to deploying on just Ethereum. Is it worth it?
When we think about the decisions to support new platforms for traditional apps, the primary benefits to evaluate are: does it help me reach more users or does it provide a better experience to existing users? If we believe users don’t really care about the underlying protocol, then contract interoperability probably won’t help the developer reach more users. Does it provide a better experience? Maybe if you can optimize which protocol runs the contract each time, transaction fees or times might go down, but you’re probably better off just picking the right set of protocol tradeoffs for your contract to begin with and deploy there.
So far, this thought experiment has assumed one single contract that’s functionally identical on multiple protocols. What if it’s several different contracts that play different roles. This might be a compelling use case for contract interoperability, but this still means that individual protocols are providing unique value to the developer and user.
Which leads us to challenge a large assumption about the interoperable future: smart contract protocols don’t have a network effect. If the need for contract interoperability is rare, smart contract protocols are actually more like operating systems than programming languages, which means there is high switching cost and the landscape will likely be more winner-takes-all (like operating systems) than the relatively fragmented adoption of programming languages.
If we doubt contract interoperability, contracts and non-functional tokens can be considered bonded to their parent protocol, which bodes well for Ethereum in particular.
Most likely, adoption of smart-contract protocols will look something like the curve below (from my prior post on user adoption), with developers picking a range along the curve that represents their preferred protocol properties.
I’d love to hear challenges to this assessment. Why would the average developer choose to invest the additional resources to support multiple protocols?
Thanks to Kyle Samani, Spencer Noon, and Lakshman Sankar for providing input on this post
If you liked what you read, please share it with your friends