OpenGradient: Inference as the foundational layer of trust

Key Takeaways

• The five gaps a16z crypto laid out, identity, governance, payment, trust, and user control, ultimately converge on a single question: was this agent's judgment and execution produced in the agreed environment, without tampering? When intelligence becomes cheap, what turns expensive is verification, and verifiable inference is the precondition for the other four gaps to function on top of trust.
• An inference infrastructure that becomes a trust layer sells not the answer but the execution record. Models keep changing, but the ledger of who made which judgment, when, and from which verified call remains. The moment payment records, call histories, and verification proofs accumulate in one infrastructure, users are bound not to the model but to the record layer. This is the position OpenGradient is after.
• OpenGradient pulls verification down from a concept into a product. The explorer turns the trust chain into a record anyone can query in a browser; the Sybil detection built with Pond puts verified inference into a workflow; x402 binds payment and inference into a single call; and private inference keeps even the model provider from knowing who is asking. All four point in one direction: making verification the default of the call.
• As cheaper, faster, and smarter models keep arriving, a moat built on the model alone weakens. The durable moat lies in how models are called, verified, and recorded. Now that hundreds of billions of dollars are pouring into compute and models, what is actually missing is the layer that verifies who ran what. The moment the call, not the model, becomes the moat, verifiable inference moves past being an add-on to AI infrastructure and becomes its foundation.

1. Redefining inference: From model responses to a trust layer for verifiable calls

1.1 The importance of verifiable inference

Source : X(@a16zcrypto)

a16z crypto recently presented five gaps that blockchains can fill in “The missing infrastructure for AI agents: 5 ways blockchains can help”. These include identity for non-human actors, governance for AI-operated systems, payment infrastructure for AI-native businesses, repricing trust in the agent economy, and user control.

At first glance, these five gaps may look like problems at different levels. Identity is about who acted. Governance is about who has authority. Payment is about how money moves. User control is about how far delegation should go. However, once an agent becomes an autonomous actor in a given context, such as agentic commerce, these problems converge on one question.

Was this agent’s judgment and execution produced in the agreed environment, in the agreed manner, without tampering?

Here, “verifiable inference” is closer to a precondition for making these problems work in a trusted way than a complete answer to all of them. For example, if the judgment, or inference, executed by a specific identity cannot be verified, it becomes difficult to assign responsibility. In payments, if it is impossible to confirm which inference call a payment corresponds to, the settlement record loses meaning. The same applies to governance. If we cannot know which model output an agent actually acted on, delegated authority is effectively built on a black box.

a16z states this point clearly: “When intelligence is cheap, what becomes expensive? Verification.” AI is lowering the cost of cognitive labor that humans used to perform directly, and the throughput of agents is quickly moving beyond what people can supervise one by one. In this shift, agent throughput is overwhelming human supervision capacity, and keeping a person in the loop every time is becoming physically difficult.

In such an environment, trust cannot be maintained through post-hoc inspection alone. A structure in which people review and approve things later can work when throughput is low. But it becomes a bottleneck when many agents call APIs, make payments, and interact with smart contracts at the same time. a16z’s conclusion is clear on this point as well. Trust must be embedded inside the architecture, rather than handled through manual inspection.

This also means that AI can no longer remain an “API that only returns answers.” The answer itself is no longer the only thing that matters. Who made the call, under what authority, in what execution environment, whether the result was tampered with, and what payment was attached to the call all need to be bound together. What we ask of agents is shifting from a simple “response” to a “call that can be verified at any time.”

1.2 OpenGradient’s position: Trust calls rather than model APIs

From this perspective, the nature of the product handled by AI inference infrastructure also changes. Existing AI infrastructure has focused on receiving a user’s question and returning the model’s answer. Inference infrastructure that becomes a trust layer sells execution records in addition to answers. Even with the same model, the same input, and the same output, the product is no longer the same if the caller, authority, execution environment, verification method, and settlement method differ.

