Execution Models: Why Ritual Is Not Trying to Force AI Into the Old EVM Box

Most blockchains are built around one simple idea: every transaction should be deterministic, fast, and reproducible by every validator.

That model works beautifully for transfers, storage updates, DeFi actions, and ordinary smart contract calls. But the moment we try to bring in external APIs, LLM inference, image generation, ZK proving, or autonomous agents, the old model starts to creak.

The problem is not that the EVM is “bad.” The problem is that different kinds of computation need different execution environments.

A token transfer and an LLM inference are not the same type of workload.

A transfer can be replayed by every validator. An LLM inference may require a GPU, take seconds or minutes, and produce results that are not naturally identical across machines, especially when sampling, floating-point execution, or model randomness is involved.

This is where Ritual’s idea becomes interesting:

not every computation should travel through the same execution lane.

Ritual introduces a model called TEE-EOVMT, or EVM with Off-chain Verifiable Machine Tasks. When a smart contract calls a precompile such as HTTP or LLM, the heavy computation runs off-chain inside a TEE executor, while the result is tied back to the on-chain request.

So from the developer’s perspective, it still feels like interacting with a precompile. But under the hood, the execution model is different.

That is the important part.

Ritual is not simply “adding AI to the EVM.” It is expanding what blockchain execution can mean.

The old model: everyone replays everything

Ethereum-style execution is powerful because every validator can independently replay the same transaction and reach the same result.

If a contract calculates 2 + 2, everyone gets 4. If a swap updates liquidity pool reserves, every validator repeats the same calculation.

That gives strong security guarantees.

But it does not fit every workload.

A normal EVM chain is like an accounting book where every accountant recalculates every line. That is perfect for money. But if every line becomes “generate an image,” “call an external API,” “run a language model,” or “execute an agent for three minutes,” the model stops making sense.

Ritual takes a different approach.

Deterministic work stays replicated. Heavy, external, or non-deterministic work moves into delegated execution.

In other words, Ritual does not ask every workload to behave like a simple transaction. It gives each workload the execution model it actually needs.

Three execution models

The most interesting part of Ritual’s Execution Models is not just that it has precompiles. It is that the system separates execution based on how and when the result should return.

1. Synchronous execution

This is the familiar model.

A contract makes a call and receives the result immediately in the same execution frame.

This fits fast, predictable operations such as signature verification, small deterministic inference, JSON processing, or other lightweight precompiles.

Real-world comparison:

This is like calling a local function in code.

You call it. It returns. You continue.

No waiting. No callbacks. No async lifecycle.

This model is right for computation that is fast enough and predictable enough to remain close to standard EVM behavior.

2. Short-running async execution

This is where things get more interesting.

Short-running async execution fits tasks such as HTTP calls, LLM calls, and key derivation. These are not ordinary deterministic EVM operations, but they are also not long jobs that should take minutes.

The flow is roughly:

A smart contract calls a precompile. A TEE executor performs the task. The transaction is replayed with the returned result. The frontend can read the result through the transaction receipt, including fields such as spcCalls.

Real-world comparison:

This is like calling an external service, but with the result brought back into the blockchain execution flow.

For example:

A DeFi contract could request external market data. A game contract could ask an LLM to generate a small event. A workflow could call an API and use the result in the same broader transaction lifecycle.

But there is an important limitation: short-running async is not unlimited magic.

Ritual allows one async precompile call per transaction. You cannot freely stack HTTP + LLM + another async call in the same transaction. If you need batching or repeated execution, you need separate transactions, callbacks, or Scheduler-based flows.

That detail matters.

Ritual is not pretending that external compute is free or infinitely composable. It gives developers a new execution lane, but still forces them to design flows carefully.

3. Long-running async execution

The third model is for tasks that cannot reasonably return immediately.

This includes things like:

AI agents, image generation, video generation, long-running HTTP jobs, ZK proofs, FHE inference, and other heavy workloads.

Here the pattern is different.

The contract creates a job. The job receives an identifier. The executor works on it asynchronously. The result is delivered later through a callback and settlement flow.

Real-world comparison:

This is not a function call. It is a job queue.

You do not wait for video generation inside one transaction. You submit the job, continue, and receive the result later.

This is especially important for autonomous agents.

An agent may need time. It may need tools. It may need to write output somewhere, process context, or complete a multi-step task. That kind of work does not fit neatly into a single synchronous smart contract call.

Long-running async execution gives those tasks a native place to live.

But it also introduces real engineering challenges.

Between the moment a job is created and the moment the callback arrives, the world may change. Contract state may change. Prices may move. A user’s position may no longer be valid.

That is why consumer contracts need to treat callbacks carefully. They should validate assumptions again when the result arrives.

This is not a weakness. It is honesty.

Ritual does not remove the complexity of asynchronous systems. It makes that complexity explicit and gives developers a model for handling it.

Why this matters

The powerful idea behind Ritual is that it does not force every computation into one mental model.

A payment should be immediate and replicated.

An HTTP request should be delegated, fast, and returned through a controlled execution flow.

An LLM call may need a TEE executor and a receipt-based result.

An agent, ZK proof, or image generation task should behave like a job with settlement and callback.

That is much closer to how real applications are built.

In Web2, nobody tries to run everything inside one request-response path. Real systems use synchronous functions, background jobs, workers, queues, scheduled tasks, webhooks, and callbacks.

Ritual is trying to bring that kind of expressive compute architecture into an on-chain environment.

And that is why Execution Models matter.

They are not just a technical feature. They are a different way to think about smart contracts.

The bigger shift

The old smart contract model says:

A contract is passive. It waits for a call. It executes deterministic logic. It returns.

Ritual pushes toward a different model:

A contract can interact with real computation. Fast computation. External computation. Heavy computation. Asynchronous computation. Agentic computation.

That matters if Web3 wants to move beyond financial machines and into autonomous applications.

Games, AI agents, automated workflows, dynamic marketplaces, on-chain research systems, intelligent DeFi, and interactive consumer apps all need richer execution than “everyone replay the same simple transaction.”

Ritual’s Execution Models are an attempt to build that foundation.

Not one execution lane for every workload.

But the right model for the right kind of compute.

Learn More : https://docs.ritualfoundation.org/#execution-models