Multisig vs. DLCs vs. Threshold Signatures vs. Custodial: How Bitcoin Loan Technology Compares

TL:DR

• Bitcoin loan models mainly differ in who controls collateral: shared multisig keys, oracle-triggered DLCs, decentralized threshold signatures, or a centralized custodian.
• Liquidium uses threshold signatures and Chain Key infrastructure to enable pooled liquidity, native cross-chain transactions, flexible loan terms, and automated liquidations.
• Each model has tradeoffs: multisig favors personal control, DLCs favor Bitcoin-native settlement, custodians favor simplicity, while Liquidium favors liquidity, automation, and cross-chain access.

Not all Bitcoin loans work the same way. Two products can promise the identical thing (liquidity without selling your BTC) while protecting your collateral with completely different technology, and completely different ideas about who you have to trust.

The four models differ in who can move your collateral. Multisig splits signing across separate keys held by borrower, lender, and sometimes a third party. DLCs settle through oracle-attested price data. Threshold signatures spread one key across many nodes. Custodial lenders hold the keys themselves. Liquidium uses the threshold model, with pooled liquidity and automated loan management on top.

Every Bitcoin-backed loan answers the same question: who can move the BTC, under what conditions, and based on what information. The technology behind that answer shapes rates, liquidation behavior, cross-chain access, and how much trust you extend to other people. This guide compares the four structures used in production today and shows where Liquidium fits.

How do the four Bitcoin loan models compare at a glance?

Who controls the collateral?

• Multisig: shared control: 2-of-3 keys split between borrower, lender, or a third party.
• DLC: locked on Bitcoin L1, released by pre-signed transactions tied to an oracle attestation.
• Threshold signatures (Chain Key): decentralized protocol custody: key shares spread across nodes, so no single node holds the full key.
• Custodial: the lending company, in its own custody setup.

How are these models typically structured?

• Multisig: commonly used for peer-to-peer or bilateral loans, with a separate escrow setup for each loan. Multisig itself does not require a P2P structure.
• DLC: commonly used for bilateral loans, with a separate contract for each position. DLCs can support other market structures, although per-loan setup makes bilateral lending a natural fit.
• Threshold signatures (Chain Key): can support either peer-to-peer or pooled lending. Liquidium uses threshold signatures with shared liquidity pools and programmatic loan management.
• Custodial: the lender controls the assets. Funding may come from the company’s balance sheet or other sources, so custody does not determine the market structure either.

What do you have to trust?

• Multisig: counterparties must cooperate to release or liquidate collateral.
• DLC: the oracle(s) must attest honestly and on time.
• Threshold signatures (Chain Key): subnet consensus, canister code, the price oracle, and liquidator liveness.
• Custodial: the company's solvency, security, and honesty.

How are prices typically determined?

• Multisig: multisig itself does not require an oracle. Lending implementations typically monitor collateral prices off-chain or use an external price feed.
• DLC: an oracle is fundamental to settlement, attesting to an agreed outcome such as the BTC price at a set time.
• Threshold signatures (Chain Key): threshold signing itself does not require an oracle. Liquidium uses ICP’s Exchange Rate Canister to price collateral and calculate health factors.
• Custodial: prices are handled by the lender’s internal risk systems, typically using external market data rather than an on-chain oracle.

How do repayment and liquidation execute?

• Multisig: manual cooperation, or pre-signed penalty transactions.
• DLC: automatic on-chain settlement once the oracle attests.
• Threshold signatures (Chain Key): programmatic: health-factor monitoring with incentivized liquidator bots.
• Custodial: off-chain margin calls at the company's discretion.

How is cross-chain coordination handled?

• Multisig: can support cross-chain loans, but coordination between BTC collateral and assets on another chain requires additional infrastructure outside the multisig itself.
• DLC: can support borrowing on another chain while BTC remains on Bitcoin L1, but coordination and settlement of the borrowed asset require an additional rail.
• Threshold signatures (Chain Key): Chain Fusion provides cross-chain execution at the infrastructure layer. In Liquidium, assets enter and exit on their native chains, while chain-key assets handle accounting inside the pooled market.
• Custodial: can support assets across multiple chains, with cross-chain coordination handled internally by the company.

What is the borrower experience like?

• Multisig: strong key control, but manual, fixed-term, and slower.
• DLC: non-custodial settlement, but fixed terms and per-loan setup.
• Threshold signatures (Chain Key): money-market experience: instant borrowing, no fixed maturity, automated management.
• Custodial: the simplest UX, with full counterparty risk.

What is a multisig Bitcoin loan?

A multisig loan locks collateral in a multisignature address, most commonly 2-of-3: one key for the borrower, one for the lender, and a third for a backup signer or the platform. No single party can move the funds alone. Unchained is the best-known example: in its vaults, the client holds two of three keys and Unchained holds one, so the company can never move the bitcoin but can help with recovery (Unchained). Lenders like Unchained and Debifi apply the same escrow to loans.

Each loan is a bilateral arrangement with its own escrow address, which keeps trust narrow but fragments liquidity into per-loan matching. There is no on-chain oracle: the escrow enforces key thresholds, and price monitoring happens off-chain at the lender's risk desk. Repayment is cooperative: the signers release your collateral once you repay.

