opML Explained: How Optimistic Machine Learning Verifies AI

When an autonomous trading agent moves a treasury, or a smart contract pays out a parametric insurance claim based on a model’s read of satellite imagery, someone has to answer an uncomfortable question: how does anyone know the AI actually said what the transaction claims it said? Large language models and vision models are not small, deterministic functions a smart contract can simply rerun; they are enormous, expensive, and often proprietary. Crypto has spent much of 2026 arguing over how to bridge that gap, and one of the oldest, most pragmatic answers is called opML.

Short for optimistic machine learning, opML does not try to make an AI computation provably correct the instant it happens. Instead it borrows a trick that already scaled Ethereum: publish the result, give everyone a window to challenge it, and only pay for real verification when somebody actually disagrees. The idea was formalized in a January 2024 research paper and now underpins Ora Protocol’s onchain AI oracle, one of a handful of live systems letting smart contracts consume AI outputs without simply trusting a centralized API. This piece covers how opML actually works, who built it, what it can and cannot verify, and how it compares with zero-knowledge and hardware-based alternatives.

What Is opML, Exactly?

opML stands for optimistic machine learning. The name is a direct nod to optimistic rollups, the scaling design behind Arbitrum and the OP Stack: assume a submitted result is correct by default, let anyone dispute it during a fixed window, and only spend expensive computation resolving an actual disagreement. Applied to AI, that means a service provider runs a model off-chain, whether inference or even training, posts the output plus a cryptographic commitment to the execution on-chain, and treats the result as final once a challenge period passes without a successful dispute.

The framework was formalized in the paper “opML: Optimistic Machine Learning on Blockchain”, published in January 2024 by KD Conway and collaborators at Hyper Oracle, the research team that became Ora Protocol. The paper describes its own fraud proof protocol as “reminiscent of the optimistic rollup systems,” a fair summary: opML is less a new cryptographic primitive than an application of an already battle-tested dispute mechanism to a workload, machine learning inference, too large and too expensive to run inside a smart contract directly.

That framing sets opML apart from its more cryptography-heavy cousin, zero-knowledge machine learning, or zkML, where verification is mathematically guaranteed from the first block rather than earned through a waiting period. opML instead makes incorrect results economically irrational, not cryptographically impossible. Ethereum co-founder Vitalik Buterin captured the stakes of this whole category in a widely cited January 2024 post, writing that “if an AI model that plays a key role in a mechanism is closed, you can’t verify its inner workings, and so it’s no better than a centralized application” (vitalik.eth.limo), a line that has become close to a mission statement for the entire verifiable-AI sector, opML included.

The Core Mechanism: Optimistic Execution and the Challenge Window

Strip away the cryptography and opML’s flow looks almost boring, which is the point. A requester, a smart contract, an agent, a dApp, submits an inference request specifying a model and an input. An opML node, sometimes called a prover or server in Ora’s own documentation, executes that model off-chain on ordinary hardware, a laptop or a GPU box rather than a specialized proving cluster, then submits the result on-chain along with a commitment representing the full execution trace, typically structured as a Merkle tree.

A challenge window then opens. Anyone running a verifier node can independently re-execute the same computation during that period and compare notes. If the posted result matches what the verifier computes, nothing happens: the result quietly finalizes once the window closes, and the requesting contract can safely act on it. If a verifier disagrees, it can post a challenge, triggering the dispute game covered in the next section.

The economics matter as much as the mechanics. opML nodes typically post a bond before submitting results; a successful challenge slashes that bond, often routing a share to the challenger as a reward for policing the system. That bond is what makes “optimistic” more than a euphemism for “unverified”: a dishonest node is not just caught, it loses money, and the challenger is paid to go looking. Ora’s documentation for its onchain AI oracle describes exactly this flow, publishing a request to opML nodes, uploading results on-chain, opening a challenge window for validators to dispute incorrect submissions, and only dispatching results to the requesting contract’s callback function once that window closes without a successful challenge (github.com/ora-io/OAO).

This also makes opML a liveness-dependent system rather than a purely cryptographic one, a distinction that matters later: its security comes from math plus the assumption that at least one economically motivated, competent watcher is paying attention during every challenge window.

