OpenGradient (OPG)

OpenGradient: A Verification Network for AI Inference

OpenGradient combines specialized inference nodes, hardware attestation, zero-knowledge proofs and blockchain settlement. OPG is used for payments and is described by the project as a utility token for network participation, but several core capabilities remain dependent on testnet infrastructure, external AI providers and evolving governance controls.

What OpenGradient is building

OpenGradient is designed as infrastructure for AI applications that need more evidence than a conventional API can provide. Its stated purpose is to let developers run model inference, agents and related workflows through a network where execution results can be attested, verified and recorded. The project’s architecture separates model execution from blockchain verification rather than asking every validator to rerun an expensive AI workload.

The project describes its blockchain as a verification and settlement layer rather than a general-purpose smart-contract chain. Public documentation says the network uses Cosmos SDK components, CometBFT consensus and EVM compatibility, while the underlying network is currently in testnet. The stated design is specialized: full nodes maintain consensus and verify evidence, inference nodes run models, data nodes retrieve external information, and Walrus is used for off-chain storage of large model or proof data.

How inference and verification are separated

OpenGradient’s Hybrid AI Compute Architecture, or HACA, divides the user experience into a fast path and a verification path. An inference request is sent directly to an appropriate inference node, which returns a result without waiting for block confirmation. The node then submits a signed result, TEE attestation or ZKML proof for asynchronous settlement. Full nodes verify the evidence during consensus, and the result is recorded after the required validator agreement.

The project presents three verification levels. Trusted Execution Environments provide hardware-backed evidence that approved code ran inside an enclave. ZKML aims to prove mathematically that a particular model produced a particular output, but the documentation describes substantially higher computational overhead. Vanilla verification uses signatures without proving correct model execution. This gives developers a way to match verification expense to the importance of a workload, but it also means that not every result carries the strongest available guarantee.

TEE infrastructure and external dependencies

For large-language-model inference, OpenGradient documents TEE-based execution as the standard path. TEE nodes must register with the network and provide hardware attestations, public keys and related enclave information before serving requests. The registry is intended to let validators check approved enclave identities and let clients establish encrypted connections to registered nodes.

This model does not remove all trust assumptions. TEE security depends on the underlying hardware, enclave implementation and approved software measurements. OpenGradient’s own design documentation acknowledges that a TEE vulnerability could weaken the security model and presents ZKML as the alternative for applications that require mathematical rather than hardware-based assurances. LLM proxy nodes can also route requests to third-party providers, so model availability, provider policies and off-network infrastructure remain practical dependencies.

What OPG does

OPG is an ERC-20 token on Base with a stated total supply of 1 billion. OpenGradient documentation says LLM inference payments use OPG on Base through the x402 payment flow and Permit2 approvals. Other forms of model execution can use the OpenGradient network itself for transaction and settlement activity. This creates a two-network workflow: Base handles the documented OPG payment leg for LLM requests, while the OpenGradient network handles registration, execution coordination, proof settlement and verification.

The project’s tokenomics page allocates OPG among ecosystem development, the foundation, contributors, investors and advisers, staking rewards, liquidity and launch, and an airdrop. Several categories have vesting or linear-release schedules extending over multiple years. The MiCA white paper describes OPG as a utility token and says holders do not receive equity, dividends or profit-sharing rights. It also describes protocol-level uses that include service payments, staking and governance participation.

Governance and project control

OpenGradient’s regulatory disclosure describes governance rights at the protocol level, including voting on network upgrades, protocol parameters and the registry of approved TEE enclave measurements. The same disclosure says staking is tied to validator participation through CometBFT. These statements establish the intended governance model, but the reviewed public material does not by itself establish a mature, active proposal system, voter participation level or the exact distribution of upgrade authority today.

The public code footprint shows a project with separate repositories for the network node, Python SDK, TEE gateway, inference facilitator and explorer components. That separation helps developers inspect individual pieces, but it also means the operating system depends on several coordinated software and service layers. The SDK documentation further warns that some client-side signature checks occur at the settlement layer and that development modes can bypass registry and TLS-pinning protections; production users therefore need to distinguish documented deployment paths from local testing shortcuts.

Practical limits for users and developers

OpenGradient is most relevant to developers building agents, model services or applications where execution evidence matters. Its design may be useful for privacy-sensitive LLM calls, auditable model execution and workflows that need a verifiable connection between inputs, software measurements and outputs. However, the network is still documented as testnet, and the project’s future plans include capabilities such as native smart-contract calls to AI inference that are not yet rolled out.

The central question is not only whether OpenGradient can verify an inference, but whether enough independent operators, developers and paying applications use the system over time. Users must also account for Base payment requirements, wallet approvals, model and storage dependencies, TEE hardware assumptions, asynchronous proof settlement and future token releases. The project provides an explorer and open repositories for inspection, but those resources should not be treated as proof of broad adoption or production reliability on their own.

Key takeaways

• OpenGradient separates AI execution from blockchain verification through its HACA architecture.
• TEE, ZKML and signature-only verification provide different security and cost trade-offs.
• OPG is documented as a Base ERC-20 utility token used for certain inference payments and intended network functions.
• LLM payments use OPG on Base, while registration and proof settlement involve the OpenGradient network.
• The network is currently documented as being in testnet, and planned native AI calls from smart contracts are not yet rolled out.
• The system remains dependent on TEE hardware, external model providers, specialized operators and coordinated software services.

Risks and open questions

• The documented OpenGradient network is still in testnet, so production performance, decentralization and long-term reliability remain unresolved.
• TEE verification depends on hardware manufacturers, enclave implementations and approved software measurements; a serious TEE vulnerability could weaken the trust model.
• LLM proxy infrastructure may depend on third-party AI providers whose availability, pricing and policies are outside OpenGradient’s control.
• The two-network payment and settlement design adds operational complexity involving Base, wallet approvals, Permit2 and OpenGradient infrastructure.
• Token allocations include multi-year vesting and release schedules that may affect future supply and participant incentives.
• The project describes governance rights, but the reviewed sources do not establish the current activity level, voter distribution or precise upgrade-control process.