Architecture Overview

Lombard Technical Architecture: V1 and V2

V1 Architecture

User Interaction

  • Staker: The user who stakes/withdraws BTC, or mints LBTC.


CubeSigner (Cubist) key management

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 be 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.

Bitcoin node

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.

  1. 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.

  2. 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.

  3. 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).

  4. 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.

  5. 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, therefore the extracted secret keys can be used to slash the staked bitcoin of those who double-signed, ensuring network integrity.

Smart contracts

There are two types of contracts deployed on various networks:

  • Consortium’s governance smart contract: Reads and commits state changes related to LBTC, ensuring that all actions are transparent and verifiable on the blockchain.

  • The ERC-20 token smart contract: Mints and burns LBTC tokens.


Lombard’s Consortium is a decentralized state machine for sharing ownership and managing assets among various members. The Consortium performs the following actions to manage these processes:

  1. Create a New Stake Address:

    • CubeSigner-Managed BTC Address: When a user requests to stake BTC, the Consortium creates a new BTC key (and address) managed by CubeSigner in secure hardware.

  2. Verify Stake and Produce Signed Data:

    • Verify Stake:

      • Check Stake Transaction Existence: Confirm that the stake transaction exists on the blockchain.

      • Confirm Transaction: Ensure that the transaction has been confirmed with the required number of confirmations.

      • Validate BTC Amount: Verify that the transaction includes the BTC amount.

      • Point to Stake Address: Ensure that the transaction points to the correct stake address.

    • Produce Signed Data: Once the stake is verified, generate the signed data that points to the selected blockchain where the user will mint the LBTC.

  3. Stake and Unstake BTC:

    • Select Providers: The Consortium selects appropriate finality providers for staking.

    • Stake BTC: Stake BTC to the finality providers.

    • Unstake BTC: Unstake BTC from the finality providers.

  4. Pay out Unstaked BTC:

    Payout Process: Once BTC is unstaked, the Consortium handles the payout of the unstaked BTC back to the user.


Performs 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 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.


Stake BTC on Bitcoin blockchain

  1. The Staker requests new or reuses a BTC address created by the Consortium for the blockchain selected, and then transfers BTC into it.

  2. The Backend handles the transfer and, once the transfer is confirmed, requests the Consortium to notarize it.

  3. 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.

  4. The Consortium selects a Finality Provider to stake BTC with, builds a proper Babylon-consumable staking transaction, and signs it with CubeSigner.

Unstake LBTC (not yet available)

  1. The Staker burns LBTC tokens on the designated blockchain.

  2. 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.

  3. 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.

  4. 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.

V2 Architecture (WIP)

Overall components are the same.

Main features


  • The Consortium becomes more trustless by switching from Raft to BFT, which makes it possible to add new members without sacrificing security and stability.

  • Babylon starts to pay rewards for staked BTC, meaning that the Consortium must start to collect information about accumulated rewards and generate data that must be provided as an oracle to supported chains. In practice, this means that the backend can request a snapshot of rewards. The Consortium will calculate this snapshot, sign it, and return the data along with the signature. This data and its signature can then be published to blockchains where LBTC is present. Smart contracts on these blockchains will use this data to distribute accrued rewards among holders.


  • LBTC is upgraded to receive the rewards data from the Consortium and distribute those rewards among LBTC holders.

  • Ability to claim rewards for holding LBTC.

Last updated