CHIPs signaling phase: Babylon x Cosmos Hub [Deprecated]

Hub Proposals Signaling/Text
1

[NOTE: We’ve opted to pursue a simplified integration with Babylon instead of the design in this post. More details here: CHIPs signaling phase: Simplified Babylon x Cosmos Hub]

This is a signaling prop to approve a technical specification to bring Bitcoin security from Babylon to the Cosmos Hub and its consumer chains.

The basic idea remains unchanged since the discussion post several months ago, but we now have a concrete specification of a technical implementation. We’ll reiterate some of the material from the discussion post to explain the high level concept, and then get into the technical details further down.

We are currently focusing on integration with Babylon, but the architecture we are building is very general and will also let the Hub aggregate security from other providers such as Eigenlayer and more.

NOTE: There is one small difference from the discussion post. Instead of claiming rewards directly on the Cosmos Hub, Bitcoin stakers will claim rewards on Babylon’s chain. This eliminates the need for the Hub to store data about a very large number of delegations on Bitcoin, and also allows the design to be more congruent with what will be required for other integrations such as Eigenlayer.

Overview

If it is approved by Hub governance, security aggregation using ICS and Babylon will work with a CometBFT extension which will be added to both the Cosmos Hub blockchain and all consumer chains. This will allow the Babylon scripts on the Bitcoin blockchain to detect when a validator double signs. Bitcoin stakers will be able to select a Hub validator to stake to, and their staked bitcoin will add to that validator’s power on the Hub, and any consumer chains that validator is opted into.

One important thing to note is that this does not introduce any new trust assumptions. Babylon’s Bitcoin staking protocol does not require bridging and is trustless and self-custodial.

Every consumer chain will be able to set a security budget for each asset being restaked through the Cosmos Hub. For example, a consumer chain might decide to allocate 75% of their rewards to their native tokenholders, 15% to ATOM security, and 10% to restaked bitcoin. On top of this, consumer chain rewards going to Bitcoin restakers will be subject to a small tax which goes to ATOM holders.

To claim their rewards, bitcoin holders will need to create a Cosmos wallet and withdraw the rewards on Babylon chain. This will onboard them to Cosmos. For many of them it may be their first experience on a blockchain other than Bitcoin.

So to sum it up:

  • Babylon’s Comet extension will be installed on the Cosmos Hub and all its consumer chains.
  • Bitcoin holders will be able to delegate to Cosmos Hub validators, and will earn rewards.
  • Consumer chains will be able to select how much of their security budget goes to ATOM vs Bitcoin.

Technical Specification

image
image3022×2472 569 KB

This is an overview. Full details are in the ADR.

The integration consists of 4 main parts:

  • Babylon’s Bitcoin Script code, which lives on Bitcoin and allows BTC to be staked on Cosmos Hub validators. It will slash BTC delegators if their chosen validator double signs. Double signing evidence which can be read by Bitcoin is generated with a CometBFT extension.
  • An oracle powered by the Slinky oracle framework. This oracle monitors the state of Babylon’s scripts on Bitcoin, and tracks how much BTC has been delegated to each validator. It is run by the Cosmos chain’s own validators and requires no trust assumptions on external chains or other trusted systems.
  • Several Cosmos SDK modules running on the Hub. These module take information from the oracle and combines it with the Cosmos chain’s own native stake to derive the final powers for each validator on the chain.
  • The Babylon chain, which receives staking rewards from the Hub and allows Bitcoin stakers to claim them.

Slinky Oracle

Slinky is an oracle framework that uses a Cosmos chain’s own validator set to run an oracle which can bring in outside information. Because the chain’s own validators run the oracle, the trust assumptions are much better than a typical oracle, especially with such a sensitive subject as a chain’s own security.

NOTE: one Slinky sidecar process run by validators will be able to handle all of the Hub’s oracle needs, including this application, an upcoming initiative to bring price feeds and perps to Neutron, and any other oracles in the future.

The oracle accesses an Ethereum node, and queries Babylon’s Bitcoin scripts. It gets two pieces of information: How much BTC stake each Cosmos Hub validator has, and a price feed of the price of BTC in ATOM.

Oracle data feed:

ValidatorPowers:
	- <validator key>: <staked btc>
	...

ATOMToBTCPrice:
	- <ratio>

Cosmos SDK modules

The Cosmos SDK modules have two main functions: power mixing, and reward distribution.

Power mixing

Power mixing is the process by which stake coming from external sources is combined with stake coming from the Cosmos chain’s native staking module to determine the relative power of the validators. This validator power is then passed to the CometBFT process underlying the Cosmos chain. A power mixing function takes two or more validator sets and returns one validator set.

powerMix(setA, setB) -> mixedSet

This mixed validator set is then sent to the CometBFT consensus process underlying the Cosmos chain where it sets how much voting power each validator has to approve blocks.

