Protocol Architecture
Lombard Technical Architecture
Last updated
Lombard Technical Architecture
Last updated
Staker: The user who stakes/withdraws BTC, or mints LBTC.
CubeSigner is a hardware-backed key management platform that safeguards keys in secure hardware even during signing. CubeSigner is used to generate Bitcoin keys (and their addresses) and apply different security policies to restrict how (and when) these keys are used. Lombard uses multiple policies, including:
Access Control: Who can create and use keys, and under what conditions.
Usage Limits: How many transactions and what types of transactions (including their value, recipient, and kind of transactions—e.g., only Babylon staking transactions) can be signed.
Multi-party Authorization (MPA): MPA policies require multiple users and, typically, multiple factors (e.g., YubiKeys) to sign-off on transactions. This enhances security by ensuring that no single party can unilaterally authorize a transaction, making the entire process more robust, reliable, and decentralized. Policies are similarly safeguarded with MPAs.
Timelocks: Keys have timers that prevent even authorized parties from using them. This enhances security by ensuring that a key is timelocked and cannot be used (e.g., for a day) even by authorized (but potentially compromised) parties. Policies themselves have similar timelocks.
A set of full/light Bitcoin nodes that interact with the Bitcoin blockchain.
User Actions: A staker interacts with Bitcoin nodes by staking BTC into the Stake Address.
Services Actions: Our services interact with Bitcoin nodes for data indexing (for example, staking data) and broadcasting of signed and verified transactions to the Bitcoin network.
The Babylon protocol itself and the Babylon chain. It enables staking and unstaking of BTC with the finality providers.
Babylon's Mechanism for Finality Providers:
Registration: Finality Providers register themselves on Babylon's platform.
Selection of Finality Gadgets: These providers select which Finality Gadgets (IBC connected CosmWasm contracts and CosmosSDK modules) they want to maintain. By doing so, they earn rewards for their maintenance efforts. The rewards are also shared with BTC stakers.
Staking BTC to Finality Providers:
Consortium Initiation: The Consortium initiates the process by staking BTC to the Finality Providers.
Creation of Staking UTXO:
Self-Custodian Vault: The sent BTC amount is locked in a self-custodian vault, creating a special staking UTXO (Unspent Transaction Output) with two spending conditions:
Timelock: Specifies a period after which the Consortium can use their secret key to withdraw the staked BTC.
EOTS (Extractable One-Time Signature): Allows the UTXO to be burned through a special EOTS. If the stake is delegated, the EOTS is assigned to the validator.
Signing with CubeSigner: The UTXO is then signed using CubeSigner. This ensures that the UTXO is securely locked and can only be spent under the specified conditions (Timelock and EOTS).
Broadcasting to Bitcoin node: After signing, the transaction is broadcasted to a Bitcoin node, eventually making it part of the Bitcoin blockchain. This step finalizes the staking process.
Finality Round: An additional signing round takes place after the base consensus protocol:
Finalization Condition: A block is considered finalized only if it receives EOTS signatures from over 2/3 of the Bitcoin stake.
Consensus and Safety:
All safety violations of the consensus are reduced to double signing in this round.
If there is a safety violation (i.e., more than 1/3 of the Bitcoin stake signs two blocks at the same height using EOTS), the secret keys of those stakers can be extracted.
Slashing Mechanism: The EOTS signature scheme (implemented by Schnorr signatures) is natively supported by Bitcoin, and therefore the extracted secret keys can be used to slash the staked bitcoin of those who double-signed, ensuring network integrity.
There are several smart contracts deployed on destination chains where LBTC is supported. View deployed smart contracts.
Lombard’s Security Consortium is a decentralized state machine for sharing ownership and managing assets among various members. The Consortium members operate independently, but come together in consensus, to validate all important security actions. Read more about the Consortium.
The Bascule Drawbridge, a state oracle running its own smart contract on Ethereum, is unique to Lombard's multi-layered security approach. The drawbridge, operated by Cubist, attests the truth from the Bitcoin network on destination chains independently of the Consortium. This adds additional security to LBTC by providing a secondary and independent attestation on the state of the Bitcoin network.
Note: Minting of LBTC requires a valid signature from both the Consortium and the Bascule Drawbridge.
The backend performs the following support functions for the Сonsortium:
Keeps track of the Stake Addresses list.
Looks for the incoming transactions to the Stake Address and handles those transactions:
Saves transaction hash and output index.
Waits for 5 confirmations for transaction finality.
Sends a request containing the following data to the Consortium:
The transaction hash.
The output index.
Consortium receives this request and performs several checks:
Confirms that the transaction has been made to a stake address.
Verifies that the transaction has been confirmed.
Ensures that the transaction actually exists on the blockchain.
Consortium reaches a consensus that all the conditions are met (the transaction is valid/confirmed) and proceeds to the next step.
Consortium returns signed data to Backend.
LBTC contract interaction:
Consortium’s signed data is used by the LBTC contract (submitted by the Staker) to mint the appropriate amount of LBTC tokens for the address selected upon generating the BTC address.
This component exists only to improve the user experience. All security is provided by the Consortium.
The Staker requests new or reuses a BTC address created by the Consortium for the blockchain selected, and then transfers BTC into it.
The Backend handles the transfer and, once the transfer is confirmed, requests the Consortium to notarize it.
The Staker receives the notarized data (RLP-encoded data: uint256 chainId, address to, uint64 amount, bytes32 txId, uint32 index; and Signature: the keccak256 hash of the data signed by the Consortium threshold key) and invokes the mint transaction to get their LBTC.
The Consortium selects a Finality Provider to stake BTC with, builds a proper Babylon-consumable staking transaction, and signs it with CubeSigner.
The Staker burns LBTC tokens on the designated blockchain.
The Backend handles the burn transaction (finds it on one of the blockchain with LBTC and waits for the transaction to be confirmed), and then requests the Consortium to verify it.
The Consortium, after verification, unstakes the designated amount of LBTC from the chosen finality provider and sends BTC transaction to the address passed to burn transaction. For the withdrawal transaction, the Consortium builds a BTC transaction and signs in with CubeSigner.
CubeSigner ensures the transaction is not suspicious and enforces security policies before signing the transaction, including requiring: multiple Consortium members to manually approve the transaction; the timelock to expire; and, the withdrawal amount to be within the daily/weekly limit.
