## The challenge of building on Bitcoin <br> On Ethereum and other chains, we have the luxury of smart contracts. These contracts let us build sophisticated applications by encoding arbitrary logic about how a given address (i.e., the contract) can use funds. For example, in a swap, the contract ensures that both parties who supplied money receive money at the end of the exchange; in a liquid staking protocol, the contract enforces that user funds flow to the staking deposit contract, and that withdrawn funds flow back to users—and *only* to users. <br> Unfortunately, real smart contract logic simply doesn’t exist on Bitcoin. Sure, there are Bitcoin scripts that can encode simple spending conditions, but it’s impossible to use those scripts to create applications that require more complex logic e.g., a swap or a liquid staking protocol. <br> ## Enter *hardware-enshrined smart contracts* <br> We’ve been working with <a href="/blog/cubist-lombard-connecting-bitcoin-to-defi" target="_blank">several</a> <a href="/blog/cubesigner-anti-slashing-now-for-babylon" target="_blank">partners</a> in the (newly exploding) Bitcoin ecosystem. One thing we’ve heard again and again is that protocols *need* more complex logic to protect how addresses can use funds. Building a liquid staking protocol without real smart contracts is a tough business! For example, <a href="https://www.lombard.finance/" target="_blank">Lombard</a>, a Bitcoin LRT, needs to enforce rules around user deposits—they must stay in the Lombard pool or be staked to Babylon—and around governance—no one should be able to unilaterally change the rules of the staking protocol. <br> Implementing these types of restrictions on Bitcoin has been a *huge* barrier for developers; many have been forced to string together centralized architectures from hot wallets of third party custodians. After talking with our partners about their needs and the status quo, we realized that our key manager, CubeSigner, could help protocols prevent attacks by enforcing rules about the flow of funds. <br> *Hardware-enshrined smart contracts* serve the same purpose as traditional smart contracts: controlling how a given address uses funds. They have two parts: <ul> <li>A *secret key* that can send and receive funds to its address. This key is generated in CubeSigner’s secure hardware and signs all transactions in secure hardware.</li> <li>A *policy* attached to the key that controls how the key’s funds can be used. This policy can specify, for example, that a key can only send funds to given addresses, or that it can only spend a certain amount of money in a certain amount of time.</li> </ul> <br> Our hardware-enshrined smart contracts have allowed partners like Lombard to implement sophisticated Bitcoin liquid staking protocols that give the same guarantees as familiar Ethereum protocols. In Lombard’s case, they enforce that deposited funds can *only* be used for Babylon staking, and that sensitive governance changes—like updating the “contract” to change how funds can be used—must be approved by many different parties (and are subject to a waiting period). <br> In the next several months, we’re looking forward to announcing how users can encode *arbitrary logic* in hardware-enshrined smart contracts. This will give Bitcoin protocols exactly the same power that Ethereum protocols already wield—the power to express cutting-edge financial and governance logic. <br> (And it may give them fun new powers too 🧙✨…stay tuned!)<br>