opML in 2026: When Proving AI Becomes a Plug-In

For most of 2026, the argument around verifiable AI sounded like a cage match. Would zero-knowledge proofs win, or optimistic fraud proofs, or trusted hardware? opML, the optimistic approach pioneered by Ora Protocol, was usually cast as the pragmatic middle option: cheaper than zkML, less trusting than a chip vendor. A draft Ethereum standard filed this year quietly answers the question in a way nobody was betting on. None of them wins. They all get wired behind the same function call.

That standard is ERC-8274, a proposal for AI inference proof verification that has been sitting in the Fellowship of Ethereum Magicians forum since March. It treats zkML, opML, trusted execution environments, oracles, and staking networks as interchangeable backends behind a single method called verify(). A contract that wants proof an AI model actually ran no longer integrates opML, or zkML, or a TEE. It calls verify(), and whatever sits behind the interface returns true or false.

The timing is the story. opML is being standardized into a plug-in at the exact moment its inventor is going dark. Ora’s on-chain oracle has answered no new requests since early 2025, its documentation site has dropped out of DNS, and its token trades near $467,000 of market value on a few dollars of daily volume. A companion piece last week argued that opML had been absorbed as a mode inside bigger platforms rather than bought as a product; read it alongside this one as the account of how the idea spread while the token collapsed. The standards layer is where that absorption becomes official. What follows walks through the proposed standard, the five backends it unifies, the trust assumptions a uniform interface cannot paper over, and why the idea is outliving the company that named it.

What a draft standard just did to opML

ERC-8274 begins from a complaint that anyone who has tried to ship on-chain AI will recognize. There are now at least five credible ways to prove a model ran honestly, and a growing list of applications that need such a proof. Wiring each method into each application by hand produces what the proposal’s author, posting under the handle JimmyShi22, calls an N by M integration nightmare: every verification project writes a custom adapter for every consumer, every consumer re-learns a new integration, and the result is vendor lock-in dressed up as choice. The standard, filed on 26 March 2026 with a reference pull request against the EIPs repository, tries to sit exactly in the middle so that verification projects plug in once and consuming contracts query a single interface.

The mechanism is deliberately plain. ERC-8274 defines two small interfaces. IProofVerifier wraps whatever a backend already does behind one verify() method that takes an input hash, an output hash, some metadata, and a blob of proof bytes, and returns a boolean. It does not care whether those proof bytes are a zero-knowledge proof, an opML fraud-proof reference, a TEE attestation, or an oracle signature. IVerificationMethod lets a consuming contract declare which verifier it trusts through a getVerifier() call, with an event that fires whenever that choice changes. The author compares the shape to ERC-20’s transfer(): flat, registry-free, and boring on purpose. Boring is the point. A standard succeeds when it disappears into the plumbing.

For opML specifically, this is a demotion dressed as an honor. When Ora raised $20 million in 2024, founder Kartin Wong told CoinDesk the goal was to unlock the design space for AI dapps. Two years later a draft standard reframes opML not as a design space but as a slot: one string, one verify() implementation, one entry in a dropdown of equivalent options. The method is being honored by inclusion and diminished by it at the same time.

opML in one minute

Optimistic machine learning borrows its trick from optimistic rollups. A node runs an AI model off-chain, posts the result and a cryptographic commitment on-chain, and the network treats that result as correct after a challenge window passes without objection. If someone disputes it, the two parties enter an interactive fraud proof: they bisect the computation again and again until they isolate the one tiny step where they disagree, and the blockchain adjudicates only that single step rather than re-running the entire model. The original opML paper, published by KD Conway and the Hyper Oracle team in January 2024, describes exactly this as an interactive fraud proof protocol reminiscent of the optimistic rollup systems, and the lineage runs back further to Truebit’s verification game from the previous decade.

The payoff is scale. Because the heavy computation only gets re-executed when someone challenges, opML can in principle verify a model with billions of parameters on ordinary hardware, where generating a zero-knowledge proof of the same inference would be far too expensive. That is the entire reason opML exists as a category distinct from zkML, which proves every operation cryptographically up front. The cost of that scale is patience and an assumption: you must wait out the challenge window, and you must assume at least one honest party is watching and willing to dispute a lie. Hold onto those two costs, because the rest of this piece is about what happens to them when opML is hidden behind a standard interface. They do not disappear. They just stop being visible.