Reward distribution

The reward distribution module takes rewards coming from consumer chains and the Cosmos Hub’s inflation, sends the proper amount to ATOM stakers, takes a small tax from the rewards sent to BTC stakers, and sends BTC rewards to Babylon over IBC to be claimed there.

Conclusion

Together, these technologies will allow the Cosmos Hub and its ICS chains to be secured by bitcoin staked directly on the Bitcoin chain. This will provide more security, as well as enabling a whole new market of Bitcoin L2s to launch on the Cosmos Hub.

Although our current focus with this initiative is Bitcoin, the technology will also be flexible enough to use with other ecosystems, such as Eigenlayer on Ethereum, to aggregate other sources of security on the Cosmos Hub.

13 Likes
2

It feel like we are adding complexity over and over to serve few developers interest but not providing much more return for stakers or validators.

Is there any return comparison including cost and efforts to run all of these services for validators and return for stakers with or without (including fees taken by third parties)

4 Likes
3

Fair question. This will require validators to run a Slinky oracle sidecar process. This will actually be the same sidecar that will be required for Neutron’s Slinky oracle, which will supply price feeds on Neutron. So the more use cases for the sidecar, the more its operational cost is amortized.

The benefit of this Babylon integration is not only to bring more security to the Hub, but also to bring in more prospective consumer chains. Security is not only about security, but also about alignment. Having Bitcoin as a staking asset will let us offer an attractive product to teams building Bitcoin L2s. We already have a consumer chain joining based on this integration- Lorenzo, a Bitcoin liquid staking token. This same code will also be used for other ecosystems such as Eigenlayer on Ethereum. I think it will be important to trying make the Cosmos Hub the best place to launch a chain not only within Cosmos, but also for projects coming from outside of Cosmos and looking for security from their native tokens.

8 Likes
4

I’m sorry but that’s not answering a single part of the above comment.
Also, did you went into the integration process and maintenance of the current version of slinky?
On one chain it’s already a mess, adding also centralisation over providers (less than a full set - eg 4 on dYdX test) and also decentralisation complexicity of reaching each parties for their api.
I’m not convinced on the benefits, as a stakers (as you didn’t answer with current numbers), and as a validator (as I didn’t see any audit, live testing and specific accurate benefits for us to run it in terms of cost).

1 Like
5

Is there any return comparison including cost and efforts to run all of these services for validators and return for stakers with or without (including fees taken by third parties)

I can’t give you hard numbers because we have not launched the integration yet. But like I said, this lets us address a growing market of Bitcoin L2s, which has already had an early dividend by allowing us to sign on Lorenzo, a Bitcoin LRT. This architecture is also very flexible and will allow us to easily hook up Eigenlayer and others.

I have not run or worked on a chain with Slinky. However, I built and helped launch Gravity bridge and Sommelier, two chains using a much more primitive sidecar process, over 3 years ago. On Gravity bridge we had a very low market cap token with very low staking rewards, run mostly by hobbyist validators, and everything seemed to be fine. I assume the Cosmos Hub validator set, earning millions of dollars in rewards, could run a sidecar as well. However, this signaling proposal is going up for a vote in two weeks and if it is rejected we will stop work or rethink the architecture.

1 Like
6

@Zdeadex not trying to push the Hub one way or another, but that’s a pretty unfactual description of what’s happening on the dYdX Slinky integration, and Slinky more generally. Probably our fault for not being more clear about this, but here’s some info that might be useful:

  1. The issues on testnet were not caused by Slinky, they were caused an IAVL bug that was triggered by them adding the new x/vaults module, as shared in the announcements channel by the dYdX team. Happy to forward you to the issue if you’d like! It had nothing to do with Slinky.

  2. Slinky runs on each validator, not just 4. All validators will run it, and so it’s as decentralized as the network is (which is impossible to do better than, unfortunately). I’m not sure where you’re getting 4 from. In fact, Slinky won’t even work if it’s on less than 66% of stake weight, like normal BFT consensus.

  3. I understand the complexity of integrating the Solana APIs on the dYdX side - to my understanding this consists of getting 5 API keys from providers already prepared to give them on Slack. This wouldn’t apply to this integration however, since we wouldn’t be using Solana APIs.

  4. Slinky has been audited three times - twice by Informal Systems, and once by OtterSec. It’s been load tested with over 2000 currency pairs on networks with over 60 validators, and has been on Berachain and Initia testnet for months with no issues.

Happy to share any of the information above, just want to make sure you have all the knowledge you might need!

Mag

6 Likes
7

I also feel like this is a super cool and complex feature. I dont really understand the value to those that build / utilize the network today/ i.e. current token holders and security providers today. I mean such development requires a lot of work and would be awesome to focus it, rather than developing everything so one day it can bring something back, maybe. Sorry for the slight passive aggression that may come across here. On the contrary - i am concerned

1 Like