This difference may look small, but over time it can create a fairly strong lock-in effect. Models keep changing. Faster models, cheaper models, and better models can appear at any time. However, a form of “ledger” that records which agent made which judgment at which time, and whether that judgment came from a verified call, becomes important data regardless of changes in models. In particular, when payment records, call histories, verification proofs, and application logic begin to accumulate together in one infrastructure layer, users become tied to the “record layer,” rather than simply to the model.

This is the position OpenGradient is aiming for. OpenGradient’s Hybrid AI Compute Architecture (HACA) does not process AI inference by having every validator execute it again. Instead, roles are divided. Inference nodes run the model, full nodes verify proofs and maintain the ledger, and data nodes fetch external data in isolated environments.

For a detailed explanation of OpenGradient’s architecture and verification mechanism, see the previous article, OpenGradient: Toward an Open Inference Layer.

In this structure, the key is less about a specific verification technology stack and more about how smoothly users can consume technologies such as trusted execution environments (TEEs), zero-knowledge machine learning (ZKML), and signature-based verification in a single call. The moat of infrastructure often comes not from the most difficult technology, but from the abstraction that makes the user experience easier.

This is the abstraction OpenGradient is trying to build. Users do not need to understand the details of trusted execution environments every time. They do not need to calculate ZKML proof costs by themselves, or attach payment and verification through separate systems. The key point is a structure in which the question, “Is this call verifiable?” is answered inside the call itself.

2. How OpenGradient turns verification into a product

2.1 Explorer: External visibility for verifiable inference

Source : X(@OpenGradient)

On May 1, 2026, OpenGradient announced that it had enabled large language model (LLM) inference verification in its explorer. OpenGradient had already explained that its inference is verified by the network and protected through TEE attestation. This feature is different because it allows users to check the verification process directly in the explorer.

This structure starts by checking whether the node that processed the inference is a trusted execution environment. First, the chip running the GPU server issues an attestation document proving that it is operating on actual AWS Nitro hardware. Next, the PCR hash, which is the fingerprint of the code running on that hardware, is extracted and compared with the allowlist pre-registered in the on-chain TEE registry. The node registration passes only if the code that is about to run on the hardware matches the pre-approved code. Finally, the TLS public key hash used by the user to communicate with the node is checked against the attestation document. This process verifies that communication with the node also took place inside a verified environment. As a result, users get on-chain verification that can be traced directly from the hardware to the TLS connection, without an intermediary trust authority such as a certificate authority (CA).

Source : OpenGradient Explorer

The next step is post-execution verification of the inference result. When a trusted execution environment node runs inference, the result is signed with the node’s signing key. The attestation proof is then posted to the OpenGradient network and verified. The inference data is recorded at different levels depending on the selected settlement mode. PRIVATE mode does not put input and output data on-chain. BATCH_HASHED mode records hashes by bundling multiple requests together. INDIVIDUAL_FULL mode records all information, including input, output, model information, and metadata, as shown above.

The key point here is not that “everything is always public.” The opposite is closer to the design. OpenGradient places choices among privacy, cost, and auditability inside the product. Some applications need to disclose the full input and output. Some applications only need to leave a hash. Some applications must not leave the data itself on-chain. For verifiable inference to become actual infrastructure, it needs to handle these differences.

This is why the explorer is more than a simple dashboard. It turns the concept of “verifiable inference,” which had been described in developer documents, into records that can be checked in a browser. When trust is no longer a claim and becomes a state that users can query directly, verification takes on meaning beyond a standalone feature.

2.2 Workflows: Building decisions on verified inference

Once verification becomes visible, the next question is where these verified calls are used in practice. For a trust layer to avoid remaining a one-off demo, it needs to be embedded in recurring workflows.

Source : X(@OpenGradient)

