← Back to all posts

Sovereign Chains: The Cosmos Thesis, Four Years On

Onomy's 2022 'Cosmos thesis' argued that building your own layer 1 buys sovereignty: your uptime, your fees, and your rules stop depending on other chains. Re-read as an engineering argument, the essay is really a decoupling claim — and the four years since (Replicated Security on the Hub, dYdX v4's app chain, Onomy itself becoming a shared-security provider) show that sovereignty is not a property you own wholesale. It is a boundary you draw layer by layer: which rules you own, and which dependencies you rent.

cosmoscosmos-sdksovereign-chainsapp-chainsibcreplicated-securitymevblockchainarchitecturesovereigntyessay

In June 2022, in the middle of a bear market, the Onomy Protocol team published a five-minute post titled A Cosmos Thesis: Why Sovereign Chains?. It is a project blog with a product to sell, and it is easy to skip for that reason. That would be a mistake. Read on its own terms, the essay is one of the cleanest short statements ever written of the engineering claim underneath the entire app-chain movement — and it is a rare case where the essay's own author later demonstrated the limits of its thesis in practice. This post rereads it four years on: what it argues, what it gets right, where it cheats, and what the history since June 2022 did to its conclusion.

What the essay says

The argument has five moves, and each is worth stating faithfully before criticizing it.

First, sovereignty is defined as full-stack control. Building a layer 1 means a blockchain "can retain complete sovereignty over its operations":

Its validator set, its consensus, its uptime, its throughput and its security can all be defined by the progenitors of the blockchain itself, without having these inhibited by, or reliant upon, the performance of other blockchains and protocols.

Note the definition is negative twice over: not inhibited by and not reliant upon. Sovereignty here is not a list of powers; it is an independence claim about the chain's operational variables — validator set, consensus, uptime, throughput, security — being functions of its own choices rather than of someone else's system.

Second, Cosmos is the tooling for the job because it separates the layers. Cosmos is framed as "an interoperable network of sovereign blockchains that set their own rules, while using the IBC to establish a shared communication protocol," where IBC is explicitly opt-in — chains choose their trading partners. The essay's key architectural claim is that "Cosmos-built blockchains split the governance of blockchains into two layers: the application layer and the underlying environment." The Cosmos SDK is the modular toolkit (staking, governance, custom modules) that makes the application layer cheap to build, and each resulting chain "is sovereign unto itself, works by itself, and validates itself with no reliance on the Cosmos network itself functioning." The analogy is deliberate and good: chains are sovereign nations, IBC is the trade-route network between them, and a nation's internal functioning does not depend on the trade network's health.

Third, the failure-dependency argument — the essay's sharpest point. Protocols on a shared chain inherit that chain's fate:

Through no fault of the protocol's own, that DEX won't work while the 'parent' blockchain is out of action.

The examples are 2022 vintage — a Solana outage taking down every DEX on Solana, Ethereum gas spiking "due to congestion" and degrading dApps because of "the other activity on the network" — but the generalization is timeless: "dApps are in thrall to their parent networks." The essay identifies the mechanism precisely: when the application layer and the governance layer are intertwined, the application's performance and availability are stunted by governance and usage decisions made by strangers. A sovereign chain decouples them.

Fourth, sovereignty is a performance argument, not just a control argument. Because an application-specific chain's "entire codebase is geared towards the execution of one function," it can operate at the speed its workload needs — Onomy's stated case being a hub for Forex trading — while staying connected through the shared IBC environment rather than being "cut off from the rest of the blockchain economies it relies upon." Specialization without isolation: the scalability of splitting, the connectivity of sharing.

Fifth, MEV resistance as a governance property. The essay defines MEV — value extracted by "reordering, inserting, or censoring transactions within a block" — and argues sovereign chains are structurally more resistant to it, for two reasons: chain makers "can enforce rules that stop it occurring," and a solitary application is "rather than a soup of all transactions on the entire Cosmos (or any other environment) chain," so there is far less opportunity for the "invisible tax" to occur, and it is "easier to stamp out when it does."

The essay even concedes the objection, in a section titled "King of the Castle": a separate validator set "needs to be trusted," and it is "harder for developers to launch their own layer 1 chains rather than simply plugging the products into the Ethereum or Solana ecosystem." Then it waves both away — the validator issue "ceases to be an issue" if the set is "sufficiently decentralised and incentivised," and sovereignty is worth the launch cost anyway.