Inside the Dispute Game: How Fraud Proofs Actually Get Resolved

The interesting engineering happens only once someone actually disputes a result, and this is the part of opML that borrows most directly from Truebit and, later, optimistic rollups. Re-running an entire large language model on-chain to settle a dispute would be absurdly expensive, so opML instead uses an interactive bisection protocol, sometimes called a verification game, to narrow a disagreement down to the single smallest step where two parties diverge.

In practice, the full computation, a neural network forward pass or a training step, gets broken into a sequence of discrete micro-instructions inside what Ora calls a Fraud Proof Virtual Machine, or FPVM. When a challenge is raised, the prover and challenger do not argue about the whole inference at once; the protocol has them repeatedly bisect the disputed range of steps, each round roughly halving the disagreement, until they isolate one instruction both sides agree is the exact point of divergence. That single instruction, and only that instruction, gets executed on-chain by a smart contract acting as referee. Because it is one step rather than an entire model pass, the on-chain computation stays cheap even when the underlying model has billions of parameters.

Ora’s technical documentation describes a two-track version of this design. A naive, single-phase implementation forces every step through the constrained virtual machine, safe but slow, since a VM cannot use a GPU. A newer multi-phase version lets most computation run natively on real hardware, GPUs included, invoking the VM only for the small disputed portion, cutting Merkle tree bookkeeping from roughly the product of graph nodes and micro-instructions down to roughly their sum, and delivering what the project describes as a speedup of “tens to hundreds of times” over the single-phase approach (github.com/ora-io/opml). Ora’s team first floated this design publicly on Optimism’s own governance forum in August 2023, pitching it explicitly as an efficient on-chain AI approach in the same optimistic tradition Optimism itself runs on.

The numbers the project has published for a simple case are modest but illustrative: a basic image-classification network finishes inference in roughly two seconds, with a full challenge and arbitration cycle wrapping up in about two minutes on a local test network, according to the project’s own benchmarks.

From Truebit to Optimistic Rollups: Where the Idea Came From

opML did not invent the idea of paying for trust only when trust is actually contested. That lineage runs back to Truebit, proposed years before Ethereum’s own scaling roadmap settled on optimistic rollups. Truebit’s design, laid out by Jason Teutsch and Christian Reitwiessner in the paper “A scalable verification solution for blockchains,” introduced the same core primitive opML now uses for AI: a solver performs an off-chain computation, a verifier can challenge it, and disagreement triggers a binary search across execution steps until a single disputed instruction is exposed and checked on-chain (people.cs.uchicago.edu).

Truebit itself never became the dominant way Ethereum scaled; that role went to optimistic rollups, Arbitrum and what became the OP Stack, which applied a similar challenge-and-bisect pattern to general EVM execution instead of arbitrary off-chain jobs, and which now secure many billions of dollars in value. opML’s own paper is candid about that lineage, describing its fraud proof protocol as “reminiscent of the optimistic rollup systems” rather than claiming an entirely novel security model.

What opML adds to that inherited design is a machine-learning-specific execution environment: a lightweight deep learning library built to replace TensorFlow or PyTorch inside the Fraud Proof VM, plus tooling to convert a trained model’s inference code into instructions the VM and its bisection protocol can handle deterministically. That word, deterministic, carries a lot of weight. Ordinary GPU-based machine learning is not guaranteed to produce byte-identical results across different hardware, drivers, or parallelization strategies, a real problem for any dispute system that needs two independent parties to agree on exactly what the correct output should have been. opML’s custom execution stack exists largely to tame that non-determinism well enough for a fraud proof to mean anything at all.

Ora Protocol and the Onchain AI Oracle

The team behind opML operates today as Ora Protocol, though the project traces back to Hyper Oracle, founded in September 2022 by Kartin Wong, a former Google software engineer and TikTok infrastructure lead. Cathie So, who previously led zero-knowledge machine learning research within the Ethereum Foundation’s Privacy and Scaling Explorations group, later joined as chief scientist, giving the team direct experience with both sides of the zkML-versus-opML question.