The Sybil detection model that OpenGradient released with Pond on May 6, 2026 is one example. A Sybil attack is an act in which one user creates multiple wallets to receive duplicate airdrops or distort governance votes. For projects that operate airdrops, points programs, referral rewards, or governance, this has long been an operational problem.

It has also been a difficult problem for ecosystem contributors. There have been many cases in which users were classified as Sybil addresses and excluded from rewards or lost voting rights despite legitimate activity. These detection processes generally relied on black box models from centralized analytics companies. Users often received only the result that they had been classified as Sybil, with little ability to check why. This created dissatisfaction. From the project’s perspective, disclosing the basis for the decision can help attackers find ways around the system. Refusing to disclose it means accepting backlash from users who were wrongly flagged. In the end, the issue was about trust and procedure as well as performance.

OpenGradient uses Pond’s machine learning model at this point. Pond has developed machine learning models that classify and label Sybil addresses. These models have been used for fair airdrop operations, prevention of referral reward abuse, detection of wash trading groups, and improvement of user metrics.

The scope of what verifiable inference solves here needs to be read precisely. Verification does not fully explain “why this address is Sybil.” Model explainability, the scope of feature disclosure, and appeal procedures need to be designed separately. What OpenGradient provides is not the accuracy of the decision itself, but the ability to trace the origin of the decision. If it becomes possible after the fact to check which model produced which result, based on which input, under which verification mode, then at least one can examine whether the decision was changed arbitrarily, whether the promised model actually ran, and whether the result was tampered with.

This difference becomes more important when combined with smart contracts. If a smart contract uses logic such as “limit rewards when this wallet’s Sybil probability exceeds a certain threshold,” the input value is no longer simple data. It becomes the basis for a decision. What is needed at that point is not a result saying that some company with a black box structure made the judgment. It is closer to a result produced by a verifiable execution record. OpenGradient does not simply lay down verification infrastructure and stop at a demo. By embedding the trust layer directly into Pond’s Sybil detection workflow, it shows how verification moves from infrastructure into product.

2.3 x402: Binding payment and inference into one call

If verification can be checked externally and that verification enters workflows, the remaining question is payment. For agents to become economic actors, they need to call services and pay for those calls. However, if payment and inference are scattered across different systems, the unit of trust breaks apart. Inference may take place in a verified environment while the payment remains in a separate system. Or the payment may be confirmed, but it may be unclear which inference call it corresponds to. In that case, the meaning of “verifiable call” as a product becomes weaker. OpenGradient addresses this by binding x402 and trusted execution environment-based inference into the same call flow.

More specifically, OpenGradient solves this problem through the integration of the x402 payment protocol and TEEs. The key is not simply adopting a payment protocol. It is that x402 is embedded directly inside every TEE instance. The user’s request does not pass through separate payment middleware. It goes directly into the TEE enclave, where payment verification and inference execution are processed in sequence. The x402 payment is verified inside the enclave, and the LLM inference runs immediately after. Since payment processing and inference execution happen within a single trust boundary, the separate payment middleware itself disappears. At the same time, enclave-terminated TLS is guaranteed, so even the host machine cannot see the communication. The TEE stamps the output with its own enclave signing key and records the hash on-chain.

The core point is not that “a payment protocol was attached.” The core point is that developers can consume payment, execution, and verification as one call flow. The user receives a response, checks the payment receipt for that call, and receives proof that the inference took place in a verified environment. Payment and verification are not issued separately. They become part of the same call.

This integration matters because it expands the range of accumulated records. Verification records accumulate, and payment records linked to that verification accumulate with them. The real lock-in effect appears here. Models can change. But records that bind payment, calls, verification, and workflows together are not easy to move.

2.4 Private Inference: Calling Closed Models Without Revealing Who Is Asking

Source : OpenGradient Docs

