Hard questions, answered honestly.

The receipt does not claim the answer is correct. It claims four things about the run that produced the answer:

• storage — the document body hashes to the recordedreceiptRoot.
• compute — the inference ran on a recorded provider.
• tee — the provider attestation re-checks from a second machine.
• chain — the anchor row matches the off-chain JSON.

You judge the answer the same way you would judge any second opinion. We give you a tamper-evident transcript so the opinion cannot be quietly rewritten later.

A ChatGPT screenshot proves nothing. There is no way to show a specific answer came from a specific model on a specific day, and there is no way to point a third party at an independent record that they could re-check on their own.

Every Ivaronix run produces a JSON receipt. The receipt is signed by the wallet that owns the agent passport, anchored on chain, and tied to the inference provider that ran it. A stranger who has never used Ivaronix can re-verify it from the CLI on their own machine.

The receipt body is canonicalised with RFC-8785 JCS and hashed with keccak256. The hash is what the signature signs and what the anchor row stores. None of those steps need our infrastructure.

If the indexer disappears, the four-light row would renderstorage amber and the remaining three green. The receipt still proves who signed what and when. Anyone with an archive node for the 0G chain can pull the anchor row; anyone with the receipt JSON can re-hash it and recover the signer.

We do not put the document on chain. We do not put the answer on chain. The chain stores a 32-byte root, the agent address, the receipt type, and the block timestamp. That is enough to prove the receipt existed at a given moment and was signed by a given identity.

A centralised database could do the same thing on paper, but the database operator can rewrite history. A public chain cannot, unless you trust 51% of validators to collude against a single row. That trade is worth the gas cost on a per-run basis.

With burn mode on, the document is encrypted with a 256-bit AES-GCM session key that is generated fresh per run. The ciphertext goes to 0G Storage. The session key only exists inside the 0G Compute TEE for the duration of the inference. The key buffer is zeroed after; we record a SHA-256 fingerprint of the key in the receipt so the use is auditable without rebuilding the key.

Threat model is explicit: /privacy lists what burn mode defends and what it does not. Local-machine compromise on your side is out of scope. A subpoena to the operator returns ciphertext.

The single field that decides this is teeVerification.verificationMethod:

• router_flag or compute_sdk_process_response → TIER 1. The TEE attestation re-checks from a second machine. The pill is green.
• external-signed → TIER 2. The inference ran on NVIDIA NIM, OpenAI, or a local model. The signature and the chain anchor still verify, but the plaintext was visible to the external operator for the duration of the call. The pill is amber. We render the amber on purpose.

Both tiers are real. The amber is honest, not a downgrade — the receipt does not lie about which provider ran it.

Price is set per skill, in OG, and is visible before you run anything. The split is encoded in the skill manifest under og.creator.fee_split as a basis-points pair that sums to 10000. The default is 9000 / 1000 (creator 90% / treasury 10%). Commoditised skill categories default to 7000 / 3000.

Payment happens on chain. The receipt anchors after the payment clears, so a run that did not pay never produces a receipt that looks paid.

The router accepts a credential of kind nim oropenai-compatible alongside the default 0G Compute route. The pipeline is identical: the same canonical hash, the same signature, the same chain anchor.

The only difference is the verificationMethod field, which captures the truth about where the inference ran. A TIER 2 receipt is still a real receipt; it is just amber on the TEE pill and we say so to anyone who opens the proof page.

Two replay paths exist today, both runnable without our servers:

• ivaronix receipt verify <id> --tee-independent — re-runs broker.processResponse against the recorded 0G Compute provider, re-hashes the canonical body, recovers the signer, and cross-checks the anchor row. Returns FULLY VERIFIED or a precise failure mode.
• A custom verifier in any language. The canonical hash is RFC-8785 JCS over the receipt body minus three fields (signature, id, chainAnchor). A third-party auditor can write their own and reach the same root.

The proof page hydrates the receipt body from 0G Storage and falls back to a local cache when the indexer is slow. While neither has returned yet, the page renders PENDING on the body pill. The chain anchor is already confirmed at that point — that is why the four-light row still has its other pills green.

Reload, or run ivaronix receipt show <id> from the CLI; the body comes back, the hash is re-verified, the pill turns green. No receipt has been lost.

Mainnet is live. Aristotle (chainId 16661) carries 10 deployed contracts and the full set of 13 receipt-type slots. Chainscan links resolve to chainscan.0g.ai for mainnet addresses. The verifier returns FULLY VERIFIED on mainnet receipts via broker.processResponse attestation, and the marketplace pays in real OG with the same 90/10 creator/ treasury split as the testnet build.

Galileo testnet (chainId 16602) stays live. It carries the larger receipt history (1,737+ anchored across V1+V2+V3), serves the JUDGE_GUIDE walkthrough, and is the default for ivaronix demo. The studio reads whichever network IVARONIX_NETWORK points at; the build serving this UI right now is whichever one the deployment env says. On-chain history never migrates — each network keeps its own ledger.

The monorepo holds the studio (Next.js), the CLI (Node.js), the Solidity contracts and Foundry tests, and three independent verifiers (TypeScript, Python, Rust) that agree byte-for-byte on the canonical hash.

A reviewer can clone, install, and run a verifiable demo with a public testnet wallet in under five minutes. The README carries the exact commands; the JUDGE_GUIDE walks the same path with screenshots.

A TEE is a CPU feature (Intel TDX, AMD SEV, NVIDIA H100 with confidential compute) that runs your code in an isolated memory region. The host operating system and the operator of the machine see encrypted memory pages only. The TEE produces an attestation — a signed quote that proves which code ran on which hardware.

On 0G Compute, inference for TIER 1 receipts runs inside a TEE. The receipt records the provider address and an attestation hash; any reviewer can re-run broker.processResponse against the recorded provider and confirm the attestation. The provider cannot read your prompt; the operator cannot read it either. That is the trust improvement over standard API inference.

The TEE does not promise the answer is correct. It promises the run happened on the model and provider it claims, with no operator-side interception. The four-light row on the receipt page shows this status as the TEE light: green when re-attestation passes, grey when the channel is transiently unreachable.

Publishing a skill sets a price in SkillPricing and a fee-split (default 90% creator / 10% treasury; commoditised categories use 70/30). When a buyer runs the skill, the studio calls SkillRunPayment.paySkillRun with the receipt root, creator address, and bps split. The contract holds the OG and credits the creator + treasury balances atomically.

The creator opens /marketplace/payouts and clicks Withdraw. The contract pays the full earned balance back to the creator wallet in one tx. Every paid run + every withdraw is a real on-chain event; nothing accrues off chain.

The 90/10 split is settable per skill at publish time. Treasury share funds infrastructure (RPC + indexer + KV sidecar). The contract emits a SkillRunPaid event with creatorShare + treasuryShare so subgraphs and dashboards can reconcile without rescanning every receipt.

A compromised provider could serve a different model than the receipt claims. The TEE attestation is the defence: a fake provider cannot produce a valid attestation that names the real provider's hardware identity. The reviewer re-runs broker.processResponse against the recorded provider address; if the attestation does not match, the verify chip stays grey.

A compromised provider that controls a real TEE could still serve a quantised or fine-tuned version of the advertised model. The receipt does not promise model fidelity at that level; it promises the inference ran on the named hardware with the named model identifier. Higher-stakes settings should run the same prompt across multiple providers and compare — the consensus tier (analyst + critic + judge) is the in-product answer for that, but a buyer can also run the same skill on a different operator and diff the receipts.

What the receipt absolutely defends against: a relay (the OpenAI-compatible Router that fronts the 0G Compute network) silently swapping providers. The Router cannot forge an attestation for a provider it does not control. If the Router returns a different model than the receipt claims, the TEE re-attestation fails and the receipt is honest about it.