Liquidation is the weak point, since moving the BTC of a defaulted or unresponsive borrower still requires signatures. The collateral is native BTC, but the borrowed asset moves on separate rails with no connection to the escrow. You keep a key and real veto power, in exchange for manual processes, fixed terms, and slower execution.

What is a DLC Bitcoin loan?

A Discreet Log Contract is a Bitcoin-native contract settled by an oracle's signed attestation of an external event, such as the BTC price at a set time. Tadge Dryja introduced the concept in his MIT Digital Currency Initiative paper, and the dlc-specs repository maintains the open standard. In a loan, both parties lock collateral into a shared output and pre-sign a transaction for every outcome. When the oracle attests, adaptor signatures make exactly one of those transactions valid, and it can be broadcast. The oracle never learns the contract exists, cannot redirect funds, and cannot steal them.

Settlement is the model's strength: repayment and liquidation execute on-chain with no cooperation needed, enforced by Bitcoin itself. The tradeoffs sit elsewhere. DLC loans are bilateral with fixed terms and per-loan setup. The oracle is the core trust assumption — if it goes offline, signs late, or colludes, the contract can settle wrong, which is why serious implementations require several independent oracles to agree. Cross-chain support stays thin: the BTC never leaves L1, but the borrowed asset lives on another rail the contract cannot verify. Lava's original loan protocol brought this model to production (Bitcoin Magazine technical overview).

What is a threshold-signature (Chain Key) Bitcoin loan?

\Threshold-signature systems replace several separate keys with one key that no single machine ever holds. The key exists as shares distributed across the nodes of a decentralized network, and a signature is produced when a threshold of nodes participate. ICP's Chain Key cryptography implements this with threshold ECDSA, the signature scheme Bitcoin and Ethereum use, so canister smart contracts can hold and move assets on other chains (ICP Chain Key cryptography). Chain Fusion extends this to reading and writing across chains without bridges (Chain Fusion).

That enables pooled, programmatic custody of native assets. Instead of one escrow per loan, decentralized canister vaults hold collateral and liquidity for the whole market, accounting for it as chain-key tokens (ckBTC, ckETH, ckUSDC, ckUSDT), each backed 1:1 by the native asset (chain-key tokens). The loan lifecycle runs as code: a price oracle feeds valuations, health factors update with the market, and incentivized liquidator bots close unsafe positions. A borrower can supply BTC on Bitcoin and receive USDT on Ethereum, with both sides settling on their native chains.

The trust assumptions move rather than disappear: subnet consensus, canister code, the price oracle, and liquidator liveness. In return, borrowers get a money-market experience — instant borrowing from pooled liquidity, no fixed maturity, automated management. Liquidium is built on this model.

What is a custodial Bitcoin loan?

A custodial loan is the simplest structure: you send BTC to a lending company, the company holds the keys, and you receive cash or stablecoins. Ledn and Strike are current examples; BlockFi and Celsius are the cautionary ones. When BlockFi filed for Chapter 11 in November 2022, client collateral ended up inside the bankruptcy estate (BlockFi Chapter 11 announcement).

There is no escrow, oracle, or on-chain enforcement. The company's internal systems track prices, issue margin calls, and liquidate at their discretion, which makes operations fast and flexible — any chain, any asset, fiat payouts — because everything is an internal ledger entry. The borrower experience is the most familiar of the four, and rates can be competitive. The tradeoff is total counterparty exposure: you have no cryptographic guarantee that your collateral is segregated, un-rehypothecated, or recoverable if the company fails.

How Liquidium's Bitcoin Loan Architecture Works

Liquidium sits in the threshold-signature category, and its design follows from that: pooled liquidity, cross-chain borrowing on native rails, and automated loan management from deposit to liquidation.

How does Liquidium secure Bitcoin collateral?

Two layers with different jobs. The first is your wallet: every action, borrow, withdraw, repay, requires a signature from your own wallet (BIP322 for Bitcoin, EIP-191 for Ethereum, Ed25519 for Solana), and no party can act on your account without one (Liquidium security docs).

The second is custody. Deposited assets are handled by Liquidium's pool canisters, with BTC held through Chain Key infrastructure. The signing key is threshold ECDSA shared across the nodes of an ICP subnet; no single node, employee, or server holds the complete key. Once you deposit, you do not retain sole key control over that collateral. Control is split: your wallet authorizes every action on your position, and decentralized canister custody means no single party can move pool funds. An independent Trail of Bits review covered the canisters behind Cross-Chain Loans.

What is the difference between the native-chain route and ckAssets?

You only ever touch native chains: send real BTC to a Bitcoin address, receive real USDT to an Ethereum address. Internally, the pools account for assets as chain-key tokens. When you deposit BTC, the ckBTC minter locks it on Bitcoin L1 and mints ckBTC 1:1 into your pool subaccount; withdrawals and borrows burn the chain-key token and release the native asset. This layer makes pooled cross-chain accounting fast enough to feel like one market. The full flow is in the cross-chain architecture docs.

How do pooled liquidity, health checks, and liquidations work?