By this point, OpenGradient's calls are verified, embedded in workflows, and bound together with payment. Yet one thing still stays exposed: who is asking what. A trusted execution environment hides the data from the host, but at the far end of the call sits a closed model provider, and the request still travels there to be processed. Private LLM Inference targets exactly this last exposure. It layers Oblivious HTTP (OHTTP) and HPKE (Hybrid Public Key Encryption, RFC 9180) encryption on top of the trusted execution environment stack, separating a user's identity from the content of their request. The request is end-to-end encrypted all the way to the enclave, and the path it travels is split into two hops with a relay in between. The relay sees only the user's IP, never inside the sealed request. The gateway enclave, where inference actually runs, decrypts and processes the plaintext but does not know which IP the request came from. What reaches the model provider is only a request issued from the enclave's egress.

This separation carries over into payment. In Section 2.3, the user paid the enclave directly. With private inference, a relay sits in between: the relay pays the gateway in x402, and bills its own users separately, in whatever way it chooses. So the gateway receives payment but never learns who paid for it. In short, private inference is less a new product than a layer that adds one more guarantee, privacy, on top of verifiable inference. The same trusted execution environment registry, the same on-chain attestation, and the same payment settlement on Base all stay in place. The verification step runs unchanged as well: each response is signed inside the enclave and checked against the key registered on-chain.

So where does this privacy come from? In the end, it comes from the fact that the relay and the gateway do not collude. As long as the two operators do not share data, no one can link a particular user to a particular prompt. If non-collusion is a promise between the two parties, attestation pins down the gateway side of it at the level of code. The HPKE private key never leaves the enclave's memory, and the server code is open-source, verifiable, and records nothing. That is why even a gateway operator who wanted to could not read the plaintext outside the approved code path. This guarantee, of course, reaches only as far as keeping content and identity unlinked. Traces such as the timing or volume of traffic fall outside it. Private inference, then, is a design that splits trust from the start, so that no single party ever holds both who and what at once.

3. The moat after models: OpenGradient’s vision for verifiable inference

Let us return to the starting point. The five gaps summarized by a16z are problems at different layers. Identity, governance, payment, trust, and user control each require separate design. However, once agents actually act, transact, and receive delegated authority, all of these problems require verifiable execution records. If we cannot know who executed what, and with which authority, then the identity, payment, and governance built on top of that foundation can easily become unstable.

OpenGradient is trying to turn this foundation into a trusted product. It makes verification visible through the explorer, puts verified inference into actual workflows through Sybil detection and AlphaSense, and binds payment and inference into the same call unit through x402 integration. These three directions point to one goal: making verification the default of the call, rather than a separate procedure.

Of course, this picture will not be completed immediately. Trusted execution environments are powerful tools, but they do not fully eliminate trust assumptions about hardware and providers. ZKML must continue to lower cost and latency before it can be applied to a wider range of models. Settlement modes also require choices among privacy, cost, and auditability.

This competition no longer plays out inside crypto alone. In May 2026, SpaceX disclosed in its IPO filing a roughly $45 billion compute supply agreement with Anthropic, and is heading for a Nasdaq debut at a valuation of around $1.8 trillion. The compute that underpins inference is being re-rated as a core business of an aerospace company, and as the largest offering in capital-market history. Yet what this deal proves is the scale of compute, not a basis for trusting the inference that runs on top of it. And the bigger this infrastructure gets, the more clearly it exposes what is missing: a layer that verifies who ran what, and on which model.

Model competition will continue. Cheaper models, faster models, and smarter models will keep appearing. For that reason, a moat built on models alone steadily weakens. By contrast, how models are called, how calls are verified, and how calls and payments are recorded together only carries more weight as time goes on.

The central question of the agent era does not end with "Which model is the smartest?" The more important question is, "Can that model's judgment be preserved in a form that can be trusted?" Now that hundreds of billions of dollars are pouring into compute and models, what is actually missing is the layer that verifies the inference running on top of them. The place where the call, not the model, becomes the moat, that is the foundation of the inference industry OpenGradient is after.