Skip to content

Consensus

OpenGradient's blockchain layer serves as the verification and settlement layer for AI inference and applications - it is not intended as a general-purpose smart contract platform. The network uses CometBFT consensus with Cosmos SDK and EVM compatibility, chosen specifically because they enable the HACA architecture's separation of fast inference execution from asynchronous proof verification.

The blockchain handles amongst other things:

  • Node Registration: Verifying and authorizing inference nodes and data nodes
  • Proof Settlement: Validating TEE attestations and ZKML proofs after inference completes
  • Payment Processing: Settling payments for inference operations
  • Ledger Management: Maintaining an auditable record of all verified AI operations

NOTE

In the future, OpenGradient will support smart contracts that can call AI inference natively via precompiles. This capability is not yet rolled out on the network.

This design keeps AI inference fast (requests go directly to inference nodes, not through the blockchain) while ensuring all results are cryptographically verified and recorded.

Consensus Engine: CometBFT

CometBFT is the consensus engine underlying OpenGradient's verification layer. It provides instant finality and Byzantine fault tolerance - properties that are essential for AI settlement where results need to be definitively recorded and verified.

Key Properties

  • Instant Finality: Blocks are final once committed. Inference results and proofs are immediately available once settled - no confirmation waiting.
  • Byzantine Fault Tolerance: The network remains secure as long as less than 1/3 of validators are malicious or faulty.
  • Deterministic Execution: All validators verify the same proofs in the same order, ensuring consistent verification state.
  • Efficient Verification: Validators verify proofs and attestations without re-executing expensive AI computations.

How Consensus Works

  1. Propose: A validator is selected as the block proposer based on their stake weight
  2. Prevote: Validators broadcast prevotes for the proposed block (including any inference proofs)
  3. Precommit: Once 2/3+ prevotes are received, validators broadcast precommits
  4. Commit: Once 2/3+ precommits are received, the block is finalized and proofs are permanently recorded

Application Layer: Cosmos SDK + EVM

OpenGradient uses Cosmos SDK with EVM compatibility - not to compete with general-purpose blockchains, but to leverage proven infrastructure and developer tooling for AI-specific functionality.

Why Cosmos SDK

  • Modular Architecture: Build AI-native modules (inference verification, node registry, proof settlement) on top of battle-tested infrastructure
  • Flexible State Machine: Custom application logic for AI operations while using proven consensus
  • Interoperability: IBC (Inter-Blockchain Communication) enables cross-chain AI inference in the future

Why EVM Compatibility

EVM compatibility lets developers integrate AI inference into existing workflows:

  • Familiar Tooling: Use Hardhat, Foundry, ethers.js, and MetaMask without learning new tools
  • Smart Contract Integration: Write AI-enabled smart contracts that call inference natively via precompiles (coming soon)
  • Ecosystem Access: Bridge assets and interact with existing DeFi protocols

Consensus and Inference Verification

The HACA architecture separates the fast path (inference execution) from the verification path (settlement). This is fundamental to how OpenGradient achieves web2-like latency while maintaining decentralized verification:

  • Inference requests go directly to inference nodes - not through the blockchain
  • Results are returned immediately to users with minimal latency
  • Proofs and attestations are settled asynchronously on the blockchain after inference completes

The blockchain never bottlenecks AI inference. It serves purely as the verification and settlement layer.

Settlement Flow

After an inference node executes a request and generates a proof:

  1. Inference Completes: Inference node returns results to the user immediately
  2. Proof Submission: The inference proof or TEE attestation is submitted to the network
  3. Payment Settlement: Payment is settled either on the OpenGradient chain or on third-party chains like Base
  4. Block Proposal: A validator includes the proof in a block proposal
  5. Consensus Verification: Validators verify the proof during the consensus round
  6. Finalization: Once 2/3+ validators agree, the proof is permanently recorded

Verification Methods

Full nodes verify proofs from inference nodes using different methods depending on the inference type:

MethodWhat Validators VerifyUse Case
TEEHardware attestations proving secure enclave executionLLM inference via third-party providers
ZKMLZero-knowledge proofs of correct model executionLocal ML model inference
VanillaSignature verification onlyLower-security use cases

Validators verify proofs efficiently without re-executing the actual inference computation. This keeps consensus fast while ensuring all AI operations are cryptographically verified.

Inference Node Registry

Full nodes maintain an on-chain registry of authorized inference nodes. Before an inference node can serve requests, it must register with the network—and for TEE nodes, this registration includes verifying their hardware attestation.

Registration and attestation verification are handled through smart contracts, making the entire process auditable and interoperable. This modular design allows developers to build more complex verification and orchestration logic on top of the base registry.

TEE Node Registration

TEE-enabled inference nodes must prove they're running in a secure enclave before they can serve requests:

  1. Attestation Generation: The TEE node generates a hardware attestation proving it's running correct, untampered software inside a secure enclave
  2. Public Key Publication: The node publishes its public key along with the attestation
  3. Registry Update: Full nodes verify the attestation and add the node to the registry
  4. Inference Authorization: The node can now sign inference results that full nodes will accept

TIP

For a detailed breakdown of the TEE Registry smart contract, verification checks, and secure connection establishment, see TEE Verification & Trust Model.

Why Registration Matters

Registration provides the foundation for trust in OpenGradient's inference network:

  • Privacy Guarantee: TEE attestation proves the node operator cannot log or manipulate user requests
  • Result Authenticity: Full nodes only accept results signed by registered nodes
  • Horizontal Scaling: New inference nodes can join the network by completing registration
  • Revocation: Compromised nodes can be removed from the registry

Security Model

OpenGradient's security model is designed around verifiable AI—ensuring that inference results can be trusted without trusting individual node operators.

Inference Verification Security

The primary security guarantee is that AI inference results are authentic and untampered:

  • TEE Attestations: Hardware-backed proof that inference ran in a secure enclave where operators cannot see or modify requests
  • ZKML Proofs: Mathematical proof that a specific model produced a specific output for a given input
  • Signature Verification: All inference results are signed by registered nodes and verified by full nodes

Consensus Security

The underlying blockchain provides standard BFT security guarantees:

  • Byzantine Fault Tolerance: Network remains secure with up to 1/3 malicious validators
  • Proof of Stake: Validators stake tokens; malicious behavior results in slashing
  • Instant Finality: Once a proof is settled, it cannot be reversed or tampered with

Full Node Responsibilities

Full nodes (validators) have AI-specific responsibilities beyond standard block validation:

  1. Verify Inference Proofs: Validate TEE attestations and ZKML proofs from inference nodes
  2. Maintain Node Registry: Track authorized inference nodes and their attestation status
  3. Settle Payments: Process payment settlement for inference operations
  4. Propagate Alerts: Broadcast warnings when invalid proofs are detected

These guarantees ensure users can trust inference results without trusting individual inference node operators.

Network Parameters

ParameterValueDescription
Block Time10 secondsTarget time between blocks for settlement
FinalityInstantProofs are final once committed—no confirmations needed
Consensus Threshold2/3+Required agreement for block finalization
Fault Tolerance<1/3Maximum Byzantine validators tolerated

TIP

You can explore the OpenGradient network at explorer.opengradient.ai.

Next Steps

  • Learn about the HACA Architecture and how node specialization enables scalable AI inference
  • Understand Full Nodes and their role in verification and settlement
  • Explore Inference Nodes and how they generate proofs