osmosis

Prop 437: Babylon signalling and phase1 Integration

Proposal Doc: https://docs.google.com/document/d/1Lx7MkpZh9pZy-XumReohvpGUf6gjSapFnRyG868b49o/edit?usp=sharing

  1. Summary

Babylon proposes a 3-phase integration to allow Osmosis to leverage the security of the Bitcoin network and enjoy benefits such as fast stake unbonding and extra security for high-valued transactions. This signaling proposal serves a dual purpose: it not only signals the Osmosis community's intent to integrate phase 1 shortly after Babylon mainnet, but also provides a clear roadmap for the integration process. Phases 2 and 3 will be specified and voted for by the community in future governance proposals.

CommonWealth forum post: https://commonwealth.im/osmosis/discussion/9967-babylon-integration-proposal-with-osmosis

We have created an FAQ based on the feedback we received from the community which can be found here: https://docs.google.com/document/d/1x1NmMZZTtWPJRWJXwPtAWIykAPDmPaZx4OgyL8fS2ik/edit?usp=sharing

  1. Overview

The Babylon project allows PoS chains to leverage Bitcoin security. Babylon uses Bitcoin to timestamp critical PoS consensus data (such as headers with quorum certificate). This secure timestamping resolves a fundamental security threat to PoS chains that allows attackers to fork the chain without being slashed, known as the long-range attack. But Babylon doesn’t just protect against long-range attacks. The same secure timestamping also improves the security dynamics for Cosmos PoS chains. To name a few: It allows for a shorter unbonding period without impacting the PoS chain’s security. It allows Osmosis clients to enjoy additional security for important high-valued transactions. It also allows for easier state sync and snapshot verification for node operators. It can also help with the IBC client initialization and verification, which is particularly important for Osmosis.

  1. Additional Context

Babylon has conducted several events around Bitcoin security for Cosmos with Osmosis and Juno among others. There has been strong Cosmos community support for these efforts with 150+ people signing up for these events. Sunny from Osmosis has spoken at these events with great community receptivity from both the Babylon and Osmosis communities. 3. Summary of the Three Phases of Integration Babylon proposes a 3-phase integration to allow Osmosis to leverage the security and availability of the Bitcoin network. At its core, Babylon verifies Osmosis’ critical consensus data (called checkpoints) submitted by IBC relayers and aggregates the checkpoints for secure Bitcoin timestamps. The table below summarizes the integration phases. In particular, Phase-1 integration is permissionless, since it only involves a standard IBC connection without any code changes to Osmosis. Yet it can already unlock Bitcoin security for Osmosis. All the integrations will be thoroughly reviewed and tested on Osmosis testnet first. Separate governance proposals will be submitted for mainnet integrations.

Three Phase Table https://docs.google.com/document/d/1VF2xpu0reAbBHfNz4dult8DrPux-mnTZx3qP9SWQsug/edit?usp=sharing

The Babylon integration will not impact the infrastructure and operations of Osmosis validators and relayers. It will provide extra information and tools that help them secure the network.

  1. More Details about the Integrations

Phase-1: The Oracle

IBC relayer’s client sync functionality will automatically submit Osmosis’ signed headers to Babylon. These headers will enter the Babylon ledger and be verified, and will receive secure BTC timestamps. Then any Babylon node can serve as an oracle for queries about: the BTC-finalized Osmosis headers whether there were long-range attacks to Osmosis This information provides objective trusted heights and headers that allow Osmosis node operators (such as validators) and IBC relayer operators to bootstrap and verify Osmosis full nodes, light clients, and snapshots. It also allows Osmosis’ counterparty chains to verify their Osmosis IBC client. Below is an example API call to a Babylon node for the query:

https://:/babylon/zoneconcierge/v1/finalized_chain_info/{chain_id} The Babylon team will also maintain an API server and web service for better visualization and usability. For example, Babylon’s web service can display real-time updates of the partner chain’s latest information. The Babylon team will also provide additional standalone tools to verify the correctness of any Babylon nodes. Phase-2: On-Chain Automation The Babylon team will work with the community to design and develop an IBC application module that handles BTC timestamps and associated proofs sent by Babylon. Osmosis will import this module to its App struct. The module will work standalone and thus will not require changes to other codes, nor impact existing functionalities. Compared to Phase-1 where Osmosis users will need to access Babylon oracle nodes for Osmosis’ BTC timestamp information, this phase will enable the following on-chain automation: automatically decide the latest headers finalized by BTC automatically detect and alert any forking attacks on partner chain observed by Babylon This phase will also be an enabler of Phase-3 integration, which utilizes the on-chain BTC timestamp information.

Osmosis x Babylon Genesis swap

In order to foster a sense of cohesion and shared purpose between our communities, Babylon will be implementing a strategic initiative during Phase 2 of our project. As part of this initiative, we will be requesting token swap. These funds will be added to Babylon's community pool and will be utilized to support the growth and development of the Babylon partnership with Osmosis.

Key components of this initiative will be the delegation and staking of the acquired OSMO and bootstrapping liquidity pools. This will not only help to secure the network and support the underlying blockchain, but will also provide a way for Osmosis to actively participate in the growth and success of Babylon. By ensuring that the genesis swap is being used to support both ecosystems, we believe that we can effectively promote alignment and a sense of shared ownership among our communities.

Overall, this initiative is a crucial step towards building a strong and united partnership, and we are confident that it will play a key role in the long-term success of Babylon and integrations of bitcoin security on Osmosis. Details of the genesis swap will be included in a future prop (phase2).

BABYLON/OSMO liquidity bootstrapping pool on Osmosis Babylon available on Osmosis Aligned success for both communities Diversify both babylon and Osmosis community pool

Phase-3: Unbonding Time Reduction

The Babylon team and Osmosis team will work together to hook Osmosis’ staking module with the IBC application module imported in Phase-2. The stake unbonding/undelegating request approval conditions will be updated to include the associated Osmosis block’s BTC finalization information provided by the IBC application module. The BTC finalization time will be a configurable parameter. It enables a configurable stake unbonding time that can be as short as 15-30 hours, which is much shorter than the current 14 days. (The Babylon team is also researching other use cases of BTC security with the community.) 5. Pro's of this Proposal Better security for Osmosis Osmosis will become BTC secured with BTC-assisted node / light client bootstrapping and verification enabled, which is particularly useful for Osmosis validator and relayer operators Optionally, much shorter unbonding time (as short as 15-30 hours, and is configurable by Osmosis) may increase the number of Osmosis community members (especially OSMO stakers such as validators and delegators) because it gives them higher liquidity and can also significantly reduce the “idle” capital that does not earn yield due to the unbonding period. Babylon community will engage with Osmosis, increasing usage, community engagement and TVL More institutional players may engage with Osmosis due to increased security of the chain through the Babylon integration increasing TVL The integration will increase censorship resistance of Cosmos zones including Osmosis 6. Cons of this Proposal Having a steady stream of IBC transactions will somewhat increase the size of osmosis blocks. The additional size per Osmosis block will be in the order of the Osmosis header size. There will be additional development and relaying commitment, but Babylon is partnered with Cosmos’ leading relayers.

Voting By voting YES on this proposal, OSMO stakers to show their intent for integrating phase 1 upon Babylon’s mainnet launch and signal support for the direction of Phase 2-3 integrations

By voting NO on this proposal, OSMO stakers voice their dissent in enabling Phase 1 integration or do not support the direction of Phase 2-3 integration.

By voting ABSTAIN on this proposal, OSMO stakers voice no strong opinion on the matter.

By voting NOWITHVETO on this proposal, OSMO stakers contribute to a 1/3rd threshold that will cause this proposal to fail, and the deposit to be burned.