The five backends behind one verify()

The proposal names its targets explicitly, and the list is a decent map of the whole verifiable-AI field in late 2026. There are five families, each with real projects behind it, and ERC-8274 wants every one of them to expose the same verify() signature so a consuming contract never has to know which it is talking to.

Read that table across the rows and the elegance of the standard is obvious: five profoundly different machines, one socket. Read it down the third column and the problem becomes just as obvious. The trust assumptions do not rhyme. That tension is the whole subject of the next section.

The interface is uniform; the guarantees are not

Here is the uncomfortable thing a standard interface does. verify() returns a boolean, and a boolean looks the same no matter where it came from. But the trues are not equal. A true from a zkML backend means a cryptographic proof checked out: no human was trusted, and it was final the instant it landed. A true from an opML backend means something much softer, especially before the challenge window has closed: it means nobody has objected yet. A true from a TEE means a chip vendor’s enclave vouched for the result, so you are trusting Intel or NVIDIA and the absence of a side-channel break. A true from an oracle means a committee voted. A true from a staking network means no operator has been slashed, which is only as reassuring as the math on how much it would cost to cheat.

Those are five different security models wearing one type signature. A contract that queries verify() and acts on the boolean has, in effect, outsourced its threat model to whoever picked the backend. Swap the verifier through getVerifier() and the calling code does not change by a single character, yet the guarantee underneath it can move from cryptographic certainty to a time-delayed assumption about anonymous watchers. The standard makes it trivial to change your security model without noticing you did.

This is not a hypothetical objection; it surfaced inside the proposal’s own discussion. A commenter in the thread, posting as Damonzwicker, pushed back that the design standardizes access to system-specific verification rather than making verification genuinely independent of the system that produced it. That is exactly right, and it is the sharpest thing anyone has said about opML’s new position. The interface abstracts the call. It cannot abstract the trust. opML behind verify() is still opML: it still needs a watcher, it still needs the window to pass, and it still returns a provisional answer dressed up to look identical to a proof. The one honest touch in the standard is the VerifierUpdated event, which concedes, quietly, that changing the backend is a security event worth logging rather than a configuration detail.

From a checkbox to a backend

ERC-8274 is not the first standard to fold opML into a menu. It is the second, and the gap between the two tells you who controls the method now. The first was ERC-7007, a finalized standard for verifiable AI-generated content tokens whose text already treats the choice of proof as a plug: it says the standard supports validity proofs and fraud proofs, and that in practice zkML and opML are the common instances of each. In other words, opML was first standardized into a checkbox inside a token standard. The notable part is the author list. ERC-7007 was written by the Ora and Hyper Oracle founders themselves, Cathie So, Xiaohang Yu, KD Conway, Lee Ting Ting, and Kartin Wong.

So trace the arc. opML started as an approach, a paper, a company with a token. Its own creators then wrote it into an ERC as one of two interchangeable proof types. Now a separate, more general standard, authored by someone with no apparent connection to Ora, demotes it one rung further into a backend string behind a universal interface. The direction of travel is unambiguous. The standard-setting around opML has left the building that invented it. There is no clearer signal that an idea has outgrown its company than the moment the people formalizing it are no longer the people who created it.

The platforms already chose their defaults

A standard interface is only interesting if real systems implement it, and the systems building production verifiable AI in 2026 have mostly chosen backends other than opML. Take 0G, one of the more aggressive decentralized-AI networks. Its Sealed Inference product runs every inference inside a confidential virtual machine on Intel TDX processors and NVIDIA H100 or H200 GPUs, and each response is signed by an enclave-born key before it reaches the user. That is a TEE-first design, shipping today on a mainnet that has been live since September 2025 and serving open models like GLM-5. opML and zkML appear in 0G’s own materials only as additional verification methods in active development. They are on the roadmap. Trusted hardware is in production.

Chainlink, the largest oracle network and one of the few crypto-AI infrastructures with real enterprise traction, made a different choice again. Its verifiable AI stack leans on the Chainlink Runtime Environment, which coordinates off-chain AI computation and then verifies results through decentralized oracle consensus before delivering them on-chain. The company has run the pattern with two dozen major financial institutions on corporate-actions processing, reporting near-total agreement among the AI models in the consensus. Nowhere in that stack does opML appear. The biggest name in on-chain data answered the verifiable-AI question with committees and consensus, not fraud proofs.

