These may not be new thoughts, but I have yet to hear them explained in a way I understood. Warning: Technical.
Abstract: I outline my understanding of the Interchain and its relevance, with a particular eye to the role of Interchain DAO tooling like DAO DAO. I envision the Interchain as an ecosystem in which organizations exist across many chains, coordinating to govern common computational resources. In contrast with visions of a singular, shared “world computer,” this Interchain would be more organic, emergent, and adaptable. In this Interchain, DAO tooling plays a particularly central role in coordinating across and between chains, applications, DAOs, and users, becoming itself a common resource—a mesh governance protocol that coordinates the computational commons upon which it relies.
The parachute game
Do you remember the kids’ game where everyone jumps simultaneously while holding a parachute? If you all jump at once (the teacher says), you’ll all float down together. The lesson of the game is that some initial coordination can create a common good.
Now imagine a geothermal vent opens up beneath the parachute just at the time of a well-executed jump’s apex, propelling the group upward into a headwind and keeping them somehow afloat. This fanciful scene illustrates a situation where initial coordination yields a self-sustaining common good. Hold this image in mind for now.
Background: Blockchains, IBC, and DAOs
Blockchains are public databases that make the most adversarial possible assumptions about the parties that provision them. Specifically, blockchains provide the capacity to run multiple versions of a shared ledger (effectively, a state machine) across multiple parties, even when some parties have an incentive to manipulate the ledger or the rules by which the ledger is updated.
A particularly compelling use is DAOs, cooperatively run organizations democratically controlled by their members. Coordinated on a blockchain via smart contracts (on-chain code), the rules of the organization, and the rules by which those rules can change, are cryptographically assured, tied to the key ownership of the DAO’s members. DAOs are compelling because the smart contracts provide automatic accounting; the blockchain prevents members from manipulating those accounts (no stealing from the till); their digital form allows flexible, cross-border coordination (they do not necessarily require a legal team to scale internationally); and, for regulators or tax authorities, the blockchain gives them a publicly inspectable state (they do not require an accounting team to audit).
While blockchains can and are today useful for DAOs, the engineering tradeoffs required to achieve blockchains’ security properties create performance problems at scale. Ethereum, which has envisioned itself as a global “world computer,” grapples with these tradeoffs as it seeks to fulfill this vision.
An alternative vision, first articulated in the 2016 Cosmos whitepaper, is to instead create a multiplicity of smaller blockchains that communicate with one another voluntarily in a loose, scale-free association. IBC (inter-blockchain communication) is a generalized cross-chain communication protocol. It allows chains to send and receive packets filled with arbitrary data to and from other chains.
The vision of IBC, the so-called “internet of blockchains,” centers primarily on application-specific chains.1 Chains are imagined to provide specific functionality, interoperating as needed with other applications in a shared ecosystem. What if, instead, this multiplicity of blockchains involves more separation between the chain and the application than this vision imagines? What if applications exist across multiple chains?
Applications that exist across chains
Juno is a permissionless smart contracting platform. Say I fork Juno and make my own chain, identical to Juno. Now, say you’re an application developer. Say you have a great app. You could run it on Juno, or on my fork.
Why not run it on both? Things go wrong on chains—running on two chains should make a more durable organization, and anyway, assets are interchangeable between them via IBC.
Now imagine you, that application developer, are a DAO. As a DAO, your objective is to advance your goals while remaining secure (or perhaps vice versa). Security is multifaceted, but generally includes those components that facilitate the DAO’s pursuit of its goals, including money (a means of incenting goal-oriented action), but also means of coordinating institutionally (e.g., voting) and extitutionally (e.g., Discord, real-life meetups), as well as DAO-managed activities themselves (e.g., frontend deployments, Cloudflare workers). Security of these components means assuring that they will continue functioning at least as well as they did at the time of analysis, even under some degraded conditions (outages, attacks).
Let’s zoom in on those aspects of a DAO that are most self-evidently coordinated on a blockchain: managing money (a treasury) and voting. (All of the components listed above could be coordinated on a blockchain, but we will leave that possibility where we found it for now). With respect to voting and treasury management, two main aspects influence the DAO’s security: the smart contracts the DAO uses and the chain itself.
The smart contracts are within the DAO’s control. The DAO can audit its contracts and, when a vulnerability is discovered, upgrade itself (assuming the DAO has an upgrade path, which DAO DAO DAOs do). But what about the chain itself—the substrate upon which the whole DAO runs? If that chain goes down (as chains sometimes do), the DAO too will be down.2 It will not be able to update its canonical state. Even if the DAO ran its own chain (or was its own chain), halts may still occur due to bugs or active attacks. Unlike attacks on smart contracts, which mutate a DAO’s state in an unanticipated and undesired way, chain halts prevent a DAO from updating its state at all—a risk at least as serious if not more serious than smart contract attacks, after or during which the DAO at least stands a chance of recovering its pre-attack state through governance. During a chain halt, by contrast, a DAO is “off.” It might as well not exist.
What’s a DAO to do about the risk of a chain halt? One appealing option might be to exist on more than one chain. Running one’s DAO across multiple chains—ideally with partially independent validator sets and perhaps even multiple software stacks exposing the same virtual machine (VM)—lowers risk. Specifically, the risk of a DAO suffering during a chain halt declines as the chains on which it runs have (1) less overlap in their validator set and (2) less overlap in their technology stack. The risk caused by a validator or cohort of validators that chooses to misbehave would not cascade as easily across chains thanks to (1), and exploits targeting one stack would be less likely to threaten others thanks to (2). So long as the DAO’s contracts run on all chains—on top of a shared VM, for example—a DAO’s risks shift back to its contracts and the VM itself—risks a well-resourced DAO can more easily manage.
To make this principle more concrete, let’s imagine that this well-resourced DAO, armed with its well-studied contracts and battled-tested VM, waved its magic wand and willed three chains into existence. One chain might run the Cosmos SDK, like Juno. Another might run Cosmwasm on top of the CW SDK. The third might implement Wasm smart contracting on top of a CosmWasm VM on Polkadot. All three chains should have only partially overlapping validator sets. The DAO could then deploy itself across all three chains, using IBC to synchronize its state (membership, voting power, etc).3 In such a world, this DAO could continue functioning even if one (or two!) chains halt! It could recover itself on the other chains, running in a moderately degraded (specifically, less secure) state in the meantime.
At the chain layer: A mesh of increased price stability and fungibility across native tokens
Before pondering what effects such an “Interchain” DAO might portend at the application layer, let’s first focus on its potential effects at the chain (i.e., compute) layer. The DAO, always needing to synchronize its state across chains, must constantly perform transactions on those chains to synchronize. As such, it has an incentive to (1) maintain liquidity across chains (2) create price stability in all chains it uses. This does not necessarily mean the prices of all these chains would be the same (though they might converge upon a similar price in some circumstances). Rather, it implies that the exchange rate between chains’ native tokens is better (from the DAO’s view) fixed over time.
The effect of these two incentives, when Interchain apps and DAOs predominate, would yield a world in which relative demand between chain tokens would reflect DAO and app preference across chains (due to performance or other differences). It would, in other words, increase competition between chains, which should create a more dynamic market, with multiple providers performing in various niches (e.g., storage, private compute, etc). Contrast with today’s world, in which potentially competing chains (e.g., Solana and Aptos) cannot be evaluated and swapped out flexibly by apps or DAOs.
Now imagine a world in which not just this DAO, but all highly valued DAOs and DAO-run apps exist across multiple chains. Although particular DAOs and apps may run on different chains, the aggregate of partially overlapping chain usage creates a “mesh,” within which demand for native tokens is relatively correlated, and outside of which demand is relatively less correlated. A maximally Interchain world would be one of commodified compute chains, competing to meet DAO and app needs.
At the application layer: mesh security
With that, our attention turns “up” the stack to applications. Both DAOs and applications exist at this layer. As I hinted earlier, DAOs may have complex relationships between apps, chains, and one another, the diversity and nature of which future work might ponder. What we can say today with confidence is that, in an Interchain world, apps and DAOs that use the same chains share an interest in the security of those chains.4 A critical question emerges: can those DAOs and apps secure those chains against economic attacks more efficiently than by staking tokens individually across each chain? The answer turns out to be "yes:" using cross-staking, an actor on one chain can provide security to several chains with a single staking action.
Here, we see the outlines of a mesh that secures itself, with the shape of that mesh (think: the specific graph of cross-chain relationships) driven by coordination at the application rather than the chain layer. Though chain governance too may reap a benefit from cross-staking, it is consumer demand at the application layer that should ultimately drive demand for chains’ native tokens. This—the notion of organizations that share incentives to secure particular chains—is the essence of mesh security. Patterns of demand across populations of organizations create a mesh of sovereign chains, securing one another economically and through governance.
A computational commons with a mesh governance protocol
If DAOs desire (and are able) to run across chains, we expect to see a few effects at both the chain and application layers. At the chain layer, we expect patterns of application-layer demand to produce a “mesh,” within which demand for native tokens is relatively correlated, and outside of which demand is relatively less correlated. At the application layer, we expect these same patterns of demand produce shared incentives for security, with even organizations that compete with each other (e.g., for marketshare) motivated to cooperate to secure the chains they mutually run on.
Across many chains, these effects would yield a computational commons: a common pool of computational resources that serves the mesh of applications and DAOs. Dreams of a single chain functioning as a global computer seem, for now, dashed by practical constraints. And, even if these practical constraints were solved by computer scientific breakthroughs, the vision of a global computer would still struggle to react to local needs and concerns. Where the global computer vision mirrors debates about a world government, mesh security provides a different means of achieving a similar end, one more analogous to the anarchistic vision of small communes in confederation: a mesh of affiliated chains join in a flexible configuration that, through emergent properties, co-constructs a shared pool of computing resources.
Interchain DAO tooling, then, could take the form of a mesh governance protocol that coordinates the computational resources upon which it relies. Through this protocol, the governance and application layers co-exist and co-create one another in an interdependent ecosystem of mutual aid.
Returning to the parachute
I mentioned at the beginning of this piece the image of a cooperative parachute game. The core lesson of this story—that up-front coordination can yield a self-sustaining reaction—is the essence of my theory of the Interchain. Initial (and perhaps unlike the parachute game) complex and emergent coordination can, like the genesis of life from the primordial soup, give rise to a stable, competitive, antifragile ecosystem. Guided by governance, the tools that provision coordination could too become self-sustaining, themselves coordinating at the highest level to form a self-regulating (in the cybernetic sense) economic union.
I wrote this post with Jake Hartnell. Thanks to Amber Case, Zeke Medley, and Noah Saso for the thoughts, feedback, and conversations.
Thank you for reading. This blog is free without a subscription thanks to my delegators. To support my work, delegate to elsehow on Juno or Stargaze.
The vision of the interchain—sovereign chains in free association—is analogous to the autonomous systems in free association that make up the internet. As originally imagined, IBC is analogous to TCP/IP: a generic mechanism for exchanging data across applications. In our vision of the Interchain, IBC is better compared to BGP than to TCP/IP. Rather than serving as a standard protocol for transmitting application data, it instead serves as a protocol that allows sovereign units (web1: autonomous systems, web3: chains) to voluntarily cohere together into a more abstract and robust whole (web1: Internet, web3: Interchain).
If there were ever a chain halt that somehow proved permanent, that chain could export its last valid state and recreate the DAO on another chain. Still, applications on top of that chain will be halted until recovery.
This DAO could perform state transitions across multiple state machines.
There’s an analogy between this argument and those 20th-century arguments that free trade would reduce conflict, as mutual reliance increases the cost of attack. On-chain and off, we will live through the history that bears out or refutes this hypothesis.