Ora raised $20 million in a round announced in June 2024, led by Polychain Capital, HF0, and HashKey Capital, funding earmarked for oracle research and blockchain infrastructure work. Wong described the company’s ambition simply, telling reporters the goal was to “unlock the design space for AI dapps” (coindesk.com), a modest way of describing an attempt to let smart contracts consume AI outputs the same way they already consume price feeds.

That ambition is built as the Onchain AI Oracle, or OAO: a set of smart contracts, secured by opML, deployed with matching addresses across Ethereum mainnet, Optimism, Arbitrum, Base, Polygon, Linea, Mantle, Manta, and BNB Chain. A contract anywhere in that footprint can request an inference, and OAO handles publishing the job to opML nodes, managing the challenge window, and calling back into the requesting contract once a result finalizes (github.com/ora-io/OAO). Ora also experimented with a more speculative concept alongside the oracle, the Initial Model Offering, an ERC-20 structure letting a trained model’s revenue be tokenized and shared with buyers, though it has drawn far less attention than the oracle itself.

Using OAO costs a small, fixed fee denominated in ORA, the project’s own token, priced by its documentation at roughly 0.01 to 1.00 ORA per model call depending on which model is invoked, functioning less like a governance token and more like gas paid specifically for AI inference requests.

What Models Can Actually Run

OAO’s documentation lists a fairly wide model menu: large language models including several Llama variants up to Llama 3.3 70B, Qwen, Mistral, Gemma, and DeepSeek-V3; image generators including Stable Diffusion 3 and 3.5 and multiple FLUX.1 variants; plus more specialized entries like the QwQ-32B reasoning model, Qwen2.5-Coder, and even proprietary APIs such as OpenAI’s GPT-4o and DALL-E 2 (github.com/ora-io/OAO).

That list needs one honest caveat. opML’s fraud proof only works if a challenger can actually re-execute the disputed computation, which in practice means the model’s weights and code have to be something a verifier can run independently. That holds for open-weight models like Llama or Stable Diffusion. It does not really hold for a closed API like GPT-4o, where nobody outside OpenAI can replay the exact computation to check it. For models like that, OAO functions more like a conventional attested oracle, relaying and recording an API response, than a system genuinely secured by opML’s dispute game. The distinction rarely gets spelled out in marketing copy, but it matters a great deal to anyone deciding how much trust a given OAO request actually deserves.

For the open-weight side of the list, the project’s own paper makes a notable claim: a 7-billion-parameter Llama model, roughly 26 gigabytes, can run entirely on a standard PC without a GPU, using the project’s lightweight inference library instead of TensorFlow or PyTorch. That is a self-reported benchmark rather than an independently audited one, but it lines up with the broader design goal: keep hardware requirements low enough that ordinary participants, not just well-capitalized proving farms, can realistically run a verifier node and actually contest bad results. A dispute system with only one plausible watcher is not much of a dispute system, so keeping the bar for participation low is a security decision, not just a cost one.

opML vs zkML: Two Different Bets on Trust

Set opML next to zkML and the contrast is really a contrast in when you pay for trust. zkML, covered in more depth in HOGE Wire’s own explainer on zk-ML’s real pitch, generates a cryptographic proof alongside the computation itself, so anyone can verify correctness almost instantly, without re-running anything and without trusting a single watcher to show up. That is a genuinely stronger guarantee: it holds even if nobody is paying attention, and it can preserve privacy in ways opML cannot, since a zero-knowledge proof can attest that a computation happened correctly without revealing the underlying inputs at all.

The cost of that guarantee is proving overhead. Turning a large neural network’s execution into a zero-knowledge circuit is computationally brutal, and the overhead tends to scale worse than linearly as models grow, which is exactly why billion-parameter LLMs remain largely out of reach for real-time zkML today. Projects like Succinct, whose SP1 zkVM and PROVE token are among the more actively used pieces of zero-knowledge infrastructure, are chipping away at that ceiling, but proving costs for anything resembling a modern frontier model are still in a completely different league than simply running the model.

opML flips that trade. Running the model off-chain costs roughly what running the model normally costs, no special circuit, no proving cluster. The price gets paid later, and only sometimes: in the latency of the challenge window every result has to sit through before it is safe to trust, and in the standing requirement that somebody, somewhere, is economically motivated to actually check. A zkML proof is trustworthy the instant it lands on-chain. An opML result is trustworthy only once its challenge window closes without incident, and only because the system assumes, correctly most of the time so far, that dishonesty does not pay.