Put those together and opML’s position in the standard looks less like a seat at the table and more like a place setting nobody has sat down at. It is the canonical reference implementation of the optimistic category, which is why it keeps getting named. But being named in a standard is not the same as being run in production, and the platforms with users are reaching for enclaves and oracles first.

The one thing a wrapper cannot hide: the clock

A standard can abstract the shape of a call. It cannot abstract time. Every backend in the table except opML can return a final answer quickly: a zkML proof verifies in milliseconds, a TEE signs instantly, an oracle committee reports on its own cadence. opML’s honest answer, by contrast, is wait. Until the challenge window closes, a result is provisional, and acting on it means betting that nobody will overturn it. verify() can return true the moment the result is posted, but that true is a promise, not a fact, and the interface gives a consuming contract no way to feel the difference.

This is not a detail that engineering will quietly fix. A recent academic critique, the Optimistic TEE-Rollups paper (arXiv 2512.20176), states the problem bluntly: optimistic approaches impose prohibitive dispute windows, preventing real-time interactivity. The authors frame a verifiability trilemma in which a system cannot simultaneously maximize computational integrity, minimize latency, and minimize cost; opML spends its budget on integrity and cost, and pays in latency. The whole point of their hybrid design is to shrink that window with trusted hardware and occasional zero-knowledge spot-checks, which is to say the state of the art is actively trying to engineer opML’s defining property out of existence.

That matters most in the one market Ora bet its flagship on: autonomous agents. An agent loop that has to pause for a multi-hour dispute window before it can trust a model’s output is not an agent loop; it is a batch job. Composability makes it worse, because a second contract cannot safely build on a result that might still be reverted. So even a perfectly standardized opML carries a property no interface can wrap away. It is excellent for a slow, high-value check where re-execution is cheap and nobody is in a hurry, and it is unusable for the real-time, stack-them-up interactions that most on-chain AI actually wants.

Who runs the watchers

Strip opML down and its security rests on one sentence: at least one honest watcher will challenge a wrong result before the window closes. Behind verify() that sentence is invisible, but it is no less load-bearing. And it points at the assumption a standard interface is least able to help with, because the assumption is economic, not technical.

Watching is expensive. To catch a lie, a watcher has to re-run inferences and compare, burning compute to produce nothing most of the time. If the system is honest, the diligent watcher earns no reward for its vigilance, so the rational watcher stops watching. This is the verifier’s dilemma, and it has haunted optimistic systems since Truebit, which tried to patch it with deliberately injected errors and jackpot bounties to keep verifiers honest and awake. opML never shipped a deployed answer to it. A healthy token with a reward budget could in theory pay watchers to stay alert; a token trading on a few dollars a day cannot. The same economics that govern who bothers to run honest infrastructure in restaking decide who bothers to watch an optimistic oracle, and the answer scales with the reward on offer.

The tell is empirical. On Ora’s live on-chain oracle, no fraud-proof challenge is on public record as having ever fired, according to an independent on-chain review. Read that charitably and it means the operator never lied. Read it skeptically and it means nobody was ever watching closely enough to catch one. From outside the contract you cannot tell the two apart, and that ambiguity is precisely what ERC-8274 cannot standardize away. A verify() backed by opML is only ever as strong as the watchers nobody is currently being paid to be.

The inventor went quiet

While the idea gets formalized, the company that coined it has grown very quiet. The same on-chain review that found no fraud proof ever fired also counted the traffic, and the numbers are stark. Ora’s Onchain AI Oracle shows 4,615 lifetime requests on Ethereum, and the counter stopped advancing on 26 September 2025. The last request that got an answer was number 4,610, on 29 April 2025; the five requests after it went unanswered, and a lone result posted in May 2026 turned out to be a backfill of an older request rather than a return to service. The oracle, in other words, has not meaningfully served new traffic in over a year.

The surrounding infrastructure has eroded to match. The review notes that the documentation site at docs.ora.io served content as recently as April 2026 and now returns no DNS record at all, taking the tokenomics pages, node operator guides, and whitepapers down with it. The governance that the token’s own materials listed as a core utility never got a venue: no on-chain governance contract, no voting space, nothing to govern with. And the figures that circulate in investor summaries, 180,000 inference calls and more than 500 nodes, cannot be reconciled with a contract that logged 4,615 lifetime requests, with the final traffic coming from Ora’s own demonstration contract rather than outside users. Against the roughly $23 million the team raised across a 2023 pre-seed and a 2024 strategic round led by Polychain and HashKey, that is a thin on-chain footprint.

