the first time i read through the inference contract, i stopped at the enum declaration. three options, vanilla, zkml, tee. one field value. the developer chooses and passes it in like any other parameter.
this is the verification spectrum in practice. @OpenGradient routes each call through a different trust path based on that one field. zkml produces a cryptographic proof any node can verify. tee wraps execution inside an Intel TDX enclave and returns hardware attestation. vanilla runs inference with almost no overhead and no proof attached.
the asymmetry is not in the options themselves but in who selects them. the developer sets the mode at build time, in contract code. end users never see which path is running beneath the protocol they interact with. a vault routing capital through an inference model could pick vanilla, and the result arrives on-chain with no signal that the lighter option was used.
cost structure explains the pressure. zkml runs 1,000 to 10,000 times slower than vanilla depending on model size. gas and latency costs push toward the cheaper path. if most production deployments default to vanilla, cryptographic verification becomes a capability the network offers but rarely exercises in practice.
this is not a design flaw. the spectrum exists because forcing zkml on every call would make the network unusable for llm workloads. the docs are explicit about the tradeoffs. but it shifts the guarantee from protocol to developer judgment, which is a different trust assumption than what users read into the phrase verifiable ai.
the broader pattern holds across the ai and crypto stack. infrastructure can offer trustlessness. market pressure tends to select against it. the gap between what a network can prove and what developers deploy is where risk accumulates quietly.
if you were building on this network today, which inference mode would you default to for capital decisions, drop your answer in the comments. see what the full verification stack looks like on $OPG.