BSA enable BTC held in institutional custody to be used as onchain collateral without transferring custody or control of the underlying BTC to any third party.

---

The problem with existing solutions

Bitcoin is the world's most trusted and widely held digital asset. However, for institutions holding it in qualified custody, it has always been economically inert — Bitcoin cannot participate in onchain finance to earn yield or act as collateral.

Every existing solution to this problem requires one of two compromises. The first is custodial risk: hand your Bitcoin to a centralized issuer who wraps it into a token (cbBTC, WBTC), accepting that a single entity controls your funds. The second is majority-trust risk: use a multisig bridge that requires a threshold of operators — typically m-of-n — to remain honest. If enough of them collude or are compromised, your funds are at risk. In both cases, Bitcoin's core value proposition — that you control your funds without trusting any third party — is surrendered at the moment you try to make it productive.

BSA are built on a different premise: your Bitcoin never leaves your control, and the trust you extend to any third party is reduced to the minimum possible.

The diagram below shows the three parties in the protocol, their responsibilities, and how they relate to one another.

---

The protocol in one sentence

A system where your Bitcoin stays in your custody, a tamper-proof referee enforces the rules, and you need only one honest participant in the entire protocol to keep your funds safe — while still being able to earn yield by accessing DeFi.

---

The core mechanism: covenant emulation

Bitcoin's scripting language is intentionally limited. Unlike Ethereum, Bitcoin does not currently support covenants — rules that constrain how a transaction output can be spent in the future. This limitation is what has historically prevented sophisticated custody arrangements directly on Bitcoin.

BSA works around this using a technique called covenant emulation. During an initial setup ceremony, all parties — the depositor, Lombard's Token Operator, and one or more Arbitration Oracles — exchange a complete set of Partially Signed Bitcoin Transactions (PSBTs). Each PSBT pre-commits to a specific spending condition (amount and output address). Because these transactions are cryptographically signed before any Bitcoin is deposited, every possible future state of the funds is defined and locked in before the protocol goes live. No new spending paths can be created after setup without the cooperation of the depositor.

The vault itself is built using Taproot script addresses — a Bitcoin upgrade that allows multiple spending conditions to be encoded into a single address efficiently, with reduced on-chain footprint.

The result is a system that behaves like a programmable vault on Bitcoin, without requiring any changes to Bitcoin consensus rules.

---

Four addresses, four states

The Bitcoin network side of the BSA protocol consists of four unique addresses per depositor:

• VA (Vault addresses): where funds are initially deposited to,
• UTA (Unbond Timelock Address): where a depositor can initiate a unilateral exit, e.g. if TO is unavailable,
• UCA (Unbond Challenge Address) and RCA (Rebalance Challenge Address): where an AO can resolve, respectively, disputed unbond and rebalance requests.

A set of PSBTs are signed and exchanged between the depositor and TO, and made available to the TO, depositor, and AOs. PSBTs signed during setup commit to specific destination addresses, meaning UTXOs deposited to the depositor's vault address can only be sent to any one of these predefined addresses before exiting the protocol.

The unilateral unlock from the vault address to UTA creates a lifeline if the TO goes offline, and makes the vault self-custodial.

The diagram below shows how the four components of the BSA architecture connect across the Bitcoin and Ethereum layers, with the Arbitration Oracle monitoring both chains.

---

BTC.b: the receipt instrument

When a deposit is finalized on the Bitcoin network, the Token Operator mints a corresponding amount of BTC.b on Ethereum. BTC.b is accepted as collateral on lending protocols like Aave and Morpho.

The Smart Account Registry (SAR) — a smart contract deployed on Ethereum — maintains a record of every user's BSA instance, including every deposited UTXO, every pre-signed PSBT, and the current status of each position. This is the coordination layer that both the Token Operator and the Arbitration Oracles read when making protocol decisions.

The diagram below shows the full deposit and withdrawal lifecycle, including the challenge path where the Arbitration Oracle intervenes.

The Arbitration Oracle: a tamper-proof referee

The most important security component in BSA for depositor safety is the Arbitration Oracle (AO). Its job is to monitor both the Bitcoin blockchain, and intervene on behalf of the depositor if the Token Operator behaves dishonestly — for example, triggering a false rebalance or challenging a depositor's legitimate withdrawal requests.

The AO is tamper-proof because it runs inside a Trusted Execution Environment (TEE) — specifically, AWS Nitro Enclaves. A TEE is a hardware-isolated computing environment: the code running inside it is cryptographically measured and attested. The AO can only sign transactions on the Bitcoin network if they are running code (i.e., dispute resolution logic) that is agreed upon by the TO and depositor at setup. This is because the AO's signing key is managed by AWS KMS with policy restrictions that prevent any access outside the enclave application itself.

This has a precise security implication: a malicious AO operator cannot instruct the AO to sign fraudulent transactions. The most damaging action a malicious operator can take is to take the AO offline. This is enforced by the covenant emulation.

The AO operates in fail-closed mode: it will only sign a transaction resolving a dispute if it has successfully verified both the Bitcoin transaction and the corresponding Ethereum state. Before any AO joins a protocol instance, it produces a cryptographic attestation — a document signed by the Nitro hardware itself — certifying the exact codebase it is running. The Token Operator and the depositor can both verify this attestation independently before committing funds.

---

How Liquidations Work

The BSA not only enables liquidations from a self-custodial vault, but is the first bridging solution to implement partial liquidations for collateral backing a fungible derivative token.

When a user's position on a lending protocol enters bad health, a liquidator can buy up the collateral token, repay the debt, and exit the position. From the depositor's vault address on the Bitcoin network, one or more deposited UTXOs will then be rebalanced to Lombard's general reserves, covering the liquidator's BTC.b in wider circulation. Please refer to Example 4.1 in the BSA Whitepaper to see a fuller overview of this.

Unlike other Bitcoin bridging solutions with non-fungible tokens, which require DeFi protocols to have specialized infrastructure to handle Bitcoin native architecture, BSA requires no DeFi protocol-level modifications and, importantly, does not introduce any liquidity delays. Liquidity delays from Bitcoin-side-necessitated modifications can reduce a liquidator's likelihood of liquidating a position on a DeFi platform, as their capital could be locked up for a lengthy redemption process on the Bitcoin network. This can result in DeFi positions remaining in bad health and causing possible risk to DeFi platforms, which may incur losses if these are not addressed in a timely manner.

---

The Security Breakthrough

BSA achieves 1-of-k security. A user requires only one correct AO from the set they selected during setup to be protected against a malicious Token Operator. So, for k AOs, this is what achieves 1 out of k security.

This is possible because AOs run inside TEEs that even their own operators cannot tamper with. A malicious AO operator cannot redirect funds to destinations not committed to during the initial PSBT exchange, or produce incorrect outcomes. The worst they can do is go offline.

The diagram below shows how BSA's security model compares to centralized issuers and multisig bridges across four key properties.

---

What Lombard has built

A Bitcoin vault architecture that requires no changes to Bitcoin consensus, no centralized custodian who owns and controls the underlying Bitcoin, and no majority-trust assumption. Bitcoin stays on Bitcoin, under the depositor's control. A tamper-proof referee enforces the rules. And the depositor's safety depends on a single honest party among an open, extensible set of independent oracles.

---

For the full technical specification, including the formal security proofs and PSBT transaction reference table, see the Bitcoin Smart Accounts whitepaper: https://www.lombard.finance/BSA.pdf