Neither approach is strictly better; they suit different jobs. A payment that needs to settle within a single block has no patience for a challenge window and probably wants zkML, a trusted execution environment, or nothing on-chain at all. A parametric insurance payout, an oracle feed updating every few minutes, or an AI agent’s periodic portfolio rebalancing can usually absorb a delay measured in minutes or hours, which is exactly the workload opML was built for.

Four Ways to Verify AI Onchain

opML and zkML are really just two entries in a broader menu crypto has assembled for making AI trustworthy on-chain. A third approach leans on hardware instead of fraud proofs or zero-knowledge circuits: trusted execution environments, or TEEs, which run a model inside a sealed, attested enclave, chips like Intel TDX or Nvidia’s confidential-computing H100s, and let the hardware itself vouch that nobody tampered with the computation. Phala Network is the best-known crypto-native example, running tens of thousands of TEE devices and reporting inference overhead in the single digits, well below what either zkML or opML currently manage, in exchange for a different kind of trust: not a lone off-chain watcher, but the chip vendor, with the ever-present risk that someone finds a side-channel exploit.

A fourth approach skips cryptography and hardware attestation almost entirely and leans on plain economics: stake a large bond, promise to slash it if a service provably misbehaves, and let the cost of corruption do the enforcing. EigenCloud, the rebrand of EigenLayer, has pushed hardest into this lane with EigenCompute and EigenAI, framing restaked ETH’s economic security as a general-purpose guarantee that could back verifiable AI the same way it already backs other actively validated services, a pivot HOGE Wire covered in depth when EigenCloud named its first production integrations. Eigen Labs founder Sreeram Kannan has described the pitch bluntly: “EigenCloud will enable the next generation of disruptive, mass-market crypto apps, closing the gap between what developers want to build onchain and what blockchains allow them to build” (coindesk.com).

None of these four approaches has actually won, and the honest read of 2026 is that each occupies a different, defensible corner of a genuine trilemma between integrity, latency, and cost. opML’s corner is cheap computation and reasonable, though not instant, finality, at the price of needing an active watcher and tolerating a delay.

Prices above are approximate snapshots from CoinGecko on August 1, 2026, and move quickly; treat them as a snapshot of relative scale rather than a live quote.

The Trade-offs Nobody Skips

Every serious look at opML eventually runs into the same handful of uncomfortable trade-offs, and they are worth stating directly rather than burying in caveats.

The first is the honest-watcher problem. opML’s security model depends on somebody actually running a verifier and actually checking results during every challenge window. If nobody bothers, because it is not profitable enough, because the model is obscure, because the window is short, a wrong result finalizes exactly as if it were correct. This is not a weakness unique to AI oracles; it is the same liveness assumption every optimistic system carries, including the rollups securing tens of billions of dollars today, and including the optimistic bridges HOGE Wire has tracked through 2026’s exploit wave, where attackers have repeatedly found the gap between someone could challenge this and someone actually will.

The second is latency. A challenge window has to be long enough to give a verifier a realistic chance to notice and respond, typically minutes at the very least and often longer. That is a fine trade for an insurance payout or an oracle update, and a bad one for anything needing sub-second finality, which rules opML out for real-time interactive use cases almost by definition.

The third is determinism, more of a hidden landmine than the other two. Fraud proofs only work if two independent parties, possibly running different hardware, can agree on exactly what the correct output should have been down to the byte. Ordinary GPU inference does not guarantee that; floating-point rounding and parallelization strategies can differ across hardware in ways that would look like a legitimate dispute even when both parties ran the model faithfully. opML’s answer, its own constrained execution library, solves this by giving something up: raw performance, relative to letting a model run on whatever hardware is fastest.

And the fourth is scale. Multi-phase opML narrows the gap considerably, but a live dispute still ultimately bottoms out in a slow, constrained virtual machine for at least one micro-step. That is fine when disputes are rare, which they should be if the economic bonding is sized correctly, and considerably less fine if an attacker finds a way to make disputes cheap to trigger and expensive to resolve.

