Bitcoin was built as a ledger for its own currency, not as a general-purpose smart-contract platform, and that design choice has long constrained how contracts on the network can react to events happening in the world outside the chain. A new scoping review published in Frontiers in Blockchain examines what has happened to Bitcoin oracle designs since Ethereum’s launch in 2015, when much decentralized application development migrated away from Bitcoin. The study, by Giulio Caldarelli of the University of Turin, finds that the main post-2015 shift is from multi-signature schemes, in which oracles acted as co-signers of transactions, toward attestation-based designs, chiefly Discreet Log Contracts, or DLCs, which align better with Bitcoin’s constraints and show evidence of real-world use in betting and prediction markets.
Oracles are the mechanisms that let Bitcoin contracts depend on exogenous events, such as the outcome of a sports match or a price level. The problem is old. One of the earliest documented proposals appears on the Bitcoin Wiki: in 2011, developer Mike Hearn suggested handling Bitcoin inheritance by making a transaction contingent on extrinsic information, the wallet owner’s death, supplied by an oracle. The basic construction was an m-of-n multi-signature output in which one key belonged to an arbiter who co-signed, and thereby unlocked, the transaction once a specified event outcome was verified. Satoshi Nakamoto was skeptical about introducing a third party, since a trusted data reporter reintroduces a single point of failure into the blockchain, but the idea attracted developers who extended the concept.
Several early projects pushed the multi-signature model further. Oraclize went beyond simple m-of-n schemes by providing authenticity proofs that let users verify the provenance and integrity of retrieved data. The Orisi project attacked single-oracle trust directly, proposing m-of-n schemes with much higher thresholds, such as 8-of-11, spreading the oracle role across multiple independent entities to improve fault tolerance and availability. These systems worked for simple bets, but implementing prediction markets proved harder and required features Bitcoin could not provide. Truthcoin proposed shifting oracle computations to auxiliary chains while relying on Bitcoin for final settlement, an early sidechain concept whose practical development turned out to be far slower than anticipated. Counterparty implemented oracle and exchange functions through a metaprotocol encoded in Bitcoin transactions using the OP_RETURN field, but growing use of OP_RETURN for application data raised community concerns about blockchain bloat, contributing to pressure to limit its size. That debate, often labeled a war, was among the factors that pushed early Bitcoin enthusiast Vitalik Buterin to build his own chain with explicit smart-contract and oracle support.
When Ethereum arrived in 2015, oracle developers gravitated toward it, drawn by its expressive smart-contract model, development resources, funding opportunities, and accessible programming environment. Bitcoin, however, kept evolving. Segregated Witness improved transaction malleability and efficiency, and Taproot introduced Schnorr signatures and enhanced script privacy, enabling more flexible spending conditions. Combined with off-chain advances, these upgrades reopened the question of whether Bitcoin’s main blockchain could support more complex applications. The review addresses three questions: what new design avenues for Bitcoin oracles have emerged since 2015, how is Bitcoin-oracle development currently pursued, and which real-world applications are most documented on Bitcoin Layer 1.
The methodology reveals as much as the findings. Caldarelli queried Scopus and Web of Science on 4 December 2025 with the keywords Bitcoin AND Oracle, retrieving 181 and 96 records respectively. After merging and removing 92 duplicates, 277 records were screened by title and abstract; 166 were excluded as unrelated, 19 went to full-text assessment, and only one was retained. That retained work referenced relevant contributions disseminated outside journal venues, motivating a complementary Google Scholar search, which shortlisted 42 documents and retained 6. A second search round on 12 January 2026 using cryptographic oracle AND bitcoin and discreet log contracts added four more. Verification searches in July 2026 with terms such as event attestation, conditional payment, and adaptor signature yielded nothing new. The final corpus comprises eleven documents, a small number that supports the view that Bitcoin-native oracle mechanisms remain underexplored academically, with key contributions appearing as technical notes, whitepapers, master’s theses, and preprints rather than journal articles.
Within that corpus, DLCs dominate: eight of the eleven documents introduce, formalize, extend, or apply the design or closely related constructions. Introduced by Tadge Dryja in 2017, DLCs make Bitcoin payments contingent on external outcomes while avoiding explicit on-chain oracle messages. Two parties lock funds in a shared 2-of-2 output and pre-sign a set of Contract Execution Transactions, one for each possible outcome, storing them off-chain. The oracle, which may be a third party such as the Olivia implementation, publishes a long-term public key and commits in advance to a one-time nonce for each event, before the outcome is known. This lets parties calculate, for each possible outcome, the public value the oracle’s later attestation would produce, and link each CET to the appropriate outcome without the oracle knowing whether any contract relies on its announcement. When the event resolves, the oracle publishes one attestation for the actual outcome using the committed nonce. The attestation acts as a cryptographic key that unlocks only the CET for that outcome, letting the winning party combine it with a private key to claim the payout. A pre-signed refund transaction with a timelock lets either party recover funds if the oracle never attests or the process stalls.
The privacy and trust properties are central to the design’s appeal. Because the oracle attestation is off-chain and settlement transactions look like ordinary spends, DLCs reduce on-chain observability of both the contract structure and the oracle’s involvement, a marked improvement over multi-sig templates where the escrow-like arrangement is often evident on-chain. The oracle nonetheless remains a single point of trust, since participants must assume honest reporting. The advance nonce commitment does deter equivocation: if the oracle signs two different outcomes for the same event, the two attestations reveal its long-term private key, which any observer can calculate. But that mechanism cannot prevent a single false attestation, so parties must still trust the oracle to report the correct outcome. Dryja’s original 2017 proposal used script-based execution with penalty and timeout mechanisms, and because Bitcoin then supported only ECDSA, a Schnorr-style scheme was used only for the off-chain attestation. Modern DLC specifications implement the same model through adaptor signatures, which became practical on Bitcoin only after Schnorr arrived with Taproot’s activation in November 2021.
Later work refined the model. Lloyd Fournier gave adaptor signatures a formal foundation as one-time Verifiably Encrypted Signatures, noting that Dryja’s original approach could require three on-chain transactions to settle a bet in an uncooperative scenario, whereas the adaptor technique allows a two-transaction flow. Le Guilly and colleagues tested DLCs in practice and evaluated design choices, reporting benchmarks indicating their extensions, including digit-based attestation for large numeric ranges and threshold multi-oracle settings, remain computationally practical. Madathil and colleagues introduced Verifiable Witness Encryption based on Threshold Signatures, or VweTS, which supports multi-oracle selection without pre-building every possible signing combination, keeping setup essentially linear in the number of oracles, though it requires spending from 2-of-2 multi-signature addresses that increase on-chain footprint and fees. Han and colleagues responded with Vwe2psTS, enabling such payments from joint addresses indistinguishable from regular single-signature spends, with at least a 40 percent reduction in communication cost relative to VweTS at the price of higher storage. DLCs, by contrast, are backed by an open standard, dlc-specs, and practical toolkits such as the DLC Dev Kit, while VweTS-based constructions remain a research and prototype direction without a comparably standardized tooling stack.
Applications cluster tightly around betting and prediction markets, a pattern the review argues is not accidental, since discrete-event contracts align naturally with the binary or small-outcome oracles Bitcoin supports. Fournier proposed a DLC-based prediction market coordinated via Twitter, targeting two rounds of communication and two on-chain transactions, with encrypted offers and randomized on-chain keys to protect winner and offer privacy, while acknowledging leakage from the public board and an unsolved market-manipulation risk called post-event acceptance. Pierog proposed a non-custodial prediction market combining an LMSR-style automated market maker with DLCs, highlighting that collateral stays locked until resolution so traders cannot sell positions early, which can stall trading and price discovery. Patel’s Transformable DLCs address this by pre-arranging transformation transactions that let a third party swap into a contract mid-way, with a stronger variant allowing multiple trades among a predefined set of participants, at the cost of added setup complexity. A complementary oracle-less line, Hartman and colleagues’ Blockrate Binaries, settles binary derivatives on block height or timestamps, removing oracle trust but introducing confirmation-race and transaction-delay risks, and remaining suited to a narrow class of events.
The review’s broader conclusions are measured. Bitcoin-native oracle development appears driven mainly by practitioners, and the quality appraisal found some non-peer-reviewed sources scoring high on technical validation and implementation evidence, supporting multivocal review methods in this field. Compared with EVM chains, where oracle networks continuously update shared on-chain feeds, Bitcoin designs minimize on-chain oracle state, relying on off-chain attestations that unlock settlement paths in isolated contracts, making usage more per-contract and event-driven. The author notes that attestation-based designs do not eliminate residual oracle risks but move them to the off-chain process of selecting and evaluating oracles, and that incentive attacks and data-source integrity remain largely unexplored in the literature. Two propositions are offered as hypotheses rather than findings: that Bitcoin contracts based on external oracles currently seem better suited to bespoke, high-value agreements between sophisticated counterparties than to mass-market composable applications, and that richer oracle-based functions such as continuous feeds are more likely to emerge through off-chain integrations or Bitcoin-adjacent layers. Both, the review stresses, require empirical evidence on actual adoption that a literature-based study cannot provide.
Subject of Research: Evolution of Bitcoin Layer 1 oracle designs from multi-signature schemes to attestation-based Discreet Log Contracts since 2015
Article Title: From multi-sig to DLCs: modern oracle designs on Bitcoin
Article References: Caldarelli, G. (2026). From multi-sig to DLCs: modern oracle designs on Bitcoin. Frontiers in Blockchain, 9, Article 1903194. https://doi.org/10.3389/fbloc.2026.1903194
Image Credits: AI Generated
DOI: 10.3389/fbloc.2026.1903194
Keywords: Bitcoin, oracles, Discreet Log Contracts, DLCs, multi-signature, adaptor signatures, VweTS, prediction markets, Taproot, scoping review, blockchain, cryptocurrency
News Source: Gavin Prescott. (November 5, 2026). Bitcoin’s oracle evolution: from multi-sig co-signers to DLC attestations. Scienmag.
