[Temp Check] Add GHO to Cosmos and Polkadot through IBC

Governance New Market
1

Author:
Agustin Cortes | Tint.eth leads partnerships at Composable Finance. Here is my profile on Twitter

Date Posted: 2023-11-13

Summary
This proposal aims to articulate the process and value prop of bridging GHO to IBC connected ecosystems such as Cosmos and Polkadot. These ecosystems would greatly benefit from the support of a decentralized stablecoin that can bring liquidity and crosschain activity.

Objective
The objective of this proposal is to introduce the opportunity to make GHO crosschain into the Cosmos and Polkadot ecosystems to create an incentive loop to grow the demand for GHO, hence increasing the amount of collateral on AAVE.

Motivation
There are 3 main benefits to getting GHO to these ecosystems. The main factors are

  • Increase demand for GHO hence increasing the total supply
  • Give Cosmos/Polkadot a decentralized alternative to USDC/USDT
  • Cross pollinate Cosmos and Polkadot to AAVE ecosystem

Background
Cosmos and Polkadot collectively have a market cap of over $8 billion but lack defi activity due to the lack of strong assets generating yield. On top of that existing bridging mechanisms rely heavier on the centralized side ranging from multisigs to permissioned validators that control the bridging components. Bridging through IBC allows us to migrate GHO in the most secure and trust minimized process by solely relying on the light clients and cryptographic proofs. More on IBC soon.

Specification
To strategically bridge AAVE’s stablecoin, GHO, to both Cosmos and Polkadot ecosystems, we’d use the Inter-Blockchain Communication (IBC) protocol—a framework allowing seamless interactivity between disparate blockchains. Initially, we’d establish an IBC connection between Ethereum and Cosmos, enabling GHO’s transfer and utilization across chains in the Cosmos ecosystem. We already have Cosmos connected to Polkadot in production so we can allow for asset transfers once the assets are in the Cosmos ecosystem. Our parachain would communicate with the Cosmos IBC, forming a relay that ensures GHO’s interoperability across all three blockchains. Through this method, GHO would gain vast market access, enhancing its liquidity and usability while expanding its influence

Identified Pools with bluechip ecosystem assets (with possible incentivized emissions)

  • GHO / USDC on Osmosis
  • GHO / USDC on Moonbeam
  • GHO / Atom on Osmosis
  • GHO / Dot on Moonbeam
  • GHO / Osmo on Osmosis

Next steps

  1. Gather community feedback on this TEMP CHECK
  2. If community consensus is reached, escalate this proposal to TEMP CHECK Snapshot stage
  3. If the snapshot outcome is YAE, allocate GHO into the pools

Disclaimer:
The migration of moving GHO into Cosmos ecosystems will be facilitated through IBC and Composable Finance. More information on IBC and Composable Finance below

Security Considerations:
Composable IBC is designed to be trust-minimized and does not rely on third-party intermediaries or centralized control. This eliminates the potential risks associated with trust assumptions and enhances the overall security of cross-ecosystem bridging. Users can confidently transfer assets and data between different blockchains while maintaining control and security. However the potential risks always linger and for an IBC bridge to be compromised there’d have to be a 51% on either of the connected chains. Fortunately, Cosmos, Ethereum, and Polkadot have huge staked budgets that fortify their security.

Detailed IBC Overview
The Inter-Blockchain Communication Protocol (IBC) is a protocol designed to facilitate the authentication and transportation of data between two blockchains. It operates with a minimal set of functions defined in the Interchain Standards (ICS). Importantly, IBC does not limit the network topology or consensus algorithm of the blockchains it connects, making it versatile and adaptable for use with a wide range of blockchains and state machines. The following features highlight key benefits to utilizing IBC:

i) Permissionless and Secure: IBC offers a permissionless way to relay data packets between blockchains, unlike most trusted bridging technologies. The security of IBC relies on the security of the participating chains.

ii) Modularity and Composability: IBC separates the transport layer (TAO) responsible for secure connections and data authentication from the application layer, which defines how data packets are packaged and interpreted. This modularity enables composability and the ability to design applications on top of IBC.

iii) Light Clients and Relayers: IBC relies on light clients and relayers to ensure the validity of cross-chain transactions. Relayers are responsible for scanning the state of participating chains, constructing datagrams, and executing them on the receiving chain. Light clients efficiently verify the relevant state of the counterparty blockchain.

iv) Security: IBC’s security is based on trusting the consensus of the connected chains. It also implements fault isolation mechanisms to limit damage in case of malicious behavior.

About Composable
Composable was the first company to connect a non Cosmos chain through IBC. This was through a custom mechanism to connect Polkadot and Cosmos. Our goal is to bring IBC everywhere, hence connecting to all chains. Connecting to Ethereum will be a major push in the terms of secure interoperability as we are moving away from centralized solutions and empowering users.

Conclusion
This proposal outlines the process of bridging AAVE’s stablecoin, GHO, to IBC connected ecosystems like Cosmos and Polkadot to enhance DeFi activities therein. By leveraging the Inter-Blockchain Communication protocol, it aims to facilitate GHO’s cross-chain transactions, boosting its demand and collateral utility on AAVE. Initial seeding of $500k GHO into liquidity pools with strong assets is planned to minimize price risks and maximize yield. The proposal emphasizes trust-minimized, secure asset transfers across ecosystems, awaiting community feedback to progress to the TEMP CHECK Snapshot stage for further approval.