Where opML Is Actually Being Used

The clearest current use case for opML is not a flashy consumer application; it is plumbing. OAO’s design, publishing a request, running it off-chain, and calling back into a requesting contract once a result finalizes, maps directly onto the kind of infrastructure autonomous AI agents need if they are going to take on-chain actions based on a model’s output rather than a human’s click. An agent that wants to justify a trade, a claims payout, or a governance vote by pointing to a specific, checkable AI inference has a genuine reason to route that inference through something like OAO rather than simply trusting whatever a centralized API returned.

Prediction markets and parametric products are a similarly good fit: resolving a market or triggering a payout based on a model’s read of a real-world event is exactly the kind of workload that can tolerate a several-minute challenge window without breaking the user experience, since resolution was never going to be instant anyway.

What is harder to find, at least so far, is independently disclosed usage data: transaction counts, unique requesting contracts, total value secured. Ora’s documentation is detailed about architecture and deployment footprint across nine chains, but neither the project nor third-party trackers appear to publish the kind of usage dashboard that has become standard for large oracle networks. That is not unusual for infrastructure this early; it is simply a reminder that deployed on nine chains and meaningfully used on nine chains are different claims, and only one of them is currently easy to verify from the outside.

Does the Token Economics Work?

If opML’s technology is a reasonably mature, multi-year-old idea by crypto standards, its token economics tell a rougher story. ORA, the fee token that pays for OAO inference calls, traded around $0.008 on August 1, 2026, giving it a market capitalization near $2.7 million, according to CoinGecko. That is down roughly 99.8 percent from an all-time high of $5.37 set in November 2024, and CoinGecko’s own volume figure at the time of writing, just over ten dollars in 24-hour trading, is a striking illustration of how thin the secondary market for the token has become (coingecko.com).

ORA is not an outlier here, which is arguably the more interesting story. Every token attached to the four verifiable-compute approaches in the table above is deeply underwater from its own all-time high. PHA, Phala’s token, has fallen to roughly two cents after peaking far higher in 2024 (coingecko.com); EIGEN and Succinct’s PROVE are each down more than 85 percent from their own respective peaks. None of that necessarily says anything bad about the underlying technology; fee-token economics for infrastructure charging fractions of a cent per call were never going to produce dramatic token velocity on their own, and a genuinely useful oracle can coexist with a genuinely unimpressive token chart.

What it does suggest is a familiar gap across this entire sector by now, between shipping real infrastructure and building a token that captures real economic value from it. Ora has real funding, a real multi-chain deployment, and a technically credible fraud-proof design; none of that has yet translated into ORA behaving like a token the market prices as economically important. Whether that changes probably depends less on opML’s engineering, which already works reasonably well for what it claims to do, and more on whether AI agents and oracle consumers end up routing enough real fee volume through OAO to matter.

Regulators Have Not Caught Up

From a U.S. regulatory standpoint, opML and the broader AI-oracle category it belongs to currently sit in a gap rather than under a clear rule. The most relevant recent development is the joint interpretive release the SEC and the CFTC issued in March 2026, filed March 17 and formally published in the Federal Register on March 23, laying out a five-category taxonomy for crypto assets and explicitly classifying sixteen tokens, including bitcoin, ether, and Chainlink’s LINK, as digital commodities rather than securities, based on a functional test asking whether a token’s value depends on the “essential managerial efforts” of an identifiable group (forbes.com).

That release is genuinely significant for oracle infrastructure broadly, since it gave Chainlink, the largest oracle network by far, explicit, formal digital-commodity treatment. It says nothing at all, however, about AI-inference oracles specifically, or about opML, TEEs, zkML, or crypto-economic verification as categories. A token like ORA was not named, and the interpretation includes no discussion of verifiable-compute infrastructure as its own asset class, leaving a project like Ora Protocol to argue its case under the same general managerial-efforts framework as everyone else, on a first-principles basis, rather than pointing to a rule written with its business model in mind. HOGE Wire’s own report card on the SEC’s crypto enforcement record found much the same pattern across the wider industry this year: broad, useful frameworks arriving well after the technology they are meant to cover.