Reading it as an engineer: the decoupling claim is the real thesis

Strip away the Cosmos evangelism and the essay is making one engineering argument, and it is the right one: deploying an application onto a shared substrate means your availability and your cost become functions of other tenants' behavior. A dApp on a congested chain does not fail because it is badly built. It fails because a stranger's NFT mint spiked the gas market, or because the parent chain's validators had an outage, or because a governance vote the dApp had no voice in changed the environment it runs on. When you rent blockspace, you are not renting a service — you are accepting a correlation structure. Your SLA is somebody else's SLA, and your unit economics are somebody else's demand curve.

This is a familiar shape outside crypto. Any system deployed on a shared platform whose other tenants can degrade its availability or its cost has outsourced part of its own specification to strangers. The app-chain thesis is the claim that this correlation is not an acceptable tax when the application is the product — that there is a size of application at which owning the substrate is cheaper than renting it, exactly the calculus this site worked through in Own the Blockspace: renting is cheaper in every dimension until the rent is the product risk, and the test is "would renting blockspace cost me more than owning it."

The essay's "two layers" claim is the same insight from the modularity side. Separating the application layer from the underlying environment is not an organizational nicety; it is giving the application its own governance boundary — its own upgrade cadence, fee policy, block time, and rule set — instead of forcing it to share one governance process that must reconcile every tenant's needs and therefore moves at the speed of its slowest compromise. A chain that "validates itself" can also change itself on its own schedule. That is what ownership means operationally, and it is why the same independence argument resurfaces, in different clothes, in AI sovereignty: control is what a provider grants you inside its walls; sovereignty is what remains possible when the counterparty acts against you. On a shared chain, the app's answer to "what happens when the platform changes the rules" is: nothing, you are a tenant. On your own chain, the answers — fork, migrate validators, upgrade — exist, even if they are expensive.

Where the essay cheats

The essay is honest about its tradeoff but dishonest about its magnitude, and four years of history supply the corrections.

Sovereignty relocates dependence; it does not remove it. The essay's negative definition — not inhibited by, not reliant upon — quietly drops the one dependency every sovereign chain keeps: its own validator set. Rent from a parent chain is replaced by a new set of counterparties, and the new counterparties have the same powers as the old ones: they order transactions, they can censor, they can stall the chain, and if they collude they can capture it. The "king of the castle" section acknowledges this and then dismisses it with "if sufficiently decentralised and incentivised" — but that if is the entire engineering problem. Bootstrapping a validator set that is both decentralized and incentivized is the hardest thing a new chain does, and most small chains fail it; the essay treats the hard part as a footnote. (This is precisely the pain point Replicated Security was built to market against, as discussed below.)

MEV is not abolished by sovereignty; it is relocated. The essay's second MEV argument is right in an important way: a "solitary application" has a smaller and more homogeneous mempool, so cross-application arbitrage surface shrinks. But the extraction game does not disappear because the chain is application-specific — it moves inside the chain. Any chain with a mempool and block proposers has an ordering game, and the proposers are the chain's own validators. What sovereignty actually buys is not MEV-freedom; it is rule-making authority over the ordering game: the right to set mempool policy — batching, commit-reveal, threshold encryption, a block-builder auction — rather than inheriting someone else's. That is a governance power, not a structural immunity, and it is a power the chain's own governance must then exercise wisely. (The essay's supporting example, that the Cosmos Hub batches transactions, is itself a policy choice by one chain's governance, not a property of the SDK.) The distinction matters because MEV is not a bug that sovereignty patches; it is a tax whose collector your governance gets to choose. This site's DEX series goes through the mechanics — frontrunning and sandwiches are ordering games that exist on any chain where block proposers have discretion.

Specialization, not decentralization, is the performance story. The essay implies that sovereignty makes chains "lightning fast." Careful: a CometBFT chain finalizes in seconds because of its consensus design, shared across every SDK chain, sovereign or not. What sovereignty changes is the fit: an order book can implement native matching, a DEX can pick fast blocks, an oracle chain can put price feeds in the protocol — no generic VM, no external demand shocks to the fee market. The speed is the speed of specialization, and it is real, but it is a property of the workload and the codebase, not of independence itself.

What happened after the essay

The four years since June 2022 turned the essay's binary — sovereign chain or tenant — into a market of partially owned layers.