None of this means opML the method failed. It means the opposite, in a way that is almost cruel: the technique is durable enough to be written into Ethereum standards and name-checked by newer platforms, while the company that authored it has stopped maintaining the oracle, the docs, and the governance. The idea is being kept alive by the ecosystem. The business is not keeping much alive at all.

The market’s verdict on each backend

Tokens are a noisy way to score technology, but when the spread is this wide it says something. Map each of ERC-8274’s five backend families onto a representative token and look at what the market pays for each. These are not pure plays, LINK is far more than verifiable AI, EIGEN is primarily a restaking network, and a token price reflects a dozen things besides a verification method, so treat this as a rough gauge of commercial standing rather than a technical ranking. The order of magnitude is the message.

The oracle backend is a top-twenty crypto asset worth around $9 billion. The staking backend is a nine-figure network. The zkML and TEE backends sit in the tens of millions. opML’s originator trades at a market value of roughly $467,000 on volume that some days does not clear the price of lunch, down 99.9% from its 2024 peak. The headline percentage swings on ORA are large and meaningless; on volume that thin, a single small trade moves the quote, so do not read a recovery into a green number. The flatline is the signal.

There is a logic to the spread that goes beyond Ora’s specific troubles. Standardization is exactly the thing that strips a protocol of pricing power. When your method becomes a swappable backend behind a shared interface, the value accrues to whoever runs the socket and owns the demand, not to whoever invented the plug. The oracle and staking networks are worth something because applications pay them for a service. opML, reduced to a verify() implementation anyone can re-run, has nothing left to charge rent on. The clearer the standard, the cheaper the plug.

The case that standardization helps opML

It is worth steelmanning the optimistic read, because there is a real one. A shared interface is a distribution channel. If opML exposes a compliant verify() once, then every application that adopts ERC-8274 can reach for it without a bespoke integration, and the integration cost that kept opML a niche choice falls toward zero. On this view the method does not need Ora to thrive; it needs to be trivial to call, and a standard delivers exactly that. The underlying economics still favor opML for a specific shape of job. As Vitalik Buterin laid out in his essay on crypto and AI, cryptographic verification of large models is brutally expensive, with zero-knowledge proving that can take hours and overheads that run into the hundreds for the non-linear parts of a network. opML exists precisely to dodge that bill, and a standard that makes the cheap option easy to select is, on paper, a gift to it.

The rebuttal is that distribution without demand is nothing, and a standard supplies neither the supply side nor the demand side that opML actually lacks. Somebody still has to run the verifier, operate the nodes, and fund the watchers; ERC-8274 makes the socket uniform but does not plug anything into it. And the jobs that have genuine demand, the agent loops and composable DeFi actions, are the ones opML’s challenge window disqualifies no matter how clean the interface. Standardization helps opML the verb, the act of optimistically checking a computation. It does almost nothing for opML the business, because the two things that starved Ora of traction, who pays to run the watchers and whether the latency fits the use case, live entirely outside the interface. A better plug does not help if nobody is buying what it carries.

What builders should actually do with this

The practical hazard of a uniform interface is complacency. If verify() always returns a boolean, it is tempting to treat every boolean the same, and that is the one mistake this standard makes easy. For anyone building on top of ERC-8274 or a design like it, a few habits keep the abstraction from hiding things that matter.

• Read getVerifier() before you trust a verify() result. The backend is a security parameter, not a configuration detail, and two contracts with identical calling code can carry opposite threat models.
• Treat an opML true as provisional until its challenge window has closed, and never let a downstream contract act on a result that could still be reverted.
• Ask who is paid to watch. An optimistic backend with no funded challengers is an attestation dressed as a proof, and absence of disputes is not evidence of honesty.
• Match the method to the latency budget: optimistic verification for slow, high-value checks where re-execution is cheap; cryptographic or hardware-attested verification for anything real-time.
• Subscribe to the VerifierUpdated event. A silent backend swap can change your security model without changing a line of your code.

