What IBC could learn from Visa

I sometimes witness planning conversations regarding IBC development. A recurring question that pops up in this discussions is, "how can IBC compete with X when X has such strong support?" Replace X with Router, Socket, Axelar, LayerZero, Hyperlane, Wormhole, and so on.

Here are some idle and personal thoughts on this matter.

It's true that IBC is no match for interoperability hubs. Most of these other solutions have at least one of the following advantages over IBC. First, VC backing sometimes to absurd valuation levels. Second, a strong team that is heavily incentivized with equity in startup shares or tokens. Third, a specific platform or a hub (often a blockchain) that is a centralization point for software development, upgrades and migration paths, libraries and dependencies, and that represents a single point of leverage for the interoperability protocol. Fourth – not that it matters very much, yet worth mentioning – an airdrop. Fifth and maybe one of the key properties enabling growth, the technical barrier to adoption (mainly as a side effect of point three, the "hub") is much lower compared to IBC.

But more importantly, this is comparing apples to oranges. It's not a fair comparison, neither towards these other interoperability solutions nor toward IBC.

It is simple for me to say it's apples to oranges. Understanding why is the case is very tricky, however, and it took me some time to start understanding it. It might even be unrealistic, but I'm thinking the current mental model is not constructive and it's time we move on to another phase of how we think about IBC.

I'll try to make the case by using the Visa network as an analogy to IBC. The primary source of reference for this was the Acquired podcast on Visa.

Bootstrapping Visa

There's these three forces, or sides, in the Visa marketplace:

• Banks: Their incentive is, primarily, to encourage consumer credits and therefore to "roll" as much credit every month.
• Consumers: Their incentive is, primarily, to have frictionless shopping experience, which means among others: the actual in-store payment should be fast and easy, settling their credit at the end of month should be automatic, they should be able to know with ease if they are spending above their means.
• Retailers: These are the merchants, and their incentive is to receive payments from consumers, primarily, as many of them to keep their business flourishing.

To bootstrap the Visa network in the late 1960s it took a combination of factors. But most relevant here was the fact that Visa found a way to incentive-align the three market forces above.

The most important were the banks.

How do you convince a bank that they should not use their own homebrewed credit and card system, and instead join Visa?^[1] The math for doing so is simple. What is better, a bank that dominates payments in a small local market of merchants and consumers; or a bank that is part of global-level commerce? Even if this bank participates in a small fraction of this global market, the latter makes more sense, economically. This is, among other reasons, because in a local market, the bank with their distinct credit card system needs to have both the merchant and the consumer signed up in their system. In a global market, the bank can participate as representing a merchant, or a consumer, or both.

Another, very crucial point in hindsight, is that the bank also benefits from network effects in the global market. If a bank B joins this global payments network, then the growth of others banks (e.g., another bank gaining more merchants and more consumers) will reflect in more potential traffic for bank B.

We can think of the banks as the hard side of the Visa network. Aligning with the other two sides of the market (consumers, retailers) is comparatively easier.

In a global payments network, consumers experience less friction because they don't need to carry around dozens of cards, one for each bank; this proved to be very important as globalization and international travel took off.

Retailers that accept Visa payments can get business from consumers associated with any bank in the network. This means the total addressable market for a retailer grows with the number of banks in the global network.^[2] This is the same network effect that applies to banks.

One way towards making IBC de facto standard

Is to understand that IBC should not acquire the type of users that are front-end wallets, but it should acquire interoperability hubs. This means to understand and practice the mentality that IBC is not competing with other interoperability solutions. That would be a losing game.

Just like Visa is not competing with banks, IBC is not competing with interoperability hubs.

Instead of competition, I think there is a positive-sum game possible with a very basic blueprint as follows:

• IBC expands to interoperability L1s, integrates with hubs in the sense of "hub and spoke" networking models.
• IBC encourages expansion of individual interoperability hubs. These hubs can compete with each other on user experience (i.e., fast, cheap transactions; fast, cheap integration), and should care primarily about expansion to untapped individual applications, which is sometimes other L1s or consists of rollup frameworks.
• IBC takes the more humble – but likely more constructive – role of an inter-blockchain core messaging protocol, abandoning the current design in which IBC has to provide the whole vertical (apps + core).

This is the splitting of responsibilities in the network's growth.

Put differently, IBC becomes the pipes. The user category it would focus on would be core blockchain developers – developers of hubs. Interoperabililty hubs focus on abstracting the pipes, no particular hub has to "win" all users,^[3] and the main user category they are building for are front-end wallets. IBC is the backend; hubs are the frontend. Interestingly, Polymer and Socket are two teams working on interoperability that are beginning or willing to adopt this mindset.

The analogy, at a basic level, is as follows:

• IBC = Visa network.
• Consumers = Web3 wallets & front-ends (wallets, DeFi apps).
• Retailers = Interoperability hubs (usually L1s, frameworks, aggregation layers).

The above is much easier said than done. And it is a hypothesis, not a plan, that would take years to test and iterate on.

Some obvious limitations here are that I did not put any thoughts on how denomination fragmentation evolves with this design. Neither how the two-layer monetization would work, the first layer for Hubs, the second layer for IBC. It's not even clear if IBC itself needs to be monetized, though Visa is. A third limitation is frauds: In the Visa network, frauds are possible and an important design constraint, but the current IBC pessimistic design essentially prevents frauds, which may be an overkill.

Many thanks to Aditya Ravi Raj and Ivan Bjelajac for feedback on a draft of this post.