The Oracle Problem: Where Every Blockchain Hits a Wall

A blockchain is, by design, a closed system. It can verify its own state with mathematical certainty – whether a transaction was signed correctly, whether a UTXO exists, whether a smart contract condition was met. What it cannot do natively is reach out and verify the real world: whether Bitcoin’s price closed above $100,000, whether a flight landed on time, whether a sporting event ended 3-1.

This gap is called the oracle problem, and every serious blockchain application eventually runs into it. How you solve it reveals your underlying philosophy about trust, privacy, and what a blockchain is actually for.

Bitcoin and Ethereum have answered this question in starkly different ways. Bitcoin’s answer, refined over the past decade, is the Discreet Log Contract (DLC). Ethereum’s answer is a thriving ecosystem of decentralized oracle networks like Chainlink, UMA, Pyth, and more. Understanding the difference between these two approaches is essential for anyone building or investing in decentralized financial infrastructure.

Part I: The Bitcoin Path – From Multi-Sig to Discreet Log Contracts

The Early Days: Oracles as Co-Signers

The first attempts to bring external data to Bitcoin were conceptually simple. If Alice and Bob want to settle a bet based on an external outcome, they could add a third party – an oracle – as a required co-signer in a 2-of-3 multi-signature arrangement. The oracle holds one key, Alice holds one, Bob holds the other. When the event resolves, the oracle co-signs the winning party’s transaction.

Projects like Orisi (2014) refined this by using larger oracle federations (e.g., 8-of-11 multi-sig), distributing trust across multiple independent signers to reduce the risk of collusion or failure. Oraclize (later renamed Provable) introduced Trusted Execution Environments (TEEs) to cryptographically attest that data was fetched from a declared source without manipulation.

These designs worked for simple bets but had critical limitations:

– Privacy: The oracle’s identity and the contract structure were often visible on-chain. Anyone watching the blockchain could see that an escrow-style arrangement existed between specific parties.
– Cost and scalability: Multi-sig outputs with oracle keys embedded in spending conditions are expensive. Every oracle interaction created on-chain footprint.
– Continuous data: When applications demanded continuously updated price feeds (for a decentralized exchange, for example), multi-sig schemes broke down entirely. You can’t afford an on-chain oracle transaction for every price update.

These limitations, combined with the expressiveness of Ethereum’s smart contract model, caused a mass migration of oracle developers toward the EVM ecosystem after 2015. Bitcoin’s oracle development continued, but quietly, mostly outside academic journals – in mailing lists, GitHub repositories, and technical notes.

The DLC Breakthrough: Thaddeus Dryja, 2017

In 2017, Thaddeus Dryja – co-creator of the Lightning Network – published a technical note introducing Discreet Log Contracts. The name is a deliberate pun: these contracts exploit the mathematical hardness of the discrete logarithm problem, and they are discreet in the sense that they leave minimal observable trace on-chain.

The core insight was radical: what if the oracle never needs to touch the blockchain at all?

How DLCs Work

The mechanics are elegant. Suppose Alice and Bob want to enter a BTC/USD futures contract settling at a specific date, with payouts depending on Bitcoin’s price at expiration.

Step 1 – Funding. Alice and Bob each lock collateral into a shared 2-of-2 multi-signature output. This is the funding transaction – the only on-chain step at setup.

Step 2 – Pre-signed outcomes. Before broadcasting the funding transaction, Alice and Bob pre-sign a set of Contract Execution Transactions (CETs) – one for each possible outcome. If the oracle will attest a price between $90,000 and $110,000, they pre-sign a CET for each price point (or range), specifying the correct payout split for that outcome. These CETs are stored off-chain.

Step 3 – The oracle’s cryptographic commitment. The oracle (say, “Olivia”) plays a critical but non-custodial role. Before the event, she publishes:
– Her long-term public key V = vG
– A one-time nonce point R = kG committed to this specific event, along with metadata (what is being attested, when, how outcomes are encoded)

From these public parameters, Alice and Bob can precompute, for each possible outcome i, a public key s_i·G = R − h(i,R)·V. They use these to “tweak” their own public keys in the CET outputs – so each CET can only be spent by the party whose key was tweaked for the realized outcome.

