July 9, 2024
5 min readThis is the second blog in a series introducing Lombard’s ecosystem partners and collective goals. We believe ‘if you want to go far, go together’, and that’s why we’re working with some of the best minds to develop, secure, and integrate LBTC into the decentralized finance economy. This blog was authored by the Cubist team, check out their website and give them a follow on X.
The recipe for an Ethereum Liquid Staking Token is easy enough to describe. The first step is to design a staking protocol on paper. Typically, the protocol offers a token — the LST — in exchange for Ethereum deposits, and then stakes the deposited ETH to earn yield. The next step is to implement this design as a smart contract. The smart contract keeps user funds safe, for example, by ensuring that deposits can only be sent to the canonical Ethereum deposit contract (and not, say, to an attacker's wallet) and that withdrawals can only be sent to the protocol's pool (and not, say, to an attacker's wallet). Finally, the protocol designers deploy the contract, usually controlled by a set of governance keys that can be used to upgrade the protocol or pause contracts in an emergency.
Unfortunately, this process doesn’t work for Bitcoin Liquid Staking. Because Bitcoin scripts are very limited compared to the Ethereum virtual machine, it’s simply not possible to create a Bitcoin smart contract that implements staking pools and on-chain governance. To build Lombard, we needed an approach that would keep user funds just as safe as a smart contract, but could be built on top of Bitcoin’s much simpler scripting language. We achieved this using a new approach developed by the Cubist team: hardware-enshrined, off-chain smart contracts.
A smart contract on Ethereum can receive funds and use those funds based on rules that it implements (e.g., stake funds once the staking pool has accumulated more than thirty-two ETH). A hardware-enshrined smart contract similarly receives funds and controls how those funds are used — just through a different mechanism. The hardware-enshrined contract consists of a Bitcoin signing key (which can receive funds) protected by a policy (which controls how those funds are used). The signing key lives inside of secure hardware, and the policy implements the logic that must be satisfied before a transaction can be signed with the key — much like the EVM bytecode of a smart contract does. Fortunately, the key and policy primitives we needed already existed in CubeSigner, the Cubist team’s hardware-backed key management system; all we had to do was write the hardware-enshrined smart contracts themselves.
Our first task was to make sure that users’ Lombard deposits can only be used to stake Bitcoin. To enforce this restriction, we used the CubeSigner policy engine, which lets you attach policies to individual keys to control what and when those keys sign. Lombard users deposit to the address of a hardware-enshrined contract (i.e., the policy-protected key). The key’s policy only allows it to sign Bitcoin staking requests — no other operation is allowed.
The next task was to build a safe governance process. In a world with smart contracts, we would assign roles like Pauser or Admin to the Lombard Consortium, and then require e.g., Admin access for sensitive operations like contract upgrades. In Lombard, the Consortium controls sensitive operations — in our world, policy changes — with yet more hardware-enshrined policies. Changing a policy on a Lombard key requires (a) sign-off from multiple Consortium members and (b) a cooling-off period of twenty-four hours before the change takes effect. This gives time for any suspicious Consortium member to veto the change if something’s amiss.
Finally, our setup gives even stronger guarantees than those of a standard liquid staking provider. Our policy-restricted keys are generated inside secure hardware and stay inside secure hardware — even when they sign transactions. This means that no one — not attackers, not Consortium members, and not Lombard developers — can ever touch the private keys that power the protocol.
Lombard and Cubist will continue our work developing secure systems that manage millions of transactions and contribute to a sustainable digital economy.
We’re excited to see Lombard and LBTC launch this summer, and also see what new applications hardware-enshrined Bitcoin contracts will enable in the future.
Cubist is a key management infrastructure company focused on making low-latency and automation use cases secure. Their flagship product, CubeSigner, eliminates the security-performance-usability tradeoff that teams have long had to make when building in Web3. The company was founded in 2022 by a former fintech risk executive and professors from Carnegie Mellon University and UC San Diego who have published more than 80 peer-reviewed papers on computer security. To learn more about Cubist and their key management technology, visit their website and follow them on X and LinkedIn.
Named after the historic Lombard Street in London — a hub of financial activity since the Middle Ages — Lombard symbolizes a place where all participants are connected to opportunity. By adopting the Lombard name, we rebuild its legacy on digital blocks, transforming it into a modern nexus of innovation and connectivity.
Lombard is dedicated to creating opportunities on-chain with the development of LBTC. LBTC is a liquid yield-bearing representation of Bitcoin, designed for composability and access to opportunities in decentralized finance. Set to launch as collateral on leading decentralized finance protocols, chains, and Layer 2s this summer, LBTC is built with no security compromises. It has the potential to connect over $1.3 trillion of idle Bitcoin to decentralized finance, contributing to the sustainability and growth of the digital economy.
July 4, 2024
6 min readJuly 2, 2024
6 min read