None of that is exotic. It is the same discipline that competent engineers already apply to oracles and bridges, extended to the newer question of how a result was proved rather than just where it came from.

The regulatory seam

For readers in the United States, the verification-infrastructure tokens sit in an awkward regulatory gap, and the standard throws it into relief. In March 2026 the SEC and the CFTC issued a joint interpretation naming sixteen crypto assets as digital commodities, Chainlink’s LINK among them. The interpretation said nothing about AI-verification infrastructure tokens like ORA, leaving them in the usual case-by-case analysis under the Howey test rather than inside the safe harbor. The result is a small irony that mirrors the token table above: the oracle backend got regulatory clarity, while the opML backend got silence. With ORA near $467,000 the practical stakes are low, but the asymmetry is real, and it is the kind of thing covered in detail in HOGE Wire’s running account of SEC crypto enforcement after the comment window.

The sharper exposure was never the utility token anyway; it was Ora’s other idea. The company’s model-tokenization scheme leaned on a revenue-share token standard, ERC-7641, whose own text says the token embodies shares and lets holders redeem a proportionate cut of a revenue pool. That maps onto the Howey test far more directly than a gas-like utility token does, and if model-tokenization ever revives, that is where a regulator looks first. The broader question of who is liable when autonomous, on-chain code handles other people’s value is the same one running through the fight over DeFi compliance, and verifiable-AI infrastructure will not stay outside it forever.

Bottom line: a verb, not a company

opML’s 2026 is a win for the idea and a loss for the company that had it. The method is durable enough to be written into a finalized token standard, name-checked by a draft verification standard, and listed as a backend alongside zkML, TEEs, oracles, and staking networks. The company that coined it has let its oracle go idle, its documentation lapse, and its token sink to a market value you could cover with a used car. Both things are true at once, and the verify() interface captures the paradox perfectly: it makes opML permanent and interchangeable in the same stroke.

Where opML still belongs is narrower than the original pitch but genuine: slow, high-value checks where re-execution is cheap and at least one well-funded party has a reason to watch. That is a real niche, not the whole of on-chain AI, and the standardization wave is quietly sorting opML into it. The optimistic bet was that one honest watcher is enough to keep a system honest. The standard’s bet is that the method matters less than the socket it plugs into. The uncomfortable lesson of this year is that both bets can pay off while the people who placed the first one walk away with nothing.

Frequently Asked Questions

What is opML (optimistic machine learning)?

opML is a way to verify AI computation on a blockchain by assuming results are correct and checking them only when challenged. A node runs the model off-chain, posts the result with a cryptographic commitment, and the network accepts it after a challenge window unless someone disputes it, at which point an interactive fraud proof pinpoints the single step in dispute. It is modeled on optimistic rollups and was pioneered by Ora Protocol.

What is the difference between opML and zkML?

zkML proves an AI computation was correct up front with a zero-knowledge proof that verifies in milliseconds and trusts no one, but generating that proof is expensive and hard for large models. opML skips the up-front proof and instead relies on a challenge window plus fraud proofs, which is far cheaper and scales to big models but adds latency and assumes at least one honest party is watching. zkML buys finality with cost; opML buys cheapness with time.

What is ERC-8274?

ERC-8274 is a draft Ethereum standard, filed in March 2026, that defines a single verify() interface for AI inference proofs so that zkML, opML, trusted execution environments, oracles, and staking networks can all be queried the same way. It aims to end the burden of wiring every verification method into every application by hand. It remains a proposal under discussion, not a finalized standard.

Is the ORA (Ora Protocol) token dead?

ORA trades near $467,000 of market value on only a few dollars of daily volume as of November 2026, roughly 99.9% below its 2024 high. An independent on-chain review found Ora’s oracle has served little new traffic since 2025, its documentation site has dropped out of DNS, and no governance venue was ever built. The token is not formally wound down, but by any measure of activity the project is effectively dormant.

Can you trust an opML verification result?

An opML result is only as trustworthy as the challenge window and the watchers behind it. Before the window closes the result is provisional, meaning nobody has objected yet rather than that it has been proven, and its security depends on at least one honest party being motivated to dispute a wrong answer. An optimistic system with no funded challengers provides an attestation, not a cryptographic guarantee.

Marcus Okafor covers verifiable AI and crypto infrastructure for HOGE Wire.