Step 4 – Settlement. When the event resolves, the oracle signs the realized outcome m (e.g., price = $102,400) and publishes the signature scalar s_m = k − h(m,R)·v. This single off-chain signature reveals the secret that allows the winning party to reconstruct their spending key for the correct CET and broadcast it.

The on-chain result looks like a completely ordinary Bitcoin transaction. No oracle address appears. No contract structure is visible. The settlement transaction is indistinguishable from a regular payment.

The Equivocation Deterrent

A clever cryptographic property protects against oracle fraud: if the oracle signs two different outcomes m₁ ≠ m₂ using the same nonce R, anyone can compute s₁ − s₂ = (h(m₂,R) − h(m₁,R))·v – which directly reveals the oracle’s long-term private key v. This creates a strong cryptographic deterrent against double-reporting. It cannot prevent a single false attestation, but it makes oracle fraud permanently and provably costly.

Adaptor Signatures: The Modern DLC

Dryja’s original design predated Bitcoin’s Taproot upgrade (November 2021), which activated Schnorr signatures via BIP340. Lloyd Fournier’s 2019 work on adaptor signatures (formalized as One-Time Verifiable Encrypted Signatures) simplified and modernized the DLC construction significantly.

An adaptor signature is a “locked” signature: verifiably correct, but not yet usable. It becomes a valid signature only when a specific secret (the oracle’s attestation scalar) is revealed. The practical effect:
– Setup requires only a single joint funding output
– Settlement requires only one broadcast transaction
– With Schnorr (post-Taproot), the settlement transaction is indistinguishable from an ordinary single-key spend – maximum privacy

Pre-Taproot implementations had to use workarounds for ECDSA, which were fragile and often required semi-scriptless constructions relying on OP_CHECKMULTISIG. Taproot made DLCs clean and production-ready.

Extensions: Scaling the DLC Model

DLCs in their base form have limitations, particularly around scalability to many outcomes and multi-oracle threshold settings. Several important extensions address these:

Le Guilly et al. (2022) introduced digit decomposition: instead of pre-signing a CET for every possible price point, the oracle attests to each digit of the value separately. This compresses the number of required CETs from potentially thousands to a small set of prefix patterns, substantially reducing setup cost at the price of additional client-side computation.

VweTS (Verifiable Witness Encryption based on Threshold Signatures), introduced by Madathil et al. (2023), takes a different approach to multi-oracle settings. Rather than preparing adaptor signature paths for every possible combination of oracles (which grows combinatorially in a t-of-n setting), VweTS prepares one settlement transaction per outcome and “locks” the payment authorization so it becomes usable only when a sufficient threshold of oracle attestations is collected. The oracle attestations act as witnesses that decrypt the valid payment signature. This scales linearly in the number of oracles rather than combinatorially.

Vwe2psTS (2025) extends this further: it enables the same oracle-conditional payments from standard two-party joint addresses that are indistinguishable from regular single-key spends – reducing on-chain footprint, communication costs, and censorship exposure simultaneously.

Transformable DLCs (TDLCs) allow a party to exit a position before settlement by pre-arranging “transformation” transactions that substitute a new counterparty’s key into the contract, approximating secondary-market trading of Bitcoin-native futures.

DLC Markets (Pantamis, 2024) builds a full institutional-grade OTC derivatives platform on this foundation, introducing:
– A coordinator that solves the “free option” problem (where one party can hold a fully-signed funding transaction and exercise it opportunistically)
– DLC renewal as a margin call mechanism: instead of over-collateralizing, parties periodically replace the running DLC with a new one with updated collateral levels
– Disjoint union DLCs for liquidation: a single contract encompassing multiple intermediate “liquidation contracts” at earlier oracle maturities, enabling liquidation before final settlement if prices move beyond the collateral range

The DLC Ecosystem Today

DLCs are no longer just a research idea. There is:
– dlcspecs: An open standard for DLC protocol messages and wire formats
– rust-dlc: A production Rust implementation
– DLC Dev Kit: A modular framework covering the full DLC lifecycle
– bitcoin-s: A JVM toolkit with DLC support
– Real deployments in applications like Mutiny wallet and 10101 Finance

Part II: The EVM Path – Shared Oracle Infrastructure

While Bitcoin was refining attestation-based oracles, Ethereum’s expressiveness enabled a fundamentally different architecture: oracles as shared, continuously-updated, on-chain infrastructure.

Chainlink: The Oracle Network as Public Utility

Chainlink (launched 2017) is the dominant oracle network in the EVM ecosystem and arguably the most influential oracle design in crypto history. Its architecture is built around decentralized oracle networks (DONs): committees of independent node operators who each fetch data from multiple off-chain sources, aggregate the results, and submit them to an on-chain aggregator contract.

Key design elements:
– Node operator staking: Operators stake LINK tokens as collateral. Misbehavior (submitting outlier data, failing to respond) is penalized through slashing.
– On-chain aggregation: A smart contract collects reports from nodes, applies an aggregation function (typically median), and stores the result on-chain as a price feed – a persistent, addressable data point.
– Push model: Price feeds are updated either on a time schedule or when the price deviation exceeds a threshold (e.g., 0.5%).
– Composability: Any smart contract on the same chain can read any price feed with a simple function call. This shared infrastructure powers the entire DeFi ecosystem – lending protocols (Aave, Compound), synthetic assets, stablecoins, and derivatives platforms all read from the same Chainlink feed.

Chainlink has expanded significantly beyond price feeds: Chainlink CCIP handles cross-chain messaging, Chainlink Automation handles on-chain job scheduling, and Chainlink VRF provides verifiable randomness, and most recently Chainlink CRE (Chailnk Runtime Environment) as an all-in-one orchestration layer for data on-chain.

UMA: Optimistic Oracles and Dispute Resolution

UMA Protocol takes a different approach centered on game theory rather than cryptography. Its Optimistic Oracle works as follows:
– Anyone can propose a price for a specific identifier (e.g., “BTC/USD at timestamp T”)
– There is a dispute window (typically 2 hours) during which any party can contest the proposed value by staking a bond
– If undisputed, the value is accepted
– If disputed, the question is escalated to UMA’s Data Verification Mechanism (DVM): UMA token holders vote on the correct value, with economic incentives designed to make honest voting the Nash equilibrium
– The loser of the dispute forfeits their bond

UMA is optimized for long-tail oracle requests – events that no centralized feed covers, including custom financial contracts, insurance payouts, prediction market resolution, and governance queries. Its permissionless model means anyone can request a price for anything, at the cost of latency (the dispute window).

UMA also powers the Optimistic Oracle V3 used by protocols like Across (cross-chain bridge) and Polymarket (prediction market), where its dispute resolution layer serves as a backstop for complex assertions beyond simple price feeds.

Pyth Network: High-Frequency First-Party Feeds

Pyth (launched 2021) attacks a specific weakness of aggregator models: latency and staleness. Traditional oracle networks aggregate from secondary data providers; Pyth instead connects first-party data providers – major trading firms, exchanges, and market makers (Jump Trading, Jane Street, Cboe, Binance) – who publish their own proprietary price data directly.

Key characteristics:
– Pull model: Rather than pushing data on-chain continuously (expensive), Pyth publishes signed price updates off-chain. Applications pull the update they need, verifying it on-chain at the time of use. This makes Pyth extremely cost-efficient for high-frequency applications.
– Confidence intervals: Each Pyth price comes with a confidence interval reflecting the spread across contributing publishers. This is particularly valuable for risk management.
– Sub-second latency: Updates are published roughly every 400ms, enabling applications like perpetuals platforms that need near-real-time pricing.
– Cross-chain: Pyth uses Wormhole to push attestations to 50+ chains simultaneously.

Pyth has become the dominant oracle for high-frequency DeFi, particularly on Solana and for perpetuals protocols (GMX, dYdX, Drift).

Band Protocol: Cross-Chain Oracle via Cosmos

Band Protocol operates as an oracle-specific blockchain built on the Cosmos SDK. Oracle scripts are deployed on BandChain; validators execute data requests by fetching from configured data sources and aggregating results. Proofs are then relayed to destination chains via IBC (for Cosmos) or bridge contracts (for EVM chains).

Band’s architecture prioritizes cross-chain composability and customizable oracle scripts – developers can define exactly how data is fetched, aggregated, and validated using WebAssembly programs.

API3: First-Party Oracles Without Middleware

API3 challenges the “middleware oracle” model entirely. Rather than having third-party node operators relay data from APIs, API3 enables API providers to run their own oracle nodes (Airnodes) directly. The data provider is also the oracle operator, eliminating the middleware layer and its associated trust assumptions and margins.

API3 also introduced dAPIs – managed data feeds backed by insurance-like coverage funded through the API3 DAO, providing a business model for oracle reliability guarantees.

Part III: The Fundamental Architectural Divide

Having described both approaches in depth, the differences go beyond implementation details. They reflect different philosophies about what a blockchain is and what “trustless” means.

1. On-Chain State vs. Off-Chain Attestation

This is the most fundamental divide.

EVM oracle networks treat oracle data as shared on-chain state. A Chainlink price feed is a smart contract with a publicly readable current value. Any other contract on the chain can compose with it. The oracle’s role is to continuously maintain this state, and the blockchain itself enforces that the data was submitted by authorized nodes. The trust is in the network and the staking mechanism.

DLCs treat oracle data as private off-chain attestation. The oracle publishes one signature for one event. This signature is used by the contracting parties privately, off-chain, to determine which pre-signed CET becomes valid. The blockchain never sees the oracle data – it only sees two ordinary-looking transactions (funding and settlement). Trust is in the oracle’s cryptographic commitments and the equivocation deterrent.

2. Composability vs. Privacy

EVM oracles optimize for composability: because price data lives on-chain in a standardized interface, an entire DeFi ecosystem can be built on top. A lending protocol reads the price feed, a liquidation bot reads it, a derivatives protocol reads it – all using the same data, updated once, paying once. This composability enables the DeFi stack as we know it.

DLCs optimize for privacy and fungibility: because settlement looks like an ordinary Bitcoin spend, no external observer can determine that a financial contract was executed, who the parties were, or what oracle was used. This is a core Bitcoin value – transactions should be fungible and non-surveillance-amenable.

The trade-off is direct: you cannot have both simultaneously. Composability requires readable on-chain state. Privacy requires that nothing meaningful be on-chain.

3. Continuous Feeds vs. Event-Driven Attestation

EVM oracles maintain continuously updated feeds. Every 30 seconds (or whenever price moves by a threshold), a Chainlink node pushes an update. This is appropriate for DeFi applications that need to monitor positions continuously, calculate dynamic health ratios, or trigger liquidations automatically.

DLCs are event-driven: an oracle announces it will attest a specific value at a specific time. The parties set up their contract, wait for the event, receive the single attestation, and settle. There is no concept of “current price” in a DLC – only “price at maturity.” This makes DLCs naturally suited for options, futures, and binary bets with fixed expiry dates, but awkward for perpetuals or continuously-margined positions (though DLC Markets’ renewal mechanism addresses this).

4. Shared Infrastructure vs. Per-Contract Oracle Selection

On Ethereum, Chainlink is shared infrastructure. Every protocol uses the same ETH/USD feed. If that feed is manipulated, every protocol using it is affected simultaneously. The security model is centralized at the feed level, diversified at the node operator level.

In DLCs, each contract selects its own oracle(s). There is no single oracle registry that all contracts must use. Alice and Bob can choose Olivia; Carol and Dave can choose a different oracle entirely. This is more resilient against systemic oracle attacks but harder to reason about for composable applications.

5. Programmable Logic vs. Pre-Defined Outcomes

EVM smart contracts can execute arbitrary logic based on oracle data. A lending protocol can calculate a user’s health ratio, compare it to a threshold, trigger a liquidation, calculate the discount, and update state – all atomically, in a single transaction, in response to an oracle update.

DLC payouts must be entirely pre-defined at contract setup. Every possible outcome and its corresponding payout must be encoded as a CET before the contract is funded. This is fine for futures (discrete price buckets) and binary bets, but it makes complex, state-dependent logic difficult. DLCs are “smart contracts” in a narrow sense – they execute pre-agreed terms, but those terms cannot be dynamically computed in response to oracle data.

6. Collateral Model

EVM-based derivatives protocols typically allow dynamic margining: collateral requirements adjust based on current mark-to-market, positions can be partially liquidated, and rehypothecation is possible (the same collateral can secure multiple positions).

DLCs require full collateral locked at setup. Both Alice and Bob must lock their maximum possible loss at the time of contract creation. This is more capital-inefficient but eliminates counterparty risk entirely – there is no credit exposure whatsoever. DLC Markets’ renewal and liquidation mechanisms mitigate this somewhat, but the fundamental model is fully-collateralized bilateral contracts.

Part IV: Side-by-Side Comparison

 

Dimension	DLCs (Bitcoin)	Chainlink	UMA	Pyth
Settlement layer	Bitcoin L1	EVM (Ethereum, etc.)	EVM	Multi-chain
Oracle data on-chain?	No – off-chain attestation	Yes – persistent feed	Yes – on dispute	No – pulled on demand
Privacy	High – settlement indistinguishable from normal spend	Low – all data public	Low	Medium – pulled but readable
Composability	Low – bilateral contracts only	Very high – entire DeFi stack	High	High
Oracle trust model	Selected by parties; equivocation reveals private key	Staking/slashing via LINK	Game-theoretic dispute resolution (DVM)	First-party providers with reputation
Data type	Discrete events / price at expiry	Continuous price feeds	Any assertable fact	High-frequency price feeds
Update model	Single attestation at maturity	Push (time/deviation)	Pull (on request)	Pull (sub-second)
Collateral model	Fully-collateralized, bilateral	Dynamic, protocol-managed	Dynamic	Dynamic
Programmability	Pre-defined payout curves only	Arbitrary smart contract logic	Arbitrary (post-resolution)	Arbitrary smart contract logic
Custodianship	Truly non-custodial	Smart contract custody	Smart contract custody	Smart contract custody
Best suited for	OTC derivatives, bilateral bets, institutional hedging	Lending, AMMs, synthetic assets, liquidations	Prediction markets, custom financial contracts, insurance	Perpetuals, high-frequency trading
Bitcoin-native	Yes – UTXO model, no smart contract language required	No	No	No
Maturity / tooling	Growing (dlcspecs, rust-dlc, DLC Dev Kit)	Very mature	Mature	Mature on Solana/EVM

Part V: What This Means for Bitcoin Finance

The DLC model is not Bitcoin’s failed attempt to replicate what Ethereum does better. It is a deliberately different answer to a different question.

Ethereum asks: How do we build composable, programmable financial applications on a shared settlement layer?

Bitcoin asks: How do we execute trustless bilateral financial agreements on the most secure, most widely-held monetary base layer, with minimal on-chain footprint and no counterparty risk?

These are valid but different goals. The implications:

Bitcoin DLCs are best for:

– OTC institutional derivatives – two sophisticated counterparties hedging Bitcoin exposure with zero counterparty risk and no custodian. DLC Markets’ whitepaper explicitly frames this as the Bitcoin equivalent of the ISDA master agreement – enforced by cryptography rather than by law.
– Non-custodial self-sovereign finance – users who want financial contracts where nobody, not even a smart contract platform, holds their funds at any point
– Privacy-sensitive applications – where the existence of a financial relationship should not be visible on-chain
– Settlement finality on hardest money – Bitcoin’s security model and Nakamoto consensus provide the most battle-tested settlement layer in crypto; for large-value contracts, this matters

EVM oracle networks are best for:

– Composable DeFi protocols – lending, AMMs, stablecoins, synthetic assets, and any application that needs to atomically combine multiple data sources in complex logic
– Continuous margining and liquidations – protocols that need to monitor positions in real-time and act automatically without party intervention
– Permissionless market creation – anyone can launch a new market on Uniswap, Aave, or a UMA-powered prediction market without bilateral negotiation
– Long-tail oracle requests – UMA’s optimistic model handles arbitrary assertable facts that Chainlink’s curated feeds don’t cover

Part VI: The Tensions That Remain

Both approaches have unsolved problems worth being honest about.

DLC limitations:

– Oracle selection problem: Each bilateral contract requires the parties to agree on an oracle. For mass-market applications, there is no equivalent to Chainlink’s single authoritative feed. Who is the “trusted” oracle for Bitcoin’s price? The DLC ecosystem is beginning to address this through oracle registries and reputation systems, but it remains underdeveloped.
– Collateral efficiency: Fully-collateralized contracts are capital-inefficient relative to the dynamic margining on EVM platforms. Rolling DLC renewals (as in DLC Markets) partially address this but add complexity.
– Liquidity and exit: Once in a DLC, your collateral is locked. Transformable DLCs help, but secondary markets for DLC positions are nascent. Prediction markets built on DLCs specifically struggle with the continuous liquidity that EVM-based AMMs provide naturally.
– Complexity of setup: A DLC requires a multi-round negotiation protocol before the funding transaction can be broadcast. The “free option” problem – where one party can hold a signed funding transaction and exploit it – requires either a coordinator (as in DLC Markets) or complex protocol design.

EVM oracle limitations:

– Systemic oracle risk: A manipulated price feed doesn’t affect one contract – it affects every protocol using it simultaneously. The 2020 “flash loan oracle attacks” demonstrated how fragile on-chain price feeds can be under adversarial conditions.
– On-chain cost: Every feed update costs gas. For high-frequency data, this becomes expensive, which is why Pyth moved to a pull model.
– Smart contract risk: Every EVM protocol introduces smart contract risk on top of oracle risk. Bugs in aggregator contracts, proxy patterns, or the protocols themselves have cost billions in hacks.
– Privacy: All positions, liquidations, and oracle reads are visible on-chain. For institutional counterparties, this is often unacceptable.
– Custodianship: Smart contracts hold user funds. This is categorically different from a Bitcoin UTXO that only the owner’s key can spend.

Conclusion: Complementary, Not Competing

The deepest insight from comparing DLCs with EVM oracle networks is that they are not competing solutions to the same problem. They reflect the constraints and values of their underlying chains.

Bitcoin’s intentionally limited scripting language, its UTXO model, and its community’s emphasis on minimizing on-chain bloat all push toward attestation-based, event-driven, off-chain contracts that leave a minimal footprint. DLCs are the most sophisticated expression of this philosophy: mathematically elegant, privacy-preserving, truly non-custodial, and grounded in Bitcoin’s security.

Ethereum’s expressive smart contract model, its account-based state machine, and its community’s emphasis on permissionless composability push toward shared, continuously-updated, on-chain oracle infrastructure that enables complex, interconnected protocol stacks. Chainlink, UMA, and Pyth are the most sophisticated expressions of this philosophy.

As Bitcoin’s financial ecosystem matures – through DLC Markets, Lightning-integrated DLCs, and potential second-layer enhancements – the two approaches may increasingly serve different segments of the market: DLCs for sophisticated bilateral OTC contracts where privacy, self-custody, and Bitcoin-native settlement matter; EVM oracles for permissionless, composable retail DeFi where continuous liquidity and complex programmatic logic are more important than privacy or custodial purity.

The question is not which approach “wins.” It’s understanding which one fits the specific requirements of the financial application you are building – and recognizing that the choice is really a choice about what kind of trust, privacy, and settlement guarantees your users need.

—

Sources:
– Caldarelli, G. “From Multi-sig to DLCs: Modern Oracle Designs on Bitcoin” (2025, preprint 2602.09822);
– Pantamis, T. “DLC Markets: A Non-Custodial Bitcoin Derivatives Trading System” (2024);
– Dryja, T. “Discreet Log Contracts” (2017);
– Le Guilly, T. et al. “Bitcoin Oracle Contracts: Discreet Log Contracts in Practice” (ICBC 2022);
– Madathil, V. et al. “Cryptographic Oracle-Based Conditional Payments” (NDSS 2023);
– Han, P. et al. “Vwe2psTS: Supporting Oracle-Based Conditional Payments from Joint Addresses” (IEEE Blockchain 2025).