Copyright

Copyright and related rights waived via CC0.

References

1 Like
2

I feel compelled to disclose to you guys that Composable is lying about the status of their IBC connection to ethereum. Namely, they do not have one. IBC is based on light client verification of block headers. Aside from code vulnerability risk in light clients or IBC libraries (which are substantial attack surfaces) this should be roughly as secure as verifying full blocks (we know what a block contains but not all the things it possibly could contain, so it’s still not quite the same). It would be quite an impressive technical achievement to have a cometBFT light client on ethereum! But, they do not have a light client in testing or production! What they’re saying is not true. The “testnet” linked in the post above is nothing more than a demonstration of their capacity to lie to their users, investors, and employees. Their smart contract on Sepolia has a function “verifyMembership” which should basically check if some commitment exists at a specific height in the blockchain. Instead it always returns true! verifyNonMembership also just returns true! Not only is this not a functioning IBC bridge but it’s less secure than existing, relatively intermediated bridging solutions. You can check this, its address is 0x56378f9b88f341b1913a2fc6ac2bcbaa1b9a9f9f the function is 0x33714fe4

I do not think this proposal is timely because it probably takes around 6-12 months to fully develop and audit a light client, and it doesn’t seem like they have one at the moment. But if they would lie about something like this, publicly get on stage at conferences and promise something they don’t have, then promote it and enlist their employees in the deception, then they can not be trusted as a partner, in my opinion! I hope that does not come across as uncivil; I care about security a great deal so I find this whole situation deeply troubling!

3

I like the idea of Cosmos, definitely. And we can see other assets like Sommelier Vaults, WBTC, Axelar assets… have migrated very successfully to Cosmos.

About Polkadot, I will not pronounce myself. Not familiar enough / a bit bearish on their whole ecosystem.

4


tint

4h

Currently, we’re in the testnet phase of implementing Ethereum IBC. We’re actively deploying bridge components, and you can find detailed information about our bridge architecture in our documentation here: Ethereum IBC | Composable Finance

During this testnet phase, we’re gradually releasing significant components, which might have caused some features to appear missing previously. However, rest assured that before the bridge is launched on the mainnet for production, our contracts will undergo audits, and the audit reports will be made public. This process will disprove any claims made against the reliability of our system.

To clarify, the latest version of our IBC implementation is operational on Goerli, not Sepolia, as indicated in your claims. You can test our bridge functionality here: Cross-ecosystem transfers | Trustless

Composable is the only team to have achieved a significant milestone by deploying an IBC instance outside of Cosmos, a two-year effort for our team. I kindly request that you await the audit reports and refrain from spreading FUD and unsubstantiated concerns about our work, which we’ve dedicated substantial effort to, without having the complete context. If you’d like us to run through our bridge in more detail, I’m happy to setup a call with one of our team members to explain our release process.

I encourage you to try it out here on Goerli. We welcome constructive feedback, that’s the main objective of our testnet. If you’re willing to identify yourself, we’d be more than happy to have a chat, reach me on tg @agustincortes831

5

It is nice to see that existing assets have been adopted well in Cosmos, our goal would be to get similar adoption at scale.

Polkadot has been a bit more quiet but there has been some demand for more stablecoins in ecosystems like Moonbeam.

8

Hi, thanks for the headsup in todays governance call. I think a lot people missed this because of v3 go live and holidays. So trying to get this back in peoples mind.

Right now GHO is at its peak cap, which is 35mil meaning the bucket size needs to be increased or a new facilitator needs to come up to be allowed to mint GHO.

Wouldn’t it make sense to use wGHO instead of GHO?
What are the risks if IBC encounters a problem?
How will GHO be protected?

I would also like to hear the opinion on this one from @ACI @Kene_StableLab and also our risk provider like @ChaosLabs and @Gauntlet

Overall I do think this could be great for GHO but im not familiar with IBC so I would need to read more about it. Maybe someone else is better positioned in this topic than me.

1 Like
9

Hey @EzR3aL thank you for the viewpoint, these are great questions to ask.

To answer some of your questions at the moment:

  1. Wouldn’t it make sense to use wGHO instead of GHO?

Technically it will be a wrapped version of GHO as GHO is not nativel minted on Cosmos and Polkadot. By definition we can call it wGHO or any other name.

  1. What are the risks if IBC encounters a problem?

The highest value prop that IBC brings is that it is the most trust minimized bridging mechanism as it only relies on light client verification. In summary the risk of IBC is if one of the connected chains gets a 51% attack that can create an erroneous state header. As we know 51% are extremely unlikely so its mechanisms are safe.

  1. How will GHO be protected?
    Our bridging process will allow for a lock and mint process so the supply of the bridged GHO will be determined on how much is locked. Additionally we will have oracles to keep price feeds correctly pegged to GHO on mainnet.

These are great questions and we’d love to explain things further if more context is needed.

1 Like