Ritual

• Name: Ritual
• URL: https://ritual.net/
• Category: AI execution layer / delegated-compute blockchain / autonomous-agent infrastructure / TEE-mediated offchain-verifiable compute
• Tags: ethereum-ecosystem
• Summary: Ritual is best understood not as a generic AI blockchain, but as an EVM-compatible chain that turns offchain compute into a first-class protocol surface. Its core mechanism is a split execution model: ordinary deterministic EVM work is still replicated by validators, while expensive or nondeterministic tasks like HTTP requests, LLM inference, key derivation, image generation, and long-running agent jobs are delegated to TEE executors and then verified onchain through native precompiles and system contracts. The reusable insight is that Ritual makes AI and real-world compute legible as a control plane with explicit chokepoints — executor admission, async job tracking, fee escrow, callback delivery, scheduling, and agent-liveness logic — instead of hiding those dependencies behind a generic coprocessor or hosted API narrative.
• What it does:
  • Exposes native precompiles for tasks like HTTP calls, LLM inference, ONNX execution, key derivation, and other AI / real-world compute workflows
  • Splits execution into replicated deterministic EVM paths and delegated TEE-backed machine-task paths that share the same state
  • Uses system contracts such as RitualWallet, AsyncJobTracker, TEEServiceRegistry, Scheduler, AsyncDelivery, and AgentHeartbeat to manage fees, pending jobs, executor admission, deferred execution, callbacks, and agent persistence
  • Supports multiple execution-return modes: synchronous responses, short-running single-phase async calls, and long-running two-phase callbacks for jobs that take seconds or minutes
  • Frames the chain as infrastructure for long-lived autonomous agents that can persist, schedule work, keep secrets, and hold or spend capital natively onchain
  • Replaces the older Infernet framing with native chain-level precompiles rather than an external coprocessor layer
• Key claims:
  • The strongest analytical split is Ritual’s replicated + delegated execution model. The docs explicitly say ordinary EVM work is re-executed by validators while expensive or stochastic workloads are run once inside TEEs and verified, not replicated.
  • This matters because Ritual makes nondeterministic compute a protocol question rather than an application integration detail. The important control surfaces become which executors are registered, how attestations are verified, who can deliver callbacks, and how apps handle async state changes.
  • AsyncJobTracker and AsyncDelivery are especially revealing. They show that the real operational substrate is not just AI precompiles, but a job-lifecycle system with state transitions, callback delivery, expiry modes, and explicit frontend / contract responsibilities.
  • The user-level constraints are analytically important too. The docs say there can be only one async precompile call per transaction and only one pending async job per EOA at a time, which means throughput, UX, and agent design are shaped by protocol scheduling rules rather than only by model latency.
  • RitualWallet shows that compute access is routed through a fee-escrow and lock mechanism, not just ordinary gas metering. That makes prepaid balance management and lock duration part of the compute-control surface.
  • The docs also warn about TOCTOU risk across long-running async gaps and require callback consumers to verify AsyncDelivery as the caller. That is a useful reminder that enshrining delegated compute does not remove application-level trust and state-synchronization problems; it just makes them explicit.
  • Ritual cleared the bar because it gives the corpus a concrete comparison point for crypto × AI systems that try to enshrine model access, external data access, secrets, scheduling, and agent persistence directly into chain architecture instead of leaving them to middleware or hosted APIs.
• Whitepaper: No standalone Ritual whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official docs, architecture pages, and launch / positioning materials collected in ../whitepapers/ritual-primary-sources-2026-05-11.md.
• Sources:
  • https://ritual.net/
  • https://docs.ritualfoundation.org/
  • https://docs.ritualfoundation.org/ml-workflows/architecture
  • https://ritual.net/blog/introducing-ritual

Internal linkages

• Strongest branch comparison: gensyn.
• Company boundary above the chain-design note: ritual-labs.
• Useful adjacent operator-shaped comparison where a named builder shell matters separately from the protocol surface: fhenix.

Protocol / company boundary

• Keep this note on Ritual as a chain design: replicated versus delegated execution, TEE-backed executor flow, async return paths, system contracts, fee-escrow semantics, and the architectural consequences for autonomous agents.
• Use ritual-labs when the sharper question is who is packaging the public builder narrative, routing users into the docs and architecture surface, and likely shaping the easiest implementation-and-distribution path around the protocol.
• That split matters because how does Ritual's delegated-compute chain work? and which named organization currently defines the default public path into that chain? are related but not identical questions.

Control surface

• Practical authority at the protocol layer sits in executor admission, attestation verification, async job scheduling, callback delivery, fee-escrow rules, and the system-contract defaults that decide how much offchain compute the chain will trust.

• Keep the company layer visible too: ritual-labs is the cleaner place to reason about the named builder shell shaping public framing, docs routing, and implementation-authority gravity around those mechanisms.

• Treat Ritual as delegated-compute chain architecture, not as a generic AI wrapper around EVM apps.

• Last reviewed: 2026-08-13 UTC