Protocol Architecture
Lombard Technical Architecture
Last updated
Lombard Technical Architecture
Last updated
Lombard Ledger (Consortium): The Cosmos app-chain at the heart of Lombard Protocol.
CubeSigner (Cubist): Non-custodial key management with multiple layers of control.
LBTC Smart Contracts: Deployed on all Supported Blockchains.
Babylon: The market place for Bitcoin economic security, where Lombard Protocol delegates Bitcoin staking to secure Bitcoin Secured Networks, earning yield for LBTC holders.
Bascule Drawbridge: A state oracle operated by Cubist, serving as an additional layer of security for every LBTC mint and every BTC withdrawal.
Trustless Relayer: Lombard operates several non-critical APIs and services to aid in communication between networks and user experience.
The staker initiates a staking request and receives a unique BTC address generated by the Security Consortium. The BTC address is verified client-side before display. Each BTC address corresponds to where LBTC can be minted (the destination blockchain), who LBTC will be minted to (an address on the destination blockchain), and a partner code used for tracking purposes.
After the staker has deposited BTC, the Trustless Relayer watches the transfer and, once the transfer is confirmed, requests the Consortium to verify it.
After the Consortium has verified the request on Ledger, the Trustless Relayer uses the authorized signatures to mint the LBTC on the destination blockchian.
If the Trustless Relayer fails to mint LBTC, the signatures can always be used directly by the staker to mint LBTC.
The staker burns the LBTC tokens on the designated blockchain by calling the redeem function on the LBTC contract, specifying the BTC address to withdraw to.
The Trustless Relayer observes the burn transaction (finding it on the designated blockchain and awaiting for the transaction to be confirmed), and then requests the Consortium to verify it.
After verification, on Ledger, Lombard Protocol will queue the withdrawal request. The daily process in Staking Bitcoin will ensure sufficient liquidity exists for the withdrawal to be processed.
When the time comes for the withdrawal to be honoured, the Consortium builds a Bitcoin transaction with CubeSigner.
CubeSigner ensures the transaction is not suspicious and enforces security policies before signing the transaction, including requiring: multiple Consortium members to approve the transaction; the timelock to expire; and, the withdrawal amount to be within the daily/weekly limit.
Lombard Protocol's core bridging solution is powered by Chainlink CCIP, with additional verification by the Security Consortium:
The user initiates the bridge transaction on the source chain, paying all network fees upfront.
The Trustless Relayer observes the bridge transaction and requests the Consortium to verify it.
After verification, Chainlink retrieves the authorization signatures from the Consortium, and can then complete the bridge transaction on the destination chain (where the signatures are validated on the LBTC contract).
Every day, Lombard Protocol runs an asynchronous routine based on the amount of newly minted LBTC and LBTC redemptions, and then stakes and/or unstakes into Babylon accordingly:
If there is an increase in LBTC supply, additional Bitcoin will be staked into Babylon.
If there is a decrease in LBTC supply, Bitcoin will be unstaked from Babylon to fulfil redemptions within the target timeframe (7-9 days).
For more information, see Babylon Staking.
