From Multi-sig to DLCs: Modern Oracle Designs on Bitcoin

Unlike Ethereum, which was conceived as a general-purpose smart-contract platform, Bitcoin was designed primarily as a transaction ledger for its native currency, which limits programmability for conditional applications. This constraint is particularly evident when considering oracles, mechanisms that enable Bitcoin contracts to depend on exogenous events. This paper investigates whether new oracle designs have emerged for Bitcoin Layer 1 since the 2015 transition to the Ethereum smart contracts era and whether subsequent Bitcoin improvement proposals have expanded oracles’ implementability. Using Scopus and Web of Science searches, complemented by Google Scholar to capture protocol proposals, we observe that the indexed academic coverage remains limited, and many contributions circulate outside journal venues. Within the retrieved corpus, the main post-2015 shift is from multisig-style, which envisioned oracles as co-signers, toward attestation-based designs, mainly represented by Discreet Log Contracts (DLCs), which show stronger Bitcoin community compliance, tool support, and evidence of practical implementations in real-world scenarios such as betting and prediction-market mechanisms.

💡 Research Summary

**
The paper “From Multi‑sig to DLCs: Modern Oracle Designs on Bitcoin” conducts a systematic review of oracle mechanisms that have emerged for Bitcoin’s layer‑1 since the 2015 rise of Ethereum. It begins by contrasting Bitcoin’s design—primarily a value‑transfer ledger with a limited scripting language—with Ethereum’s general‑purpose smart‑contract platform. This fundamental difference constrains Bitcoin’s ability to incorporate external data, a prerequisite for oracle‑driven contracts.

The authors trace the historical evolution of Bitcoin oracles. The earliest documented approach (2011) used an m‑of‑n multisignature output where one key was held by an “oracle” that co‑signed when a predefined external event (e.g., the owner’s death) occurred. While conceptually simple, this design introduced a single point of trust and was criticized by Satoshi‑era skeptics. Subsequent projects such as Oraclize and Orisi attempted to mitigate trust concentration by employing trusted execution environments (TEE) or by raising the multisig threshold (e.g., 8‑of‑11). However, these solutions ran into practical obstacles: Bitcoin’s script language could not express the required logic efficiently, and the use of OP_RETURN for data embedding sparked community concerns about blockchain bloat, leading to strict size limits.

The launch of Ethereum in 2015 attracted many oracle developers because of its expressive Solidity language, abundant tooling, and funding opportunities. Nonetheless, Bitcoin continued to evolve through protocol upgrades—SegWit, Taproot, and Schnorr signatures—that improved transaction malleability, privacy, and the expressive power of scripts. Taproot, in particular, allows complex spending conditions to be committed to a single public key, paving the way for more sophisticated conditional contracts without inflating on‑chain data.

Against this backdrop, Discrete Log Contracts (DLCs) emerged as the dominant post‑2015 oracle design. Introduced by Tadge Dryja in 2017, DLCs replace on‑chain oracle messages with a single cryptographic attestation: the oracle signs a value (e.g., a sports result) that corresponds to one pre‑signed Contract Execution Transaction (CET). The two parties lock funds in a 2‑of‑2 output, pre‑construct a CET for each possible outcome, and wait for the oracle’s signature. When the oracle publishes the appropriate signature, the corresponding CET becomes valid and can be broadcast, settling the contract without ever revealing the outcome on the blockchain. This approach yields three key benefits: (1) privacy—no explicit oracle data appears on‑chain; (2) scalability—only a single signature is needed, minimizing transaction size and fees; (3) simplicity—no complex script evaluation at settlement time.

The literature search combined Scopus, Web of Science, and Google Scholar, using “Bitcoin AND Oracle”. After de‑duplication and rigorous screening, only one indexed journal article met the criteria; the remainder were conference papers, technical notes, master theses, and pre‑prints. In total, eleven contributions (2016‑2025) were analyzed. Early works (2016‑2018) explored off‑chain automation and distributed‑oracle betting protocols. The 2019 introduction of adaptor signatures (a cryptographic primitive enabling DLCs) and later threshold‑signature schemes strengthened the underlying security model. From 2020 onward, a series of applied papers demonstrated real‑world use cases: Twitter‑based prediction markets, DLC‑based gambling platforms, block‑height binary contracts, and the development of transferable DLCs (TDLCs). Recent research (2023‑2025) focused on multi‑outcome extensions (Verifiable Witness Encryption, VweTS) and joint‑address constructions (Vwe2pTS) that reduce on‑chain footprint and improve censorship resistance.

The findings confirm that DLCs have become the primary mechanism for bringing external data onto Bitcoin’s main chain. They enjoy strong community adoption, tooling support (e.g., dLC‑Lib, Lightning‑DLC), and concrete deployments in betting, prediction markets, and binary contracts. Conversely, traditional multisig‑based oracle designs remain largely experimental, limited by privacy leaks and high transaction overhead.

A notable meta‑observation is the scarcity of peer‑reviewed academic literature on Bitcoin L1 oracles; most innovation circulates via developer forums, GitHub repositories, and conference workshops. The authors argue that future research should (1) formalize and standardize Bitcoin L1 oracle primitives, (2) build empirical security and performance benchmarks, and (3) explore the portability of DLC‑style attestation to other UTXO‑based chains and Layer‑2 solutions. By doing so, the Bitcoin ecosystem can continue to expand its conditional transaction capabilities while preserving the core security guarantees that distinguish it from general‑purpose smart‑contract platforms.