The borrower deposits BTC into a 2-of-2 multisig address controlled jointly by borrower and lender. Neither party can move the funds alone — both signatures are required for any transaction that spends from this address.
This is the foundation of the entire DLC. The BTC never enters a custodial wallet, never touches a centralized exchange, and never leaves the Bitcoin blockchain. On the portfolio page, this is the first node in the decision tree — "Borrower locks BTC." The collateral amount, USD value, and LTV ratio are all shown when you click the node.
Read Matt's full explainer →
Both parties sign the funding transaction, which creates the on-chain
multisig output. This is a real Bitcoin transaction — you can look up the
funding txid on any block explorer.
The contract ID is derived from the funding transaction — it's the cryptographic fingerprint of the entire agreement. When you click "Verify now" on a loan, the dlc-verify engine reconstructs this transaction from the DlcOffer and DlcAccept messages and validates that it matches the on-chain output.
Magnolia is a blinded oracle. It monitors four objective events for each loan and publishes a Schnorr signature (attestation) on whichever one occurs first:
1. Was the loan funded within 48 hours?
2. Was USDC repayment received?
3. Did the BTC price cross the liquidation threshold?
4. Did the maturity date pass without repayment?
The oracle's attestation is the trigger that "unlocks" the correct pre-signed transaction. Without the attestation, none of the outcome transactions can be broadcast. The oracle does not know who the borrower is, who the lender is, how much BTC is locked, or what the contract addresses are. You can verify the oracle's identity on the Oracle page — the pubkey and uptime are fetched live.
Oracle advantage explained →Before the contract starts, both parties pre-sign one transaction per possible outcome. These are called Contract Execution Transactions (CETs). Each CET uses an adaptor signature — a cryptographic commitment that can only be completed when the oracle publishes its attestation for that specific outcome.
Lygos loans use 4 enumerated outcomes instead of thousands of numeric price points. This means only 4 adaptor signatures need to be generated and verified, which makes the contract:
| Metric | Numeric DLC | Enumerated DLC (Lygos) |
|---|---|---|
| Setup time | 1–2 minutes | ~5 seconds |
| Signatures | 1,000+ | 4 |
| User verification | Complex curve | 4 clear outcomes |
| Hardware wallet support | Impractical | Possible |
On the loan detail page, the "Pre-signed outcomes" node shows the count and verification status. When you click "Verify now", the dlc-verify engine checks every adaptor signature cryptographically using the DDK (Discreet Log Contract Development Kit).
Enumerated vs numeric DLCs →Every Lygos DLC loan resolves to exactly one of four endpoints. These are the outcome branches at the bottom of the decision tree on each loan page:
Each outcome has a pre-signed transaction that specifies exactly how many sats go to borrower and how many go to lender. You can inspect these exact amounts by clicking any outcome branch in the decision tree after verification.
Full loan flow →
Every DLC includes a time-locked refund transaction as a safety valve.
If both Lygos and the oracle disappear entirely, the borrower's collateral is returned
automatically after the refundLocktime expires.
This is the dashed "refund timeout" path at the bottom of the decision tree on each loan page. It ensures that borrower funds are never permanently stranded, even in a catastrophic infrastructure failure. The refund locktime is set far enough in the future (typically months after maturity) to give the oracle ample time to attest under normal conditions.
DLC safety properties →
When you click Verify now on a loan, the open-source
dlc-verify engine runs a complete cryptographic audit:
1. Parses the raw DlcOffer and DlcAccept hex messages
2. Extracts the oracle public key and event identifier
3. Reconstructs the funding transaction and computes the contract ID
4. Verifies each CET adaptor signature using the DDK cryptographic library
5. Validates the oracle's Schnorr attestation signature via bip-schnorr
6. Parses the pre-signed outcomes and sats allocations
The decision tree on the loan page illuminates progressively as each step passes. Every field — pubkeys, txids, sats, locktimes — is clickable for inspection. The raw JSON response is available at the bottom for the paranoid auditor.
Source code: github.com/LygosLabs/dlc-verify
Verification philosophy →Magnolia publishes attestations to events, not to contracts. The oracle does not know:
Borrower identity — unknown
Lender identity — unknown
Collateral amount — unknown
Payout addresses — unknown
Contract terms — unknown
On-chain, the DLC looks like a standard 2-of-2 multisig — indistinguishable from any other Bitcoin transaction. The oracle's attestation reveals which outcome occurred, not who was involved or how much was at stake.
Oracle privacy model →At no point does Lygos, the oracle, or any third party hold the borrower's Bitcoin. The collateral sits in a 2-of-2 multisig that requires both borrower and lender signatures.
Since both parties can cooperatively sign new transactions, the contract terms can be renegotiated — extend maturity, adjust repayment, or unwind the position entirely — without oracle involvement. This is a key difference from multi-sig arbiter models where a third party must actively participate in execution.
DLC vs multi-sig arbiter →