Liquidium is a pooled-liquidity protocol. Lenders supply into shared pools and borrowers draw from that liquidity instantly, with no matching or per-loan negotiation. Users can supply, borrow, and interact with the protocol directly without approval from a lender or Liquidium. Debt has no fixed maturity date, and positions are unified under one account across chains: supply BTC on Bitcoin, borrow USDT on Ethereum, monitor one position (cross-chain features).

Every position has a health factor: collateral value weighted by liquidation thresholds, divided by debt value, priced by ICP's Exchange Rate Canister. Below 1.0, a position is liquidatable. Liquidations are permissionless: anyone can run their own liquidator and interact with the protocol directly. When a position becomes liquidatable, a liquidator can repay part or all of the debt and claim the collateral plus a bonus. This keeps the pools solvent without relying on Liquidium staff or a designated risk desk (health factor, liquidations).

What are Liquidium's trust assumptions and tradeoffs?

• ICP subnet consensus: custody depends on a threshold of subnet nodes behaving honestly.
• Canister code: bugs are possible; the Trail of Bits review and overcollateralization mitigate this, not remove it.
• Chain-key infrastructure: the ckAsset minters and ledgers are system canisters you must trust.
• The price oracle: a bad Exchange Rate Canister feed can trigger wrongful or blocked liquidations.
• Liquidator liveness: automation assumes liquidators are online when volatility hits.

In exchange, borrowers get what multisig and DLCs cannot offer: instant borrowing from pooled liquidity, cross-chain routes on native rails, no fixed maturity, and loan management that runs itself.

Which Bitcoin loan model fits which borrower?

Multisig fits borrowers who want a human counterparty and a key in their own hand: large term loans, an arbitrator or recovery path, and manual processes over protocol code.

DLCs fit Bitcoin purists who want settlement enforced by L1 alone: fixed-term loans, a trusted oracle setup, and liquidation as a pure function of the price feed.

Threshold-signature / Chain Key lending fits borrowers who want the money-market experience: instant stablecoin liquidity against BTC, cross-chain borrowing without bridges, and automated monitoring and liquidations. If that is you, the borrow feature page and the bitcoin-backed loan page show how it works in practice.

Custodial fits borrowers who prioritize simplicity over custody and accept full counterparty risk. The 2022 lending collapses showed what that can cost.

Final thoughts

There is no universally best Bitcoin loan technology. Multisig maximizes personal key control, DLCs maximize Bitcoin-native settlement, and custodial lending maximizes convenience at maximum counterparty risk. Threshold-signature systems trade some self-custody for pooled liquidity, cross-chain reach, and automation.

Liquidium is the strongest fit for borrowers who prioritize that combination: native-chain deposits and withdrawals, unified cross-chain positions, and loan management that monitors and liquidates itself, while depending on ICP consensus, canister code, the price oracle, and liquidator liveness. If that balance matches what you’re looking for, open the Liquidium app and check out the available markets for your preferred assets.

This article is for educational purposes only and does not constitute financial, legal, or tax advice. Borrowing against Bitcoin carries liquidation risk and can result in partial or total loss of collateral.

FAQ's

What is the difference between multisig and threshold signatures for Bitcoin loans?

Multisig uses several complete, independent keys, and a quorum of keyholders each sign every transaction. A threshold signature splits one key into shares across many nodes, which jointly produce a single standard signature. Multisig gives named keyholders explicit veto power, which suits bilateral loans. Threshold signatures let decentralized infrastructure sign programmatically, which suits pooled protocols like Liquidium — but you do not personally hold a key to your deposited collateral.

Do DLC Bitcoin loans require an oracle?

Yes. A DLC settles based on an oracle's signed attestation, such as the BTC price at a set time. Adaptor signatures mean the oracle only reveals which pre-signed outcome becomes valid — it cannot see or move the funds. But an oracle that is offline, late, or dishonest can settle the contract incorrectly. Multi-oracle setups reduce the risk without removing it.

How does Liquidium hold my Bitcoin collateral?

Your BTC is locked on Bitcoin L1 by the ckBTC minter, and Liquidium's BTC pool canister accounts for it as ckBTC in your subaccount. Every action requires your wallet signature, and the infrastructure key is threshold ECDSA shared across ICP subnet nodes — no single party holds a complete key. You keep exclusive authorization over your position, but custody of deposited collateral is decentralized protocol custody, not sole key control (Security docs).

Is pooled lending better than peer-to-peer lending for Bitcoin loans?

For fungible collateral like BTC and repeat borrowing demand, pools produce tighter rates and instant liquidity, because one shared market replaces per-loan matching. Peer-to-peer still fits bespoke loans that need individual terms. We compared both in Liquidity Pools vs. Peer-to-Peer Bitcoin Lending.

Are cross-chain Bitcoin loans safe?

They carry knowable risks: canister or contract bugs, oracle failures, liquidator downtime, and the consensus security of the coordinating infrastructure. Designs that keep assets on their native chains, like Liquidium's Chain Key architecture, avoid the bridge exploits behind the largest cross-chain losses. More background in Chain Fusion: Security and Trust in Cross-Chain DeFi.