Why prediction markets need zkTLS, not oracles

For most of the on-chain era, “how does the smart contract know what happened in the real world” had one answer: an oracle network. Chainlink popularized the model, UMA refined it, Pyth specialized it. The pattern is the same: a set of off-chain participants attest to a fact, the contract trusts the aggregate, and a cryptoeconomic game keeps reporters honest. That model worked. It is also no longer the best available answer for prediction market settlement, and Mentat is built on the bet that zkTLS makes it obsolete for the common case.

This post is the architectural argument.

What an oracle actually is

An oracle network is a trust-minimized data delivery layer. Take Chainlink as the canonical example: a set of node operators, each independently fetching a price feed from primary sources, signing their report, and submitting it on-chain. The contract aggregates the signed reports (usually with a median) and writes the result. The cryptoeconomic guarantee is that corrupting the median requires corrupting a quorum of independent operators, each of whom has stake at risk.

UMA’s optimistic oracle is a different shape but the same idea: a proposer asserts an outcome, a challenge window opens, anyone with a bond can dispute, and disputes are resolved by token-weighted voting. The trust assumption is that DVM token holders are economically rational enough to vote honestly because dishonest voting devalues their own holdings.

Both architectures share a fundamental property: the chain trusts the network, not the source. The Chainlink contract has no way to verify that the operators actually queried Coinbase or that the prices they signed reflect real Coinbase responses. It trusts that the cryptoeconomic incentives keep them honest in aggregate. UMA’s contract has no way to verify what actually happened in the world; it trusts that the DVM voters will reach the truth.

For 2017, that was the best available trust model. The chain could not look at TLS sessions directly. The only way to bridge off-chain data on-chain was to build a separate trusted layer and minimize its trust through economic games.

What zkTLS changes

zkTLS — short for zero-knowledge TLS proofs, sometimes also called web proofs — flips the trust direction. Instead of trusting a network of operators to faithfully relay data, the chain verifies a cryptographic proof that a specific TLS handshake against a specific domain returned a specific response body at a specific time.

The mechanic, in TLSNotary style:

A prover initiates a TLS session with api.coingecko.com.
A notary participates in the session in a way that lets it co-sign a commitment to the transcript without learning the plaintext.
The prover generates a zero-knowledge proof that asserts: “I conducted a TLS 1.3 session with this domain, the server’s certificate chained to this CA root, the request body contained this path, and the response contained this JSON fragment matching this JSONPath query.”
The proof and a small public input are submitted on-chain.
The settlement contract verifies the proof using a precompile or a Groth16 / Plonk verifier.

The trust shifts from “an oracle network operated honestly” to “TLS 1.3 is sound, the certificate authority chain is sound, and the verifier circuit is correct.” Those are well-studied cryptographic primitives. The notary participates in the protocol but cannot lie about transcript content because the proof binds the public output to the cryptographic transcript commitment.

For mechanically-resolvable outcomes — did this API return a value above this threshold, did this response body contain this exact phrase, was this transaction hash visible at this block — zkTLS gives the chain something an oracle network can never give it: direct cryptographic evidence about the source, not about the relayer.

Why this matters for prediction markets specifically

Prediction markets are oracle networks’ hardest case. Here’s why.

Pricing data is structurally robust. Bitcoin’s price is the median of many liquid venues; if Coinbase reports $97,432 and Binance reports $97,415, the consensus is obvious. Oracle networks can median across venues and the aggregation cleans most noise.

Prediction market outcomes are categorical and often unique. “Did Candidate X win the election” has one canonical answer published by one canonical body. “Did the Federal Reserve raise rates by 25bps on this date” has one canonical answer in the FOMC statement. There is no median to take. The oracle network either reports the canonical source correctly or it does not. Aggregation across multiple operators reading the same source provides only resistance to operator corruption; it provides no help if the source itself is misinterpreted.

This is where dispute mechanisms enter. UMA optimistic oracle adds a challenge window precisely because reading and interpreting canonical sources is harder than reading numeric APIs. The 2024 Polymarket election cycle saw repeated disputes about exactly what counted — did this candidate’s path to a specific outcome materialize, did this Trump-related event meet the trigger condition, when does a market “really” resolve. These were not Chainlink-style “is the price feed accurate” disputes. They were “does this source say what we think it says” disputes. UMA voters had to interpret.

zkTLS removes the interpretation layer for the common case. If the market spec says “resolve YES if https://www.federalreserve.gov/newsevents/pressreleases.htm contains the phrase ‘raised the target range by 25 basis points’ within 24 hours of the FOMC meeting date,” then a zkTLS proof can directly attest to whether that exact phrase appeared. The market spec encodes the interpretation; the proof confirms the data. No interpretation drift between reporters.

What zkTLS does not solve

We are not arguing that zkTLS makes every market mechanical. Some markets remain irreducibly interpretive: “Did the candidate concede” is a hard problem regardless of cryptographic infrastructure, because “concede” is a fuzzy predicate over a stream of statements made by various parties.

For those markets, two things matter:

The market spec should be honest about the interpretation surface. If you write a market that requires a human to decide whether some event “really happened,” you are writing a market that needs an arbiter. UMA-style optimistic settlement is the right tool. Mentat supports a fallback dispute path precisely for these cases.
The Validator agent should refuse to ship those markets without a clean trigger. This is the AI pipeline’s job: rewrite “did the candidate concede” into “did the candidate publish a concession statement on their official campaign account before [date]” — a trigger zkTLS can verify directly.

In other words: most markets should be mechanizable. Authoring that catches non-mechanizable markets and either fixes the trigger or sends them to the dispute lane is the missing piece, and the AI pipeline plus curator workflow is how Mentat handles it.

What this looks like in the protocol

The Mentat resolution path is a simple state machine:

Draft → PendingLaunch → Active → Locked? → Resolved | Invalid | Disputed
                                       ↘
                                        Proof verified on-chain

The settlement program (MarketSettlement) accepts a proof artifact and verifies it against the spec’s trigger condition. Verification success transitions the market to Resolved{YES|NO} and triggers payout. Verification failure (no proof submitted before deadline, proof references a domain not in the source allowlist, trigger condition not met) transitions to Invalid and returns capital.

A dispute window opens after settlement. Challengers can post a bond and submit either a counter-proof or evidence that the trigger was misinterpreted. Disputes route to a governance layer outside the base protocol. The base case — clean proof, clean trigger — resolves without ceremony.

This is the architectural inversion. The oracle network model puts a cryptoeconomic game in the resolution path for every market. The zkTLS model puts a verifier in the resolution path for every market and a dispute game in the resolution path only for contested edges. That is a much smaller and slower attack surface and a much faster typical-case latency.

Caveats worth saying out loud

zkTLS is still maturing as a primitive. TLSNotary works for many cases; proving against TLS 1.3 with key exchange that resists MPC notary participation is still an active research area. Proof generation is non-trivially expensive — single-digit seconds to minutes depending on circuit size — though acceptable for prediction market timelines. On-chain verification cost is real and depends on the verifier circuit.

We are not claiming the primitive is fully production-grade today. We are claiming that the architectural direction is correct and the infrastructure is improving fast enough that designing the protocol around it now is the right bet. M4 ships the proof service. By M5 the primitive will be in better shape than UMA was at Augur’s launch, and we will know more about which markets benefit most from the model.

The argument in one sentence

Oracle networks trust the network; zkTLS trusts the source. For prediction markets, where outcomes are categorical and interpretation matters, trusting the source is the better trust model — and now finally an available one.