Lombard Security Model
Lombard was built with security as the foundation, not an afterthought. When you deposit Bitcoin with Lombard, you're trusting the protocol with real value. We take that responsibility seriously.
This page explains the security measures protecting your funds, from hardware-level key protection to multi-layer verification to ongoing monitoring and audits.
Our Security Philosophy
Most bridge hacks and DeFi exploits share a common pattern: a single point of failure. One compromised key, one buggy contract, one malicious insider — and funds are gone.
Lombard's security model is built on the opposite principle: defense in depth. Every critical operation must pass through multiple independent security layers. An attacker would need to simultaneously compromise several unrelated systems to steal funds.
Security Consortium
The Security Consortium is the foundation of Lombard's trust model. Rather than relying on a single entity or a small multisig, Lombard distributes trust across 15 independent digital asset institutions like Galaxy Digital, Wintermute and Kraken.
Why Institutions Matter
Consortium members aren't anonymous validators. They're established companies with:
Public reputations they can't afford to damage
Legal accountability in their jurisdictions
Professional security teams managing infrastructure
No single point of control with geographic and organizational diversity
Supermajority Requirement
Every critical operation requires signatures from two-thirds of Consortium members (10 of 15). This means:
A single compromised member can't authorize anything
Even 5 compromised members can't authorize anything
An attacker needs to simultaneously breach 10 independent institutions
Becoming a Consortium Member
Membership isn't open, it requires vetting and approval:
1. Infrastructure deployment. The candidate deploys required infrastructure: Lombard Ledger node, CubeSigner integration, Bitcoin full node, and destination chain nodes.
2. Review process. Existing members review the candidate, including independent KYB (Know Your Business) checks. Public keys and organizational details are exchanged.
3. Network vote. Existing Consortium members vote to add the new member to the Proof-of-Authority network.
4. Smart contract update. The Lombard Protocol multisig updates contracts to include the new member's public address for signature verification.
This process ensures every member meets security standards before gaining signing authority.
CubeSigner: Hardware-Level Protection
CubeSigner, built by Cubist, provides the key management layer that protects all cryptographic operations in Lombard. It addresses the fundamental tradeoff between security and availability that has plagued crypto protocols.
Keys Never Leave Hardware
Private keys are generated inside Hardware Security Modules (HSMs) and never leave. Specifically, Lombard uses HSM-sealed Nitro enclaves designed to prevent key extraction.
This means:
No one can see the keys — not Consortium members, not Lombard, not Cubist
Keys can't be copied or exported — they exist only in hardware
Software attacks can't extract keys — even a fully compromised server can't steal them
Signing Sessions
When Consortium members need to sign operations, they don't access keys directly. Instead, they use CubeSigner signing sessions:
Fine-grained scopes — each session restricts who can sign, which messages, and with which keys
Short-lived — sessions expire quickly, limiting the window for misuse
Instantly revocable — compromised sessions can be killed immediately
Even if an attacker breached a Consortium member's systems, any stolen session would be useless within minutes.
Policy Enforcement
CubeSigner doesn't just protect keys — it enforces rules about how they can be used. These policies run in hardware, making them impossible to bypass through software:
Access control. Defines who can create and use keys, and under what conditions.
Transaction restrictions. Keys can only sign specific transaction types. User keys can only sign Babylon transactions — not arbitrary Bitcoin transactions. Even then, the types of Babylon transactions are restricted.
Usage limits. Controls how many transactions can be signed and their parameters (value, recipient, type).
Multi-party authorization. Certain operations require multiple members and multiple factors (like YubiKeys) to approve. No single party can unilaterally authorize high-risk transactions.
Timelocks. Keys and policies have mandatory waiting periods. Even authorized parties can't use them immediately — this prevents rapid exploitation if credentials are compromised.
Anti-Slashing Protection
Babylon staking introduces slashing risk if validators double-sign. CubeSigner includes Babylon-specific anti-slashing policies that make it cryptographically impossible for validators to sign slashable messages — whether from operational mistakes, bugs, or attacks.
Bascule Drawbridge: Independent Verification
The Bascule Drawbridge, operated by Cubist, provides a completely independent verification layer. It's a separate system that cross-checks every Consortium action before execution.
The Drawbridge Metaphor
Think of it as a literal drawbridge. The bridge is raised by default, minting is blocked. Only when Bascule independently confirms a valid deposit does the bridge lower to allow minting.
This design means that even a fully compromised Consortium can't mint unbacked LBTC. They would also need to compromise Bascule, which is operated by a separate organization with separate infrastructure.
Why Independent Verification Matters
Even well-designed systems can have bugs. The Consortium's verification logic could have an edge case that allows invalid mints. CubeSigner policies could have a misconfiguration.
Bascule is the safety net. It runs independently, with its own view of the Bitcoin network and its own verification logic. If something passes the Consortium but shouldn't, Bascule catches it.
How Bascule Works
For deposits:
Bascule monitors the Bitcoin network independently
When a deposit is detected, Bascule waits for 6 confirmations
Bascule writes an attestation to its smart contract
LBTC minting requires valid signatures from both the Consortium AND Bascule
If either is missing, minting is blocked
For withdrawals (Reverse Bascule):
Bascule monitors redemption events on supported chains
After confirmations, Bascule writes the burn state to CubeSigner
Before authorizing a BTC payout, CubeSigner checks for Bascule's attestation
If the attestation is missing, the payout is blocked
Smart Contract Security
LBTC contracts are deployed on every supported chain. Each contract undergoes rigorous security review.
Audits
Lombard's contracts have been audited by multiple independent security firms:
OpenZeppelin — industry-leading smart contract auditors
Veridise — formal verification specialists
Halborn — blockchain security experts
Cantina — competitive audit platform for security researchers
Sherlock — decentralized security audit marketplace
Audit reports are publicly available for review.
Bug Bounty Program
Lombard maintains an active bug bounty program through Immunefi with rewards up to $250,000 for critical vulnerabilities. This incentivizes security researchers worldwide to find and responsibly disclose issues before they can be exploited.
Runtime Monitoring
Beyond audits, Lombard uses Hexagate for real-time monitoring of contract behavior. Anomalous patterns trigger alerts, enabling rapid response to potential threats.
Safety Features
LBTC contracts include built-in safety mechanisms:
Pausable functions. Critical operations can be paused instantly if a threat is detected.
Two-step upgrades. Contract upgrades require two separate transactions with a timelock between them. This prevents malicious instant upgrades and gives time for community review.
Rate limiting. Unusual patterns (like sudden large mints) can trigger additional verification requirements.
Operational Security
Security isn't just about code — it's about how systems are operated.
Incident Response
Lombard maintains documented incident response procedures. When issues are detected:
Automated monitoring triggers alerts
On-call team assesses severity
If needed, pause functions are activated
Root cause analysis begins
Fix is developed, reviewed, and deployed
Post-mortem is conducted and published
Key Ceremonies
Critical operations like adding new Consortium members or updating policies follow formal key ceremony procedures with multiple witnesses and verification steps.
Ongoing Review
Security isn't a one-time effort. Lombard conducts:
Regular security reviews of infrastructure
Penetration testing
Code audits for all significant changes
Monitoring of new attack vectors in the ecosystem
Transparency
Security through obscurity isn't security. Lombard maintains transparency about its security measures:
Proof of Reserve. Chainlink Proof of Reserve feeds verify Bitcoin backing every 10 minutes. Anyone can verify on-chain that LBTC is fully collateralized.
On-chain verification. All Consortium authorizations are recorded on the Lombard Ledger, creating a verifiable audit trail.
Public audits. All security audit reports are published publicly.
Open documentation. This documentation exists so users can understand exactly how their funds are protected.
Known Risks
No system is perfectly secure. We believe in being transparent about risks:
Slashing risk (LBTC only, 0.1%). BTC staked through Babylon is subject to slashing if Finality Providers double-sign. BTC.b is not staked through Babylon. CubeSigner anti-slashing policies mitigate but don't eliminate this risk.
Smart contract risk. Despite audits, undiscovered vulnerabilities may exist in Lombard's contracts or integrated protocols.
Bridge risk. Cross-chain transfers rely on bridge infrastructure (CCIP, LayerZero) which could have vulnerabilities. Dual verification mitigates but doesn't eliminate this.
Consortium risk. While distributed, the Consortium is a permissioned set. A coordinated attack on supermajority of members could compromise the protocol.
Regulatory risk. Future regulations could affect protocol operations or Consortium members.
Understanding these risks helps you make informed decisions about using Lombard.
Next Steps
Protocol Architecture — How the components work together
Proof of Reserve — Verify Bitcoin backing
Audit Reports — Review third-party security assessments
Last updated