<a href="https://babylonlabs.io/" target="_blank">Babylon</a> is a hot new DeFi protocol that makes Bitcoin staking possible. Developers are using Babylon to build liquid staking protocols, restaking protocols, and other layered protocols that let users earn yield from natively staked BTC without the need for third-party custody, bridging, or wrapping. This staked BTC—which until this point has been sitting idle—is fueling new proof-of-stake (PoS) blockchains and serving as *the* source of shared economic security. <br> Last week <a href="/blog/full-featured-bitcoin-api-now-available-in-cubesigner" target="_blank">we announced the release of our full-featured Bitcoin key management API</a> in CubeSigner, and today we’re thrilled to expand on that news: CubeSigner now supports complete workflows for Babylon staking! <br> ## Introducing the first and only all-in-one Babylon key management solution<br> CubeSigner is the first and only key management product offering functionality for building on Babylon. Similar in concept to our specialized <a href="/blog/cubist-launches-key-management-platform-for-web3-infrastructure" target="blank">key manager for Ethereum validators</a>, this new Babylon support makes it possible for teams to easily stake Bitcoin and build protocols, apps, and end-user wallets on top of Babylon. <br> With CubeSigner, developers use simple APIs to securely handle deposits, withdrawals, and early unbonding. We put a lot of effort into these workflows because the alternative is simply *scary*. Right now, developers’ only choice is to use hot wallets and blind signing for Babylon staking transactions…which we’ve learned (from Mt. Gox and others!) is at best negligent and at worst malicious. <br> But why the blind signing? It’s because old-school custodians and key managers have not kept up with Bitcoin—and Babylon takes advantage of many Bitcoin features that go beyond the simple asset transfer transaction (e.g., the Babylon staking/deposit transaction is a Taproot transaction with three output scripts that specify how and when the staked funds can be spent). <br> First-class APIs that capture Babylon workflows make it simpler for developers to build on Babylon—the APIs abstract away Bitcoin's complexity—and, more importantly, it makes it possible for them to set policies that safeguard the assets their Taproot keys hold. As an example: when CubeSigner’s Babylon staking policy is applied to a Taproot key, it means that key cannot be used for anything besides Babylon staking. In particular, if the developer—or the protocol or the exchange—is compromised, the *most* the attacker can do is stake the BTC to Babylon with that key. Later, we’ll describe how developers can use policies to limit damage even further. <br> ## Security policies matter *even more* on Bitcoin<br> Security policies are not just nice to have, they’re genuinely fundamental. This is because Bitcoin doesn't have smart contracts; instead, policies allow projects to enforce how funds are used. As one example, we expect a Bitcoin liquid staking or restaking protocol that pools together end-user funds to provide the same security guarantee that an Ethereum smart contract would. All user deposits must be staked to the protocol and all withdrawals must be to the L[SR]T's pool, which disburses funds back to the users. On Bitcoin, the L[SR]Ts can provide these security guarantees with policies as opposed to smart contracts. [^policy] <br> One of the first teams to use CubeSigner to build a secure protocol on Babylon is <a href="https://www.lombard.finance/" target="_blank">Lombard</a>, a novel Bitcoin LST that’s gearing up for launch. <a href="/blog/cubist-lombard-connecting-bitcoin-to-defi" target="_blank">See our blog post</a> for more about how Lombard is using CubeSigner to overcome the challenges teams are normally faced with because of Bitcoin’s limited programmability. <br> Beyond making sure teams can safeguard their and/or their users' assets, our goal with first-class workflows and policies was to minimize development and maintenance burden. The reality is most teams—even sophisticated ones building on Babylon!—don't have multiple dedicated security ops/engineers, and often rely on external contractors to build and run serious systems. CubeSigner’s APIs, which are compatible with off-the-shelf bitcoin libraries, are designed to let them focus on building products; CubeSigner's secure hardware and policies prevent them from accessing or misusing keys. <br> ## Locking down staking operations<br> There are four different workflows that developers rely on when staking with Babylon: <ul> <li>**Deposits** - deposit, or stake, funds into the Babylon protocol</li> <li>**Normal withdrawals** - withdraw funds after the standard staking timelock has expired</li> <li>**Early unbonds** - initiate the withdrawal process before the staking timelock has passed</li> <li>**Early unbond withdrawals** - withdraw funds after the early unbond timelock has expired</li> </ul> <br> CubeSigner exposes first-class APIs for all four workflows and enforces strict security policies on the Bitcoin keys used for Babylon staking. As a little background: CubeSigner lets you attach a policy to a key, and refuses to sign transactions/messages that do not conform to the policy. This lets you impose spending limits on keys, require k-of-n users to approve a transaction, etc. <br> When a Babylon staking policy is attached to a Taproot key, CubeSigner first enforces that the key cannot be used to sign any transaction that is not a Babylon deposit, withdrawal, or early unbond. As we hinted before, though, just restricting signing to Babylon transactions is not enough. This is because deposit transactions are dangerous: an attacker can always sign a Babylon deposit transaction with the withdrawal address of their choosing (and then steal funds by signing a withdrawal). This is why our Babylon staking policy lets you constrain the different parameters relevant to Babylon staking, including the:<br> <ul> <li>Allowed public keys that can be used for staking</li> <li>Allowed finality providers that can be used for staking</li> <li>Allowed change addresses that can be used in staking transactions</li> <li>Allowed withdrawal addresses that can be used in withdrawal transactions</li> <li>Maximum fee allowed in a staking or withdrawal transaction</li> <li>Minimum and maximum staking lock times</li> <li>Minimum and maximum staking amounts</li> <li>…and more!</li> </ul> <br> Our threat model assumes the worst: that every system will eventually get compromised. CubeSigner’s Babylon support locks down what constitutes an allowable transaction to limit what a malicious actor could do if they were to gain access to your system. *All* they could do is stake through CubeSigner on your behalf with a finality provider of your choosing. <br> ## Locking down keys unlocks Bitcoin's potential<br> CubeSigner's staking policies—and more generally our notion of <a href="https://www.lombard.finance/blog/lombard-collaboration-cubist-hardware-enshrined-governance-for-bitcoin-liquid-staking/" target="_blank">hardware-enshrined contracts that couple hardware keys with policy logic</a>—enable new Bitcoin protocols like Lombard to provide security guarantees on par with on-chain smart contracts. Coupled with simple APIs, they also make it easier for developers to ship products faster. <br> We admire the principled work that David, Fisher and the rest of the Babylon team have done in preparation for Babylon’s mainnet launch and are excited to provide new technology foundations that help builders securely connect Bitcoin to the rest of the DeFi ecosystem. <br> Want to learn more about securely managing your Babylon keys with CubeSigner? <a href="/contact-form-cubesigner-hardware-backed-key-management" target="_blank">Get in touch here</a>. <br> [^policy] <small>And like in smart contract protocols, the way to ensure the policy logic doesn't change is, again, with a policy—e.g., that k-of-n administrators need to approve the change.</small><br> <br>