Peggy in the Cosmos Network
Cosmos Network has recently enjoyed a spirited Twitter discussion about the purpose and suitability of bridges for Cosmos zones. Here, we frame Sifchain’s position, made all the more relevant because of its work on Peggy, its Cosmos <> Ethereum bridge. We start by describing leadership from relevant Cosmos orgs, including the Cosmos Hub. We then consider Osmosis’s place as a leading chain in the Cosmos Network. After that, we discuss the ideal bridge architecture and the complexities with getting there. Finally, we discuss some options that exist looking forward.
It should go without saying but we have strong respect for any team mentioned in this article. All criticisms have positive intent.
Cosmos Network Product Direction
Older Cosmos Network product documentation calls for a single peg zone blockchain connected to Ethereum via a custom bi-directional bridge and the Cosmos Hub via IBC. This would allow all Cosmos engineers to focus their attention on a single bridge deployment and let them all receive the benefits of it together. We simply never had the conviction from Cosmos leadership to stand by that vision and provide the human capital and funding it needed.
Maybe that’s because of how Cosmos is decentralized, many it’s because there are too few blockchain experts and too many challenges, maybe it’s because Cosmos has strong self-imposed limits on funding projects, or maybe it’s something else. Whatever the reasons, it led to the underfunding of two different bridge projects (Peggy and Gravity Bridge) both of which took outside capital for completion which added financial complications that derailed them from being installed directly on Cosmos Hub.
In short, Cosmos Hub underfunded work that was critical to it achieving its mission to be the source for all other Cosmos Network chains, and the recent bridge debacle is related to its leadership void. Another example of the same problem is that the Cosmos Hub was expected to be a central source of tokens for all chains in the network, with every chain connecting to the Hub alone and not needing to connect directly to each other. We instead see chains using many-to-many connections in which the Hub is not particularly privileged.
The Hub is still in a powerful position and has a lot of talented contributors, but this does mean that a lot of expectations need to be re-examined and Cosmos Network hasn’t exactly conditioned itself to address these kinds of problems. It’s just solving them as they come up. The network is now arriving towards standards through what we can consider “convergent decentralization” rather than hierarchical decision making.
Osmosis Community Governance
As a rising force in the Cosmos Network, Osmosis is increasingly setting the pace for decisions that the Cosmos Hub and other Cosmos orgs like the ICF and Tendermint are not engaging in. As the chain with the most trading activity in the Cosmos Network and the most trafficked network by IBC transactions, Osmosis contains the most economic DeFi activity despite attempts from the Cosmos Hub with Gravity DEX.
Osmosis and its proxies have been floating on Twitter and other venues that the Cosmos Network, the Cosmos Hub, or other Cosmos namesakes should be renamed to highlight a lack of relative importance between the Cosmos Hub and other chains. While this stance is controversial, it’s expressed against a backdrop of critical new decisions that Osmosis is in the center of with the Cosmos Hub caught up in its own red tape.
It’s concerning here that Cosmos governance is not itself capable of managing all of its needs and another entity is stepping into that void. Osmosis doesn’t have dozens of seasoned experts like Informal and Interchain Berlin. It is being developed to be a CEX replacement first and foremost; the quality of architecture patterns in the Cosmos Network comes second or lower to Osmosis. It doesn’t have a storied history of investing countless hours of engineering cycles and financial product cycles on bridge technology.
By extension, it also doesn’t have a well-defined procedure for evaluating bridges. In a way, it’s burdened by the bridge support question because Cosmos Hub didn’t definitively answer the question years ago. Nevertheless, questions about product fit for bridges can be addressed somewhat objectively.
The Path to Ideal Bridge Architecture
In an ideal world, every chain could instantly verify the state of any other chain to which it is connected. The closest we have to that ideal is IBC, which provides a framework for spinning up bridges with double light client verification. Communications between chains should be as direct as possible, meaning any network security node (validator, miner, etc.) should be able to verify cross-chain token migrations and event data transfer without relying on a special, privileged node.
The limitation for IBC is that it’s primarily designed to work with CosmosSDK blockchains. Efforts are underway to use it for connections with other architectures like Solana, Substrate chains, and EVM chains but as of now it’s effectively exclusive to Cosmos.
The next closest compromise from the ideal is a Cosmos Network peg zone chain for importing tokens using some other bridging mechanism aside from IBC. If there were multiple zones, those zones would not import different versions of the same asset to avoid fungibility issues. These peg zones could then connect to any other chain in the Cosmos Network, letting destination chains be agnostic as to bridge selection.
No bridge actually supports the ideal architecture yet, although the Peggy team is actively researching light client verification for Cosmos <> Ethereum transactions and bridge routing to transfer tokens through other bridges pending security approvals from a Peggy DAO, among other upgrades. For now, here is a simple analysis of some compelling bridges, highlighting their strengths and where they fall short.
Optics / Nomad — Can extend to many chains but uses a reactive security model with disputable cross-chain transactions
Connext — Performs simultaneous swaps in liquidity pools on both the source and destination chain but does not support cross-chain token migrations or event data transfer of any kind
Layer Zero — Supports cross-chain event data transfer in messages that are compliant with IBC’s App Layer, but does not actually rely on full light client verification requirements in IBC’s Transport Layer
Axelar — SDK for building cross-chain bridges to connect to Axelar’s chain in the Cosmos Network but doesn’t support double light client verification between source and destination chains
Gravity Bridge — Supports cross-chain event data transfer across its Gravity Bridge Blockchain in the Cosmos Network but only supports Ethereum <> Cosmos and does not support double light-client verification. Also has cryptoeconomic security issues if deployed as Gravity Bridge Blockchain and secured only by the $GRAV token until shared security is implemented.
Wormhole — Supports cross-chain token transfer across multiple chains including Terra, Ethereum, and Solana but managed by a closed consortium of relayers
Peggy — Cross-chain token transfer between Ethereum and Cosmos with infrastructure to support arbitrary EVM chains but needs to increasingly decentralize its relayer base and does not support cross-chain data transfer.
Each bridge falls short of ideal in some way and has its own unique security risks. The bridges operate on different chains, so multiple bridges are needed for destination chains to get the widest token selection. Unless one dominates all others (and it’s hard to see how any can dominate at present), we will have a plurality of bridges.
This isn’t to say each bridge is equally close to our ideal. On the contrary, they’ll all need additional development. This means they all need capital and a long-term commitment from a well-supported dev team/community. In light of the community’s inability to actually evaluate the quality of every single bridge in real-time, a properly functioning free market can provide the next best thing by allowing the trade of bridged tokens to occur unimpeded and letting users decide.
Even the Osmosis team understood that until recently.
The Osmosis team’s plan to partner exclusively with Gravity Bridge must have only come in the past few months. It might lead to saving a few clicks in a browser wallet in a UX improvement that any other bridge could make. That product insight is dwarfed by the market’s intelligence, accumulated through several years of fair competition among bridges in an open DEX market. CEXes may not have multiple versions of the same token, but they also don’t have permissionless listing.
Bridge Monetization
It’s critical to ask questions around bridge monetization because it informs how well a bridge is likely to be able to fund the inevitable work it must do to improve its utility, reach, and security. Most cryptocurrency projects have simple monetization stories but bridges are unique because users don’t want to pay bridge fees and there are no other obvious ways to monetize bridges (though there are a few clever non-obvious ones). Bridges are primarily funded via grants that are just big enough to get a competent team to build a prototype and often not enough to get them to production or for a V2. Bridges can attempt to acquire equity or token funding but this can have mixed results as the token economics are often shoehorned in and not viable.
Peggy is currently funded by value accrual to Rowan as a DEX settlement token, a large token sale, and institutional support from VCs. Other bridges mentioned earlier can speak to similar support but it’s unclear that Gravity Bridge can; the project has hopped from team to team and grant to grant but doesn’t have a revenue generation model.
Someone may be trying to figure out a monetization strategy for the $GRAV token because it’s had a private distribution of tokens, but nothing has been announced.
https://twitter.com/fekunze/status/1487183012844425220?s=20&t=ET8mMak81wTMw6j3Ytspqg
The monetization story for the Gravity Bridge team is confusing. If Gravity Bridge is still supposed to be deployed onto the Cosmos Hub then Gravity Bridge Blockchain should be considered hobbyist or a canary chain, to be sunsetted after Cosmos Hub’s deployment of Gravity Bridge goes live. That would imply the $GRAV token not intending to compete with $ATOM for revenue generated by supporting Cosmos Network’s Ethereum traffic, so then what exactly would it be monetizing? If the Gravity Bridge team is not monetizing $GRAV then how would it compete long term with the likes of not just Peggy but others like Axelar, Wormhole, Optics, and Multichain?
Looking Forward
Sifchain is still committed to making Peggy a strong bridge for the entire Cosmos Network, eventually including improvements like Omni-EVM, double light client verification between Cosmos and Ethereum, a Peggy Chain that can support more advanced bridging, and a Peggy DAO focused on interoperability standards for Peggy Chain. It’s worth it for the Cosmos Hub and members of the Cosmos Network to reflect on the degree to which they want to lead in addressing the hard problem of standardizing bridges in a world with a plurality of bridges.
Fortunately, Osmosis and Sifchain leadership are both converging on a UX that supports multiple bridges and fungibility across them (currently called “Token Fungibility Groups”). If Osmosis is serious about giving the community a voice in which bridges it prefers, doesn’t want to cause fungibility issues with its users, and also respects market competition amongst bridges, it may need to implement Token Fungibility Groups before supporting any bridge and then turn on multiple bridges simultaneously.
Whatever it does, we hope its community takes the decision seriously. The recent Wormhole hack is just another reminder of how important it is to get bridge architecture correct. If the Cosmos Network actually does its homework, we could all coordinate on bridge technology together, actually minimize risk of cross chain attacks (social and technical), and actually maximize the risk-adjusted value of all bridged liquidity in the Cosmos Network.
Get in Touch with Sifchain
Official Channels
Media & content creators, contact us at communications@sifchain.finance.