There is a second, quieter regulatory question specific to this category: an AI oracle that feeds a wrong but unchallenged result into a smart contract during a dispute window has, functionally, misinformed a financial system, even without any human intending fraud. Neither the March 2026 interpretation nor any other public SEC or CFTC guidance found for this piece addresses that scenario directly, leaving it, for now, a matter of smart contract design and economic bonding rather than securities law.

What Comes Next: Hybrid Systems and the Verifiability Trilemma

The most interesting recent research in this category does not try to crown a winner between opML, zkML, TEEs, and crypto-economic staking; it tries to combine them. A 2026 paper on what its authors call Optimistic TEE-Rollups proposes exactly that: use a trusted execution environment, specifically Nvidia H100 confidential-computing hardware, to deliver near-instant provisional finality, layer an optimistic fraud-proof mechanism on top for security, and add stochastic zero-knowledge spot checks to catch hardware-level tampering that a compromised chip might otherwise hide (arxiv.org).

The paper frames the underlying problem as a “verifiability trilemma,” the same integrity-latency-cost tension every approach in this piece runs into individually: push hard enough on any one dimension and the others suffer. Its proposed fix, a consensus mechanism the authors call Proof of Efficient Attribution, cryptographically ties execution traces back to hardware attestations, so the system inherits TEE-level speed for the common case while retaining an optimistic dispute path and an occasional ZK check as backstops against exactly the kind of hardware trust failure a pure TEE design cannot rule out on its own. The authors report their design reaching roughly 99 percent of a centralized system’s throughput at a marginal cost near seven cents per query, though those figures come from the paper’s own benchmarks rather than independent replication.

Whether that specific architecture ships in production or gets superseded by something else, the direction is telling. opML’s pure fraud-proof design and zkML’s pure cryptographic design both made a single, clean trust assumption and optimized hard around it. The systems now being proposed increasingly refuse to pick just one, borrowing opML’s cheap common case, zkML’s occasional hard cryptographic guarantee, and TEE’s low latency all at once, on the theory that no single approach available today is good enough on its own to be the last word on verifying AI onchain. opML, years after Truebit-style verification games first showed up in blockchain research and more than two years after its own paper made the idea concrete for machine learning specifically, looks less like a finished answer and more like one durable building block in whatever comes next.

Frequently Asked Questions

What does opML stand for?

opML stands for optimistic machine learning. It refers to a way of verifying AI computations on a blockchain by publishing a result first and only proving it correct if someone actually challenges it within a fixed window, the same optimistic approach used by rollups like Arbitrum and the OP Stack, applied to AI inference and training instead of general contract execution.

How is opML different from zkML?

zkML generates a cryptographic zero-knowledge proof alongside the computation, so correctness can be verified instantly by anyone without re-running anything, at the cost of heavy computational overhead for large models. opML skips that upfront proof entirely, running the computation at normal speed and only paying for verification, through an interactive fraud proof, when a challenger actually disputes the result during a set challenge window.

Who created opML?

opML was formalized in a January 2024 research paper by KD Conway and collaborators at Hyper Oracle, the team that now operates as Ora Protocol under co-founder Kartin Wong. Ora built the Onchain AI Oracle, the main live implementation of opML, and raised $20 million in June 2024 from investors including Polychain Capital, HF0, and HashKey Capital.

Is opML secure enough to trust with real money?

opML’s security depends on economic bonding and on at least one honest, competent verifier actually checking each result during the challenge window; if both conditions hold, a dishonest result should be unprofitable to submit. That makes it well suited to workloads that can tolerate a delay of minutes to hours, like insurance payouts or prediction market resolution, and less suited to anything needing instant, real-time finality, where a wrong result could go unchallenged simply because nobody was watching in time.

What is the ORA token used for?

ORA functions as a fee token for Ora Protocol’s Onchain AI Oracle, with each model inference request costing roughly 0.01 to 1.00 ORA depending on the model called, rather than serving primarily as a governance or staking asset. As of August 1, 2026, ORA traded around $0.008 with a market capitalization near $2.7 million, down about 99.8 percent from its November 2024 all-time high.

Aidan Voss, HOGE Wire