CHIPs signaling phase: Babylon x Cosmos Hub [Deprecated]

[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…

Excerpt (1197 of 6322 characters). Read the whole post on the forum ↗

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)

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.

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).

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.

@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: • 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. • 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. • 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. • Slinky has been audited three…

Excerpt (1199 of 1538 characters). Read the whole post on the forum ↗

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