Google doc with comments functionality: https://docs.google.com/document/d/1zZ6rVoAo1WI08_fmGG7jjJlo6mJGK_fORj2Iaxm_AGU/edit?usp=sharing
Table of Contents
1: Introduction
2: Public-Good IBC corridor
2.1: Subsidized Public Good IBC corridor
3: Artificially Scarce Corridors
3.1: Corporate Owned Artificially Scarce Corridor
3.2: DAO Owned Artificially Scarce Corridor
3.3: Crowd Owned Artificially Scarce Corridor
4: Conclusions and further questions
1: Introduction
This article derives from conversations inside Chorus One and the IBC Community call. Thanks to everyone who contributed to the discussions. Special thanks to Chris Goes for answering my questions in the community call, and for the idea of a crowd-owned artificially scarce corridor.
This post covers the possible economic arrangements for the functioning of IBC corridors between a pair of chains. It is meant to be a survey of possibilities, rather than a recommendation of specific paths. The current IBC implementation orients towards one of the options (Public Good IBC corridor). The post will help the reader position the current IBC implementation vis a vis the other potential options.
Let’s first start by describing what is meant by an IBC corridor. An IBC corridor between two chains A and B is a combination of:
- Light client for B running on A and light client for A running on B.
- Some validated consensus state for B in A, some validated consensus date for A in B.
- Connections and channels are running on top of the light clients that utilize the validated consensus states.
An IBC corridor is a workable path to send IBC packets from A to B and back. We have a few different ways of building IBC corridors.
The main difference comes about when we consider the property rights of IBC corridors. It takes financial resources to keep a passage updated since header syncing must continually happen on the two chains. Depending on whether we allow property rights to exists on corridors, the following categories emerge:
2: Public-Good IBC corridor
The first type of IBC corridor - a public-good corridor - does not include any notion of property rights on either of the two clients. No party can preferentially charge corridor fees for transactions using the corridor.
Any user can submit updated headers on either side of the corridor. Submitters must bear the transaction costs of header processing. But submitters are unable to recoup that cost by charging corridor fees on other transactions that might use those (validated) headers.
Corridor users send IBC packets by paying transaction fees of both chains and include some incentives for the relay of their transactions.
A public-good corridor is non-excludable - no party can exclude a user from sending a transaction on that corridor. It is also non-rivalrous - the usage of the corridor by some user does not impair your ability to use the same route.
The first implementation of IBC likely contains only public-good IBC corridors.
The main advantage of these designs is that they require no property rights, and are open for all users. The main disadvantage is that there might be a “free rider” problem. Users would like to send transactions on such a corridor, yet nobody is incentivized to keep the consensus state updated on either side of the corridor.
If header verification is cheap relative to the average transaction fee level, the free-rider problem may be less material. However, when header verification is expensive (for example, in the Solana-Cosmos Hub corridor), the free-rider problem could be significant. The failure mode for a public-good IBC corridor occurs when headers are synced at a much lower frequency than users desire. It leads the average user to experience high transaction latency on their cross-chain transactions.
2.1: Subsidized Public Good IBC corridor
As a result of the free-rider problem, there might be a configuration in which token holders of A and B agreed to fund header updates transactions on both chains by allocating financial value to submitters of headers. The non-excludability and non-rivalry properties of the corridor remain the same.
One challenge in designing a subsidized public-good IBC corridor is the coordination of both chains to bear the burden of subsidies equally. A second issue pertains to the choice of chain pairs to subsidize. The Cosmos hub could only end up, say, supporting corridors to 5 chains. Which chains should it pick? Governance must weigh in on this decision costing time and DAO organizational bandwidth. There is a natural cap on the number of subsidized public good corridors. To win the ‘Interchain Hub’ market, the Cosmos Hub could logically choose to invest significantly in this type of corridor.
3: Artificially Scarce Corridors
The second significant type of IBC corridor contains property rights, on the two chains, that allow a party (or a set of two parties) to “own” the corridor. Ownership of the corridor translates into the ability to charge corridor-specific transaction fees. A message on an artificially scarce corridor would pay for the transaction processing on both chains and a corridor fee. Corridor fees paid by such users accrue to the owner(s) of the corridor.
Because there is an incentive to make corridor fee revenue, there is an inclination to spend resources on keeping the headers on both sides updated. Artificially Scarce Corridors are excludable - the owner of the corridor can deny service to a particular user if they don’t pay the corridor fee. However, such corridors are not rivalrous - your usage of the corridor does not impair my ability to use the same. Artificially scarce corridors may not have a “free rider” problem since corridor owner(s) have natural incentives for the relay of transactions.
Artificially scarce corridors could be further classified based on the types of owners. The three compelling cases are:
⦁ Corporate ownership of an artificially-scarce corridor
⦁ DAO ownership of an artificially-scarce corridor
⦁ Crowd ownership of an artificially-scarce corridor
3.1: Corporate Owned Artificially Scarce Corridor
In this case, the property right belongs to a corporation. Imagine Figment networks owning a corridor between Cosmos Hub and Kava. There is a corridor fee (paid to Figment) of $0.02 for every IBC transaction routed on the corridor in addition to the transaction fees levied by the Cosmos Hub and Kava. All fees might aggregate into a unified “transaction fee” of $0.05 for the end-user. Figment might also sell transaction throughput in bulk to wallets. In exchange for the transaction fee, Figment keeps consensus headers updated, and runs high-availability relayers between the chains.
The main advantage of such a design is its simplicity at the protocol level. IBC economics are all negotiated off-protocol by a competitive market.
The main disadvantage of the design is public perception - cryptocurrency engineers favor decentralized solutions to problems, and would prefer some ‘decentralized ownership of an IBC corridor.’ However, we must ask ourselves what utility decentralization brings to IBC corridors - these pieces of infrastructure are already designed to be dumb. Users don’t need to trust corridor functioning for the safety of funds or business logic. All they need is for a corridor is to be highly available and regularly synced - properties that are probably serviced well by a competitive market of corporate-owned corridors.
Another potential issue could be whether such corporations are at risk of being regulated as money transmitters since they move financial value between electronic systems: https://coincenter.org/entry/what-is-money-transmission-and-why-does-it-matter
3.2: DAO Owned Artificially Scarce Corridor
Corridor ownership by DAOs hosted on their sovereign chains is an intriguing case. A DAO, such as the Cosmos Hub or a “Relayer DAO” (with its sovereign chain and native token) or an association of validators (with a membership token), owns a particular IBC corridor. The economic protocol of the DAO assigns the responsibility of header syncing and relay to its members. There might be a periodic rotation of such obligation. The quality of work done by DAO members gets monitored, and they are compensated based on the quality. Collected corridor fees are allocated to the DAO token holders as a return on their invested capital.
The main advantage of such a design, over the previous one, might be its censorship resistance. It is unclear if regulators can force multiple corporate-owned corridors to censor transactions. If they can, a DAO owned corridor serves as a backup. In reality, it is unclear if DAO owned corridors will fare better. The upcoming regulatory battles against DAO held decentralized exchanges should give us some data points on the regulatory immunity of such organizational structures.
On the downside, there are several. First of all, an economic protocol to co-ordinate its members is required. Such contracts will need to judge the quality of maintenance of a corridor by a member - likely a challenging problem. Second, there will be a coordination cost paid by such a decentralized organization that will probably make it less economical than corporate-owned corridors.
3.3: Crowd Owned Artificially Scarce Corridor
Imagine a corridor, modeled after the public-good IBC corridor, that allows anyone from the crowd to contribute headers for syncing the light clients. Also, the corridor charges a corridor fee. When the user succeeds in submitting a header, they gain the rights over all corridor fees routed using the particular header provided. For instance, if Chris manages to present Header 100k of Chain B to Chain A, 50% of the corridor fees charged to any transaction using Chris’ header are routed to Chris.
Effectively, header submission transforms into a crowd game. Users can partake in the game, in expectation of making corridor fees whenever their submissions enter the chain. There is a race to submit every header, which makes the updates fast and the protocol highly available.
Such a design has property rights, but these property rights are sliced up and allocated to the headers (and their submitters). There is artificial scarcity in the design since the header-updating crowd excludes users not paying corridor fees from the usage of the infrastructure.
The main advantage of such designs is the lack of coordination overhead required by a DAO owned corridor. They are likely to be censorship-resistant as well. These protocols are also better aligned with the value systems of cryptocurrency engineers.
There are a few disadvantages. One disadvantage is that the crowd cannot invest, at a loss, to make profits later. If a particular corridor has low transaction throughput at the start, there might be a period of investment needed to attract transaction throughput (and subsequently profits). Such situations cannot be handled by a crowd since a member of the crowd only makes a revenue for the current transaction throughput.
The second disadvantage is the existence of competition in the crowd for every header submission. The game will lead to duplication of work, with the same header submitted twice. Such repetition could ultimately drive up corridor fees to a level higher than corporate-owned corridors. Protocols to avoid duplication of work in a crowd setting are likely quite hard to design. DAO owned corridors also avoid such duplication of work, by having the DAO co-ordinate corridor responsibilities.
One might ask what the exact difference between DAO held, and crowd owned corridors are. The crowd owned system does not contain any internal capital (tokens) or a sovereign blockchain dedicated to such activity. The DAO held system, has internal capital in the form of a token, and probably a sovereign blockchain to co-ordinate its worker-members.
4: Conclusions and further questions
This post presented a few alternative designs for the economics of IBC corridors. This research opens up a few questions:
- What is the header syncing cost for the Cosmos Hub and other popular SDK chains? What do these costs depend on? How do these costs compare to standard transaction fees?
- What are the implications of the above for the “free rider” problem in public-good IBC corridors?
- How does one design a protocol to measure the quality of work of a relayer? Such protocols are necessary for DAO owned IBC corridors.
- Is there a decentralized mechanism to limit competition in the crowd-owned IBC corridor design space?
- Should the first production version of IBC have property rights? What kind of property rights are most suitable for inclusion?
- Which pairwise chains are more susceptible to free-rider problems?
- Which pairwise chains would favor corporate-owned IBC corridors, and why?
- What are the advantages of large validators, ala Sikka, in the different possibilities presented?