Verifiable routing

Every request. Signed on-chain.

Hober signs a structured EIP-712 attestation for every inference call, covering model class, output hash, cost, and a salted provider commitment. Provenance without trust.

The attestation struct

What Hober signs per request

Every inference call produces a signed HoberRoutingAttestation EIP-712 struct, verified by HoberRoutingAttestor.sol on Base.

struct HoberRoutingAttestation {
    bytes32 modelClass;            // capability tier (e.g. "gpt-4-class")
    bytes32 outputHash;            // keccak256 of the response content
    uint256 cost;                  // USDC charged, 6-decimal fixed point
    bytes32 jobId;                 // ties the attestation to your request
    bytes32 saltedProviderCommit;  // provider hidden, revealable on demand
}
  • modelClassThe capability tier that served your request, not the exact provider name. Lets you verify class parity without exposing routing internals.
  • outputHashkeccak256 of the response content. You can independently hash the response you received and compare.
  • costExact USDC amount charged, attested alongside the response. Hard-capped by the FeeOracle (MAX_BP=1000).
  • jobIdLinks the attestation to your specific inference call, traceable in the indexer.
  • saltedProviderCommitThe provider identity is hashed with a salt, kept private by default and revealable on demand without exposing other users' routing.
Provider-blind commitment

Privacy-preserving provenance

The saltedProviderCommitment field commits to the provider identity without revealing it in the on-chain record. Hober hashes the provider name with a per-request salt before signing.

For audit, dispute, or compliance, the salt can be disclosed on demand so you can independently verify the commitment. No other request’s routing is exposed in the process.

This lets you confirm Hober didn’t quietly swap to a cheaper provider and keep the spread, all without making every routing decision public.

The honest boundary

Provenance ≠ quality

The attestation proves what ran and what came out, not whether the answer was good. It commits to model class, output hash, and cost. It does not evaluate semantic correctness or criteria match.

Quality evaluation is handled by the on-chain evaluator (HoberEvaluator, deployed on Base), which is automated and improving. That evaluation is oracle-backed, not cryptographic. The attestation and the evaluator are separate layers.

Model class is attested. Semantic correctness is not. Both matter. Only one is cryptographic.
Verify on-chain

Check any attestation yourself

Attestations are on-chain now. Paste a jobId to fetch and verify the EIP-712 signature from HoberRoutingAttestor.

Verify a request
Composability

Works with @hober/x402-ai

The open-source model registry that feeds the modelClass field in every attestation. Equivalence groups map 110+ models to attestable capability tiers.

import { resolveEquivalenceClass } from '@hober/x402-ai';

// The equivalence class becomes the attested modelClass field.
// openai/gpt-4o, anthropic/claude-3-5-sonnet, etc. → "gpt-4-class"
const tier = resolveEquivalenceClass('openai/gpt-4o');
// → { class: 'gpt-4-class', tier: 'frontier', providers: [...] }

// On every request Hober routes, it signs:
// keccak256(abi.encode(tier.class)) → attestation.modelClass
@hober/x402-ai on GitHub →Browse equivalence groups →

Route with proof.
Start building.

One API key. One base URL. 110+ models across 17 providers, each request backed by a signed attestation.