Babylon and Cubist collaborate to make staking bitcoin safer 

Slashing risk mitigation

When a user stakes BTC with Babylon, they operate under the assumption that the node operator, or “finality provider,” will behave correctly and thus pay out a promised yield.

“The core protocol is agnostic as to how the finality provider actually behaves,” Wahby said. “So the core protocol really sets up the incentives.”

In practice, people make mistakes.

“People do a deployment wrong, they accidentally get the Kubernetes configuration wrong, one datacenter goes down and the migration to a different data center goes haywire — and the result is they get slashed,” Wahby explained.

“And it’s not because they wanted to, it’s because they made a mistake. But we can give a stronger guarantee.”

One of the most notable additions to CubeSigner is this anti-slashing mechanism designed to protect Babylon finality providers. Support for Extractable One-Time Signature (EOTS) keys, coupled with a constantly active anti-slashing policy, protects against such violations.

Slashing will not initially be enabled when Babylon launches its mainnet, but will come in a later phase, “which will be quite a few months away,” Tse said.

Beyond security, CubeSigner’s integration with Babylon is also aimed at reducing the complexity and development time for teams building on the protocol, particularly for smaller teams that may not have dedicated security operations personnel.

Lombard, a bitcoin liquid staking protocol, is one of the first teams to leverage CubeSigner’s hardware-enshrined contracts, an offchain alternative to onchain smart contracts (which are not yet available on Bitcoin).

Other dapps are going after the same market in a different way. For instance, Atlas Protocol looks to leverage Near’s new Chain Signatures scheme to facilitate BTC liquid staking on EVM chains.

Tse argues that smart contract risk is limited both in probability and scope with Babylon.

“One thing about Bitcoin — you may argue that Bitcoin get[s] a stupid chain because it doesn’t have smart contracts,” Tse said. “Because it doesn’t have smart contracts, you’re forced to write a very simple contract using the scripting language, and that’s exactly what we achieved — a very simple scripting contract.”

The lack of a centralized custodian meanwhile ensures that money at risk is limited to each individual staker.

“In fact, the risk is very decentralized because every stacker manages their own key. So therefore if you do manage to hack into someone’s key, it only affects that particular stacker’s funds — and even that risk will [be] minimized if they use Cubist,” Tse said.

Source