Security became rentable. In March 2023 the Cosmos Hub launched Replicated Security, letting consumer chains borrow the Hub's validator set. The validator-bootstrapping bottleneck the essay waved away in "King of the Castle" was productized: a chain can now be fully sovereign over its application and governance while renting its security from a provider whose validator set is already decentralized and incentivized. The sovereignty frontier stopped being "do you run your own validators" and became "which layers do you own."

The specialization argument went into production at scale. In October 2023, dYdX — a protocol that had been one of the largest tenants of a shared chain — launched v4 as a standalone Cosmos layer 1, to own its matching engine, its latency, and its ordering rules outright. The largest real-world validation of the essay's claim that an application whose core is throughput and ordering should own its substrate.

And then the essay's author chose shared security. This is the detail that makes the 2022 essay worth rereading. In June 2023 the Onomy DAO voted to adopt Replicated Security, and in April 2024 — roughly two years after publishing "Why Sovereign Chains?" — Onomy became the second provider chain in the ecosystem, launching its Onomy Exchange consumer chain over the shared security of its own expanded validator set. Their own post states the reason in the essay's own vocabulary: before Replicated Security, to launch an app chain a team had to "invest significant resources into onboarding validators that would secure and decentralize the network" — which "represented a bottleneck for early-stage teams that were stretched thin."

Read the two posts back to back and you get the complete argument the first one left out. Onomy did not abandon the thesis; it refined it. The team kept sovereignty where it matters — application logic, governance, tokenomics, the fee market, the rules of the DEX — and rented the one layer whose bootstrapping cost was killing them: the validator set. Sovereignty turned out not to be a property you own wholesale by building a layer 1. It is a boundary you draw, and the boundary can run through the stack: own the app, rent the security, connect by IBC.

Why the reread matters for agents

The Cosmos thesis has a second life that the 2022 essay could not have predicted, because it is about who — or what — the tenants are. MEV bots were the first autonomous economic agents, and they were running on shared chains precisely because the ordering games there were worth playing. As more agents become economic actors — placing orders, holding assets, executing strategies — the tenant problem compounds: an agent renting execution on a shared chain inherits not only human congestion but other agents' games, and it cannot change the mempool policy, fee market, or governance that those games run on. Sovereign execution for an agent means its rules are embedded in its own chain rather than rented from a platform whose other tenants — human or machine — set its environment. That is the argument of Cosmos SDK is the substrate for AI agents, and it inherits both the strength and the caveat of the 2022 essay: the agent gains sovereignty over its application layer, and gains a new dependency on its validator set — which, post-2023, it can rent instead of bootstrap. The line back to this site's older argument is direct: blockchains matter for agentic software because they make a mechanism's rules visible and programmable rather than opaque platform policy — and a sovereign chain is the strongest form of visible rules an agent can run on.

Key insight

The Onomy essay's question — why sovereign chains? — is right, and its answer is too simple, in a way that its own author's later history corrects. Sovereignty is not a binary you buy by running your own layer 1. It is a decoupling claim: a sovereign chain's availability, cost, and rules are not functions of strangers' behavior. That claim has three true parts — full-stack control over your own operational variables, a governance boundary around your application layer, and rule-making authority over your own ordering game — and one hidden cost: the dependency you keep (your validator set) is as real as the one you escape. Four years of history productized exactly that cost, and the market answered the question the essay dodged. Security is rented (Replicated Security, dYdX's own set, Onomy becoming a provider chain). Application, governance, and ordering rules are owned. The sovereignty that matters is ownership of the rules — and the boundary between what you own and what you rent is now a design decision made layer by layer, not an all-or-nothing existential choice. The 2022 essay saw the boundary's existence. Its author's 2024 choices show where it should be drawn.

References:

Engineering treats every system as a set of dependencies and asks which ones you can afford to own. The Cosmos thesis is that argument applied to blockchains: the shared chain is the dependency you cannot hedge by being well-behaved, because its congestion, its governance, and its outages are functions of strangers. Building your own chain hedges that dependency — and creates the next one, the validator set, which the market has since made rentable. The engineer's move is not to seek the system with no dependencies, but to choose, layer by layer, which dependencies are worth owning.

Sovereignty is not a property you buy by building a chain. It is a boundary you draw — between the rules you own and the dependencies you rent. The 2022 essay saw the boundary's existence. The years since showed where to draw it: own the application, rent the security, never outsource the rules.