Oracle Attestation

An oracle attestation is the cryptographic signature an oracle publishes after a real-world event resolves, declaring which outcome actually occurred. In a Discreet Log Contract (DLC), this single piece of signed data is what unlocks the correct payout: the oracle signs a message such as an asset's closing price or a match result using a nonce it committed to in advance, and that signature doubles as the decryption key for exactly one of the contract's pre-arranged settlement paths. The elegance of the construction is that the oracle wields real power over settlement while remaining almost completely blind to what it is settling.

From signature to settlement

Before the event, the two contract parties build and pre-sign a set of contract execution transactions — one per possible outcome, each paying the parties according to their agreed terms for that outcome. These CETs are not immediately valid: each is locked with an adaptor signature that can only be completed using the oracle's signature over the corresponding outcome message. When the oracle publishes its attestation, the party favored by the real outcome takes that signature, completes the matching CET, and broadcasts it. On-chain, the result looks like an ordinary multisig-style spend — no contract terms, no oracle identity, nothing to distinguish it from mundane cooperative transactions. The oracle never sees the contract, never learns who used its data, and never touches any bitcoin. Its only power is to tell the truth or to lie — and lying, as we will see, is self-incriminating.

Attestation versus announcement

Attestation is the second act of a two-step protocol. First comes the announcement: before the event, the oracle publishes a commitment describing the event, enumerating its possible outcomes, and — critically — committing to the specific nonce it will use when signing the result. Contract parties build their CETs against this announcement. Later comes the attestation revealing the actual outcome under that committed nonce. This ordering is what gives the scheme its teeth: in Schnorr-style signatures, signing two different messages with the same nonce exposes the signer's private key through simple algebra. An oracle that equivocates — attesting to two different outcomes for the same event — mathematically forfeits its key, destroying its identity and any reputation attached to it. Cheating is not merely detectable; it leaves a cryptographic confession.

Trust, minimized but not eliminated

DLC oracles are trust-minimized, not trustless. An oracle can still sign a single wrong outcome (lying without equivocating), go silent, or collude with a counterparty — which is why serious deployments spread the risk across multiple independent oracles, settling contracts only when a threshold of attestations agree, and why contracts include timeout paths that refund the parties if attestations never arrive. The design philosophy will feel familiar to anyone in the sovereignty camp: rather than asking an institution to custody funds and adjudicate honestly, the protocol reduces the trusted party to a narrow, auditable role — sign one honest statement about the world — and makes betrayal both visible and costly. Built on Schnorr signatures and settled as plain Bitcoin transactions, attestation-based contracts extend what Bitcoin can express without bloating the chain or minting a token. See oracle announcement for the commitment half of the protocol.

For a sense of where this is used: attestation-based DLCs underpin non-custodial derivatives, prediction markets, and hedging arrangements between parties who never learn each other's identities and never post funds with an intermediary — including hashrate and difficulty hedges of direct interest to miners, where a contract can pay out based on an oracle's attestation of network conditions. The pattern generalizes: any agreement reducible to a signed statement about a public fact can settle this way, on-chain, with the oracle none the wiser. It is quiet infrastructure, and quiet is the point.