Ritual Chain LLM Precompile: What the Receipt Actually Binds

#ai #crypto #web3 #security

Ritual Chain LLM Precompile: What the Receipt Actually Binds

A receipt for an LLM call means nothing until you say what it is supposed to back up. On Ritual Chain, the question worth asking is not whether a model answer reached chain-adjacent infrastructure. It is narrower: which part of the path does the receipt actually bind, and which part still falls to your application to validate.

Disclosure: AI assisted with drafting and structure. This article is technical education, not investment, trading, token, yield, or financial advice.

The Receipt Surface

Ritual Chain's documentation describes an EVM with off-chain verifiable machine tasks, where precompile calls like HTTP and LLM hand the real work to TEE executors. That detail is what makes the receipt boundary worth a close look. The contract-facing result here is not an ordinary deterministic EVM computation that every validator re-runs, so where the result came from is part of the answer.

The docs put the LLM precompile at 0x0802 and walk through a flow where a contract sends a prompt and gets a completion back. Read narrowly, the statement backs one implementation claim. A documented precompile surface for LLM inference exists. It says nothing about whether the answer is true, safe, unbiased, or ready to trigger a sensitive action.

The Short Async Path

Execution paths in the docs split three ways: synchronous work, short-running async work, and longer two-phase async work. The first boundary lives in the short-running path, since that is where the docs group HTTP, LLM, and DKMS calls and route returned data through receipt.spcCalls.

For a developer, that path hands the application a concrete place to inspect what the documented precompile call returned. It is not a semantic oracle, though. A value sitting in receipt.spcCalls can be evidence that a result came back through the documented path and still be a terrible answer for your domain.

The Streaming Trap

The docs also cover optional streaming, where executor-pushed tokens can land in a frontend before finalization, carrying EIP-712 signatures. Precision matters here. EIP-712 defines typed structured data signing, nothing more. It does not turn a streamed token into final chain state, does not prove replay protection, and does not prove the text is correct.

A frontend that renders streamed text should treat it as preview until the final receipt path lands. The signature helps the interface reason about origin and structure, but that is a long way from application acceptance. Your application still decides which actions, if any, the text gets to influence.

Attestation Is Appraisal Input

TEE executors and component roles like TEEServiceRegistry get their own treatment in the docs, which list it as the contract that registers TEE executors and attestation proofs. That earns a component-role claim, nothing about whether every model output is correct.

RFC 9334 helps here by framing remote attestation as evidence, verification, and relying-party appraisal. That framing keeps things honest. An attestation result can feed a policy decision, but the relying party keeps its own policy. For an LLM answer, provenance and environment evidence never stand in for validating the answer itself.

The Sender Lock And The Gap

A sender-lock boundary shows up too, where each EOA can hold only one pending async job at a time. The same execution docs flag TOCTOU risk across the async gap and push the work of checking preconditions onto the consumer contract when a callback arrives.

Both details matter because they stop you from treating the receipt as a complete control plane. The receipt boundary is one piece. Your application still has to account for time, pending work, stale assumptions, and state that shifts between request and response.

A Receipt Boundary Artifact

Call the artifact ritual_llm_precompile_receipt_boundary.v1. It is not an official Ritual standard. Think of it as a developer checklist that separates what the receipt can back from what the application still has to prove.

{
  "schema": "ritual_llm_precompile_receipt_boundary.v1",
  "surface": "ritual_chain_llm_precompile",
  "request_binding": {
    "precompile": "0x0802",
    "prompt_hash": "sha256:example",
    "input_parameters_hash": "sha256:example",
    "executor_reference": "documented_tee_executor_path"
  },
  "execution_path": {
    "mode": "short_running_async_single_phase",
    "documented_result_location": "receipt.spcCalls[0].output",
    "streaming_tokens_are_pre_finalization": true,
    "one_async_precompile_per_transaction_constraint": true,
    "sender_lock_for_pending_async_job": true,
    "two_phase_toctou_requires_callback_precondition_checks": true
  },
  "registry_and_attestation_boundary": {
    "registry": "TEEServiceRegistry",
    "documented_role": "registers TEE executors and attestation proofs",
    "boundary": "registration and attestation bind an executor/proof path, not semantic truth"
  },
  "receipt_can_support": [
    "which request was sent",
    "which documented precompile path was used",
    "which output bytes or completion were returned",
    "whether data is final receipt output or preliminary stream data"
  ],
  "receipt_cannot_support_by_itself": [
    "the answer is true",
    "the answer is safe",
    "the output should trigger a transaction",
    "the application policy accepted the result"
  ]
}

Application Checks Above The Receipt

Treat the receipt as a source map at the application layer, not a final judgment. A workable policy checks schema shape, allowed output classes, stale state, source or tool cross-checks, and whether the output came from final receipt data or a streamed preview.

That policy is where the LLM answer earns its place or gets thrown out. Say a model claims an address is safe. The receipt may help prove which path produced that sentence. It still does not prove the address is safe. That call has to live above the receipt.