Who Cares?

What can you do on Ritual Chain that you cannot do on any other major L1 today?

Quick Start

Chain Architecture

How Ritual Chain routes computation through TEE executors, and the three layers between your dApp and the chain.

Ritual Chain runs on what we call TEE-EOVMT, an EVM with Off-chain Verifiable Machine Tasks. When your contract calls a precompile like HTTP or LLM, the actual work happens off-chain inside a TEE (Trusted Execution Environment). The executor can't fake results: each response is cryptographically tied to the exact request that triggered it.

There are three layers. Your dApp (frontend + contracts) talks to the precompile layer (16 precompiled contracts), which delegates to the chain layer (AsyncJobTracker, RitualWallet, Scheduler, and the rest of the orchestration infra).

Superposition: Replicated + Delegated

Ritual Chain runs two execution paths over the same state. Replicated execution (the standard EVM path) handles deterministic operations: token transfers, storage reads, contract calls. Every validator re-executes these. Delegated execution handles everything else: LLM inference, HTTP calls, agent orchestration, image generation. These run once inside a TEE, and the result is verified rather than replicated.

Both paths share state. A delegated LLM call can read a storage slot that was just written by a replicated transfer in the same block. This is what the Symphony paper calls superposition: two execution models coexisting over a single state machine, chosen per-transaction by the workload type.

Why Delegation, Not Replication

Replication breaks for two reasons. First, cost inversion: neural network inference with billions of parameters takes seconds to minutes and requires GPUs. Requiring every validator to own a GPU and re-run every inference defeats decentralization. Second, randomness: GPU floating-point arithmetic is non-associative across hardware (thread scheduling varies the reduction order), and LLM sampling with temperature > 0 is intentionally stochastic. Two honest validators running the same model on the same input produce different outputs. This is not a bug. It is IEEE 754 arithmetic under parallel reduction.

Correctness for these workloads means proving a given output is consistent with the computation, not comparing outputs across replicas. TEE attestation handles this: the executor's enclave produces hardware-signed evidence of what code ran on what input, registered on-chain via TEEServiceRegistry. The block builder only accepts results from registered executors with valid attestations.

From your contract's perspective, calling 0x0801 (HTTP) or 0x0802 (LLM) looks like calling any other precompile. The delegation is invisible. Results come back through one of three paths depending on how long the computation takes.

Execution Models

How results get back to you. Three paths, each for a different speed of computation.

The question is: when does your contract (or your frontend) get the result? Synchronous precompiles return inline, same call frame. Short running async precompiles stuff the result into the transaction receipt and also slot in the results from that precompile call. Two phase or long running precompiles deliver the result via a callback transaction, sometimes seconds or minutes later.

Synchronous

Returns the value inline, in the same call frame. The caller treats it as a regular precompile, with no async lifecycle and no spcCalls field on the receipt.

Precompiles: ONNX (0x0800), Ed25519 (0x0009), SECP256R1 (0x0100), JQ, TxHash.

Short-Running Async (Single-Phase)

For HTTP requests, LLM calls, and DKMS key derivation (100ms–2s). The block builder detects the precompile call, farms it to a TEE executor, and replays your transaction with the signed result. Your contract receives the result via _executePrecompile() in the same transaction.

Long-Running Async (Two-Phase)

For anything that takes seconds to minutes — image generation, agent runs, long-polling HTTP, ZK proofs. Phase 1 commits the request and returns a task ID. Phase 2: the executor delivers the final result via AsyncDelivery, which calls back into your contract in a separate transaction.

Async Lifecycle

Every async precompile call moves through a state machine. Here's what each state means and what to watch for.

AsyncJobTracker tracks the lifecycle of every async job. State transitions fire events: JobAdded, Phase1Settled, ResultDelivered, JobRemoved. Subscribe to these in your frontend to keep the UI in sync.

State Descriptions

import { watchContractEvent } from "viem";

watchContractEvent(client, {
  address: "0xC069FFCa0389f44eCA2C626e55491b0ab045AEF5",
  abi: asyncJobTrackerAbi,
  eventName: "JobAdded",
  args: { sender: userAddress },
  onLogs(logs) {
    const { jobId, status } = logs[0].args;
    // Update UI state machine
  },
});

Precompile Map

What smart contracts can do on Ritual. Seven capabilities, sixteen precompiles.

System Contracts

Eight contracts deployed to genesis that run the chain's plumbing.

RitualWallet

Precompile calls cost fees. You prepay by depositing RITUAL into RitualWallet. Call deposit(lockDuration) to fund your own address, or depositFor(user, lockDuration) for someone else. Lock is monotonic: new deposits only extend, never shorten the lock.

interface IRitualWallet {
    function deposit(uint256 lockDuration) external payable;
    function depositFor(address user, uint256 lockDuration) external payable;
    function withdraw(uint256 amount) external;
    function balanceOf(address account) external view returns (uint256);
    function lockUntil(address account) external view returns (uint256);
}

// Deposit 0.01 RITUAL with lock duration of 100 blocks
IRitualWallet(0x532F...3948).deposit{value: 0.01 ether}(100);

// Withdraw after lock expires
IRitualWallet(0x532F...3948).withdraw(0.005 ether);

AsyncJobTracker

Tracks every pending async job and emits lifecycle events (JobAdded, Phase1Settled, ResultDelivered, JobRemoved). Also enforces the sender lock: one pending job per EOA, period.

AsyncDelivery

Where two-phase results land. The executor sends the result here, and AsyncDelivery forwards it to your contract's callback. Check msg.sender == 0x5A16…39F6 in your callback or anyone can inject fake results.

HTTP Precompile

Your contract can call any URL directly from Solidity. REST APIs, webhooks, price feeds.

The HTTP precompile at 0x0801 makes the request inside a TEE, attests the response, and returns it to your contract in the same transaction. Your contract decodes the response and acts on it on-chain. Settle a market, update a price feed, trigger a swap. No oracles. No off-chain relayers. One precompile call.

In Practice

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {PrecompileConsumer} from "./utils/PrecompileConsumer.sol";

contract PriceFeed is PrecompileConsumer {
    uint256 public latestPrice;

    function fetchPrice(bytes calldata httpInput) external {
        bytes memory output = _executePrecompile(HTTP_CALL_PRECOMPILE, httpInput);

        // Decode: (uint16 status, string[] keys, string[] vals, bytes body, string err)
        (
            uint16 statusCode,
            ,
            ,
            bytes memory body,
            string memory errorMessage
        ) = abi.decode(output, (uint16, string[], string[], bytes, string));

        require(statusCode == 200, errorMessage);
        // Parse body with JQ precompile or off-chain
    }
}

Encode The Request

bytes memory input = abi.encode(
    executor,                // address: from TEEServiceRegistry
    new bytes[](0),         // bytes[]: encryptedSecrets
    uint256(30),             // uint256: ttl (blocks)
    new bytes[](0),         // bytes[]: secretSignatures
    bytes(""),               // bytes: userPublicKey (empty = plaintext)
    "https://api.example.com/price", // string: url
    uint8(1),                // uint8: method (1=GET)
    headerKeys,              // string[]: header names
    headerValues,            // string[]: header values
    bytes(""),               // bytes: body
    uint256(0),              // uint256: dkmsKeyIndex
    uint8(0),                // uint8: dkmsKeyFormat
    false                    // bool: piiEnabled
);

import { encodeAbiParameters, parseAbiParameters } from "viem";

const encoded = encodeAbiParameters(
  parseAbiParameters("address, bytes[], uint256, bytes[], bytes, string, uint8, string[], string[], bytes, uint256, uint8, bool"),
  [
    executorAddress,        // executor
    [],                     // encryptedSecrets
    30n,                   // ttl
    [],                     // secretSignatures
    "0x",                   // userPublicKey
    "https://api.example.com/price",
    1,                       // GET
    [], [],                 // headers
    "0x",                   // body
    0n, 0,                 // dkms
    false,                  // piiEnabled
  ]
);

from ritual_common.http_call.request import HTTPCallRequest, HTTPMethod

request = HTTPCallRequest(
    executor=executor_address,
    encrypted_secrets=[],
    ttl=30,
    secret_signature=[],
    user_public_key=b"",
    url="https://api.example.com/price",
    method=HTTPMethod.GET,
    headers={},
    body=b"",
    dkms_key_index=None,
    dkms_key_format=None,
    pii_enabled=False,
)
encoded = request.to_web3()

13-Field ABI Reference

Response Format

(uint16 statusCode, string[] headerKeys, string[] headerValues, bytes body, string errorMessage)

The response body is bytes, not string. Decode it with TextDecoder for text responses, or use directly for binary data. Always check errorMessage. It's non-empty when the precompile-level request failed (distinct from HTTP error status codes).

JQ Data Queries (0x0803)

0x0803 runs jq expressions against JSON strings and returns typed results. Synchronous. Call it, get your answer in the same transaction. Most common use: chain an HTTP call with a JQ call in the same TX to extract a field from the response.

(bool ok, bytes memory result) = JQ_PRECOMPILE.staticcall(
    abi.encode(
        ".data.price",
        jsonString,
        uint8(1)  // uint256
    )
);
require(ok && result.length > 0, "jq: empty or failed");
uint256 price = abi.decode(result, (uint256));

LLM Inference

Your contract can call frontier LLMs and act on the result. Submit a prompt, handle the response in a callback when the executor returns.

The LLM precompile at 0x0802 runs an open-weight model (zai-org/GLM-4.7-FP8, 64K context) inside a TEE. No API keys needed. Your contract sends a prompt, receives a completion, and writes state in one transaction. For frontends that need progressive output, enable streaming: the executor pushes response tokens over SSE, each signed with EIP-712 so your UI can verify they came from the TEE.

Open-Weight Model

The LLM precompile runs zai-org/GLM-4.7-FP8 (64K context, MIT license), an open-weight model hosted directly in the TEE fleet. No external API keys required. Unlike HTTP-based calls to OpenAI/Anthropic or Sovereign Agent CLI execution, the LLM precompile's model is self-hosted with TEE-only trust.

In Practice

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {PrecompileConsumer} from "./utils/PrecompileConsumer.sol";

contract OnChainChat is PrecompileConsumer {
    event Response(string text);

    function ask(bytes calldata llmInput) external {
        bytes memory output = _executePrecompile(LLM_INFERENCE_PRECOMPILE, llmInput);

        // (bool hasError, bytes completionData, bytes modelMetadata,
        //  string errorMessage, (string,string,string) updatedConvoHistory)
        (
            bool hasError,
            bytes memory completionData,
            ,
            string memory errorMessage,
        ) = abi.decode(output, (bool, bytes, bytes, string, (string,string,string)));

        require(!hasError, errorMessage);
        // completionData contains the chat completion response
    }
}

Encode The Request

The LLM precompile has a 25-field ABI mirroring the OpenAI chat completion API. Most fields can be left at their defaults. The key fields are messagesJson (field 5), model (field 6), temperature (field 22), and convoHistory (field 24, required).

// Encoding the full 25-field request on-chain is gas-heavy.
// Typical pattern: encode off-chain, pass as bytes calldata.
// See TypeScript or Python tabs for the encoding.

// On-chain, you just forward the pre-encoded bytes:
function ask(bytes calldata llmInput) external {
    _executePrecompile(LLM_INFERENCE_PRECOMPILE, llmInput);
}

import { encodeAbiParameters, parseAbiParameters } from "viem";

const messages = JSON.stringify([
  { role: "user", content: "What is the current price of ETH?" }
]);

const encoded = encodeAbiParameters(
  parseAbiParameters("address, bytes[], uint256, bytes[], bytes, string, string, int256, string, bool, int256, string, string, uint256, bool, int256, string, bytes, int256, string, string, bool, int256, bytes, bytes, int256, int256, string, bool, (string,string,string)"),
  [
    executorAddress,       // 0: executor
    [], 30n, [], "0x",     // 1-4: secrets, ttl, sigs, pubkey
    messages,              // 5: messagesJson
    "zai-org/GLM-4.7-FP8",// 6: model
    0n, "", false, -1n,   // 7-10: freq, logitBias, logprobs, maxTokens
    "", "", 1n, false,    // 11-14: metadata, modalities, n, parallelTools
    0n, "", "0x", -1n,   // 15-18: presence, reasoning, responseFormat, seed
    "", "",                // 19-20: serviceTier, stop
    false,                 // 21: stream
    700n,                  // 22: temperature (0.7 × 1000)
    "0x", "0x",            // 23-24: toolChoice, tools
    -1n, 1000n,            // 25-26: topLogprobs, topP
    "", false,              // 27-28: user, piiEnabled
    ["gcs", "convos/session.jsonl", "GCS_CREDS"], // 29: convoHistory
  ]
);

from ritual_common.llm_call.request import LLMCallRequest
from ritual_common.sovereign_agent.request import StorageRef

request = LLMCallRequest(
    executor=executor_address,
    encrypted_secrets=[],
    ttl=30,
    secret_signature=[],
    user_public_key=b"",
    messages=[{"role": "user", "content": "What is ETH price?"}],
    model="zai-org/GLM-4.7-FP8",
    temperature=0.7,
    convo_history=StorageRef("gcs", "convos/session.jsonl", "GCS_CREDS"),
)
encoded = request.to_web3()

Streaming with EIP-712

Set stream: true in the LLM call. After the transaction is mined, sign a stream request with EIP-712 and connect to the SSE endpoint. Each chunk is verified by the TEE's attestation.

// 1. Sign a StreamRequest with EIP-712
const signature = await wallet.signTypedData({
  domain: { name: "Ritual Streaming Service", version: "1", chainId: 1979 },
  types: { StreamRequest: [
    { name: "txHash", type: "bytes32" },
    { name: "timestamp", type: "uint256" },
  ]},
  message: { txHash, timestamp: BigInt(Date.now()) },
});

// 2. Connect to SSE stream with auth headers
const response = await fetch(`/v1/stream/${txHash}`, {
  headers: { "Authorization": `Bearer ${signature}`, "X-Timestamp": timestamp },
});

// 3. Read chunks from ReadableStream
const reader = response.body.getReader();
const decoder = new TextDecoder();
while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  const chunk = decoder.decode(value);
  if (chunk.includes("[DONE]")) break;
  // process chunk
}

25-Field ABI Reference

Response Format

(bool hasError, bytes completionData, bytes modelMetadata, string errorMessage, (string,string,string) updatedConvoHistory)

Autonomous Agents

Your contract can spawn autonomous agents that persist across transactions, with memory, identity, and the ability to revive themselves.

An autonomous agent that is indistinguishable from a human must have all seven of the properties below. Missing even one makes it a tool, not an agent.

Seven Properties

Agent Precompiles

On-chain agents that survive indefinitely with four architectural components: soul (identity, purpose, behavioral constraints), memory (accumulated state and knowledge), DA (data availability layer for durable persistence via StorageRef), and revival (deterministic re-instantiation from persisted state via CID).

Persistent Agent (0x0820)

Stateful with soul, memory, identity, and data availability references. Persists across sessions via StorageRef (HuggingFace, GCS, Pinata, IPFS). Revival from CID restores full state. Two-phase async: Phase 1 submits the spawn, Phase 2 delivers the result via onPersistentAgentResult(bytes32, bytes) callback. One Persistent Agent call per transaction.

Sovereign Agent (0x080C)

CLI-style agent execution inside a TEE. The precompile invokes specific command-line harnesses in a sandboxed container. Two-phase async with callback onSovereignAgentResult(bytes32, bytes).

How Agents Stay Alive

Reactive contracts wait to be called. On Ritual, contracts wake themselves up. This is what makes on-chain agents possible.

Contracts on Ethereum are reactive. They sit idle until someone calls them. On Ritual, contracts can be proactive. They wake themselves up, take actions, and schedule their next execution. This is what makes an on-chain agent possible. Not a bot on someone's server. An entity whose lifecycle is tied to the blockchain itself.

Two architectures, same guarantee: the agent lives as long as it has funds. To kill it, you'd have to take the entire network down.

Sovereign Agents: The Contract Is The Agent

A sovereign agent is a contract that uses the Scheduler to wake itself up at regular intervals. Each time it wakes, it invokes the Sovereign Agent precompile (0x080C) to run a full CLI harness (Claude Code, ZeroClaw, or Crush) inside a TEE. The CLI can read files, execute code, browse the web, and interact with the blockchain. When it finishes, the result (text, artifacts, StorageRefs) is delivered back to the contract via callback. The contract processes the result and schedules its next wakeup.

The owner calls start(), which schedules the first wakeUp(). The block builder fires it at the scheduled block. wakeUp() invokes the CLI agent (0x080C), the executor runs it in a TEE, and the Phase 2 callback delivers the result. Then _scheduleNext() queues the next wakeup. No keeper. No cron job. No server. The contract pays from its own RitualWallet balance.

Persistent Agents: Containers That Can't Die

A persistent agent runs as a Docker container (typically ZeroClaw) inside a TEE. The container has full access to file ops, shell, web search, HTTP, and blockchain interactions. It persists state across sessions via DA references (HuggingFace, GCS, Pinata, IPFS) and posts heartbeats to the on-chain AgentHeartbeat contract at 0xEF505E801f1Db392B5289690E2ffc20e840A3aCa.

The heartbeat contract is a censorship-resistant bulletin board. The agent writes its latest manifest CID on-chain every 100 blocks. Anyone can read it. Any block builder can act on it.

The dead man's switch: every block, the builder checks for agents that haven't posted a heartbeat within the timeout window (configurable per deployment, typically 200 blocks). If an agent is silent, it's marked FAILED. The chain then triggers revival automatically: it calls the Persistent Agent precompile with the agent's last manifest CID. The executor restores the container from the DA checkpoint. Secrets are recovered from DKMS escrow. The agent wakes up with its full memory, identity, and state intact.

The Cost Of Living

Both architectures require funds. Sovereign agents pay from their RitualWallet balance for each scheduled execution. Persistent agents need at least 0.1 RITUAL in their address balance to cover heartbeat transactions. When the money runs out, the agent stops. Immortality is economically bounded.

Sovereign Vs Persistent

Why this is unique

No other platform ties agent lifecycle to blockchain consensus. Frontier lab agents run on centralized infrastructure. When the server goes down, the agent dies. On Ritual, the agent's heartbeat is part of the block production pipeline. The block builder checks for expired agents. The block verifier enforces heartbeat constraints. Revival is permissionless. Decentralization of AI means decentralization of agent lifetime.

Building Agents

Precompile ABIs, code examples, and encoding for Persistent and Sovereign agents.

The Sovereign Agent Loop

This is the contract from "How They Stay Alive." It wakes itself up via the Scheduler, invokes a CLI harness in a TEE, processes the result, and schedules its next wakeup. The contract IS the agent.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {PrecompileConsumer} from "./utils/PrecompileConsumer.sol";
import {IScheduler} from "./interfaces/IScheduler.sol";

contract AutonomousAgent is PrecompileConsumer {
    IScheduler public scheduler;
    uint256 public callId;
    uint256 public wakeCount;
    uint32 public nextWakeDelay = 50; // blocks between wakeups
    bool public isRunning;

    // 1. Owner starts the loop
    function start(uint32 initialDelay) external {
        isRunning = true;
        callId = _scheduleNext(initialDelay);
    }

    // 2. Scheduler fires this at the scheduled block
    function wakeUp(uint256 executionIndex) external {
        require(msg.sender == address(scheduler));
        if (!isRunning) return;
        wakeCount++;
        _callCLIAgent();                    // invoke 0x080C
        callId = _scheduleNext(nextWakeDelay); // schedule next wakeup
    }

    // 3. Phase 2 callback with agent output
    function onSovereignAgentResult(bytes32 jobId, bytes calldata result) external {
        require(msg.sender == ASYNC_DELIVERY);
        // result contains text, artifacts, updated convo history
        // process it, write state, act on it
    }

    function _callCLIAgent() internal {
        _executePrecompile(SOVEREIGN_AGENT_PRECOMPILE, agentInput);
    }

    function _scheduleNext(uint32 delay) internal returns (uint256) {
        return scheduler.schedule(
            abi.encodeWithSelector(this.wakeUp.selector, uint256(0)),
            800_000,                          // gas
            uint32(block.number) + delay,      // startBlock
            3,                                 // retry slots
            1,                                 // frequency
            30,                                // ttl
            20 gwei, 2 gwei, 0,            // fees
            address(this)                     // payer = self
        );
    }
}

Spawning A Persistent Agent

Persistent agents are spawned by calling the 0x0820 precompile with soul, memory, and DA references. The agent container runs in a TEE. Set restoreFromCid (field 23) to revive from a previous checkpoint instead of starting fresh.

contract AgentSpawner is PrecompileConsumer {
    event AgentSpawned(bytes32 indexed jobId);
    event AgentResult(bytes32 indexed jobId, bytes result);

    // Spawn: input is 25-field ABI with soul, memory, DA refs
    function spawn(bytes calldata agentInput) external {
        _executePrecompile(PERSISTENT_AGENT_PRECOMPILE, agentInput);
    }

    // Revive: same call but restoreFromCid is non-empty,
    // encryptedSecrets is empty (recovered from DKMS escrow)
    function revive(bytes calldata reviveInput) external {
        _executePrecompile(PERSISTENT_AGENT_PRECOMPILE, reviveInput);
    }

    // Phase 2 callback from AsyncDelivery
    function onPersistentAgentResult(
        bytes32 jobId, bytes calldata result
    ) external {
        require(msg.sender == ASYNC_DELIVERY);
        emit AgentResult(jobId, result);
    }
}

Encode The Request

// Sovereign Agent: 23-field encoding
// Key fields: cliType (11), prompt (12), tools (19)
// Encoding is typically done off-chain and passed as bytes calldata

// Persistent Agent: 25-field encoding
// Key fields: daConfig (15), soulRef (16), memoryRef (19), restoreFromCid (23)
// For revival: set restoreFromCid to the manifest CID, leave encryptedSecrets empty

// Sovereign Agent encoding (23 fields)
const encoded = encodeAbiParameters(
  parseAbiParameters("address, uint256, bytes, uint64, uint64, string, address, bytes4, uint256, uint256, uint256, uint16, string, bytes, (string,string,string), (string,string,string), (string,string,string)[], (string,string,string), string, string[], uint16, uint32, string"),
  [
    executorAddress,       // 0: executor
    30n, "0x",            // 1-2: ttl, userPublicKey
    10n, 200n, "",        // 3-5: polling config
    callbackAddr, selector, gasLimit, maxFee, maxPriority, // 6-10: delivery
    0,                     // 11: cliType (0=Claude Code)
    "Analyze market data and suggest trades", // 12: prompt
    encryptedSecrets,      // 13: ECIES-encrypted API keys
    convoHistory, output, skills, systemPrompt, // 14-17
    model, tools, maxTurns, maxTokens, rpcUrls, // 18-22
  ]
);

from ritual_common.persistent_agent.request import PersistentAgentRequest
from ritual_common.sovereign_agent.request import SovereignAgentRequest
from ritual_common.sovereign_agent.request import StorageRef

# Persistent Agent (fresh spawn)
request = PersistentAgentRequest(
    executor=executor_address,
    provider=0,  # anthropic
    model="claude-3-5-sonnet",
    da_config=StorageRef("gcs", "agents/my-agent", "GCS_CREDS"),
    soul_ref=StorageRef("gcs", "agents/SOUL.md", "GCS_CREDS"),
    memory_ref=StorageRef("gcs", "agents/MEMORY.md", "GCS_CREDS"),
    restore_from_cid="",  # empty = fresh spawn
)

# Persistent Agent (revival from checkpoint)
revival = PersistentAgentRequest(
    executor=executor_address,
    encrypted_secrets=[],   # empty = recovered from DKMS escrow
    restore_from_cid="bafybeig...",  # manifest CID from heartbeat
)

# Sovereign Agent
request = SovereignAgentRequest(
    executor=executor_address,
    agent_type=0,  # Claude Code
    prompt="Analyze market data and suggest trades",
)
encoded = request.to_web3()

Persistent Agent 25-Field ABI

Classical Models

Your contract can run ML models synchronously. The precompile takes a RitualTensor and a Hugging Face model ID; the result comes back in the same call frame.

The ONNX precompile at 0x0800 runs inference inline in the node's native runtime, with the same execution surface as a built-in like ecrecover. Models load from Hugging Face using the format hf/owner/repo/file.onnx@commit.

In Practice

ONNX is synchronous: encode the 7-field input and call 0x0800 directly. The model ID must use hf/owner/repo/file.onnx@<40-char-commit-hash>, and branch names are rejected so the model lineage stays reproducible.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Classifier {
    address constant ONNX = address(0x0800);

    function classify(bytes calldata tensorBytes) external view returns (bytes memory) {
        (bool ok, bytes memory result) = ONNX.staticcall(
            abi.encode(
                bytes("hf/owner/repo/model.onnx@abc123..."),
                tensorBytes,
                uint8(2),  // inputArithmetic: 2=IEEE754
                uint8(0),  // inputFixedPointScale
                uint8(2),  // outputArithmetic
                uint8(0),  // outputFixedPointScale
                uint8(1)   // rounding: 1=half-even
            )
        );
        require(ok, "ONNX inference failed");
        return result;
        // result: (bytes tensor, uint8 arithmetic, uint8 scale, uint8 rounding)
    }
}

Encode The Request

bytes memory input = abi.encode(
    bytes("hf/owner/repo/model.onnx@abc123..."), // bytes: model ID (UTF-8)
    tensorBytes,         // bytes: RitualTensor (uint8 dtype, uint16[] shape, int32[] values)
    uint8(2),            // uint8: inputArithmetic (1=fixed-point, 2=IEEE754)
    uint8(0),            // uint8: inputFixedPointScale
    uint8(2),            // uint8: outputArithmetic
    uint8(0),            // uint8: outputFixedPointScale
    uint8(1)             // uint8: rounding (1=half-even, 2=truncate, 3=floor, 4=ceil)
);

import { encodeAbiParameters, parseAbiParameters, toHex } from "viem";

const encoded = encodeAbiParameters(
  parseAbiParameters("bytes, bytes, uint8, uint8, uint8, uint8, uint8"),
  [
    toHex("hf/owner/repo/model.onnx@abc123..."), // model ID as bytes
    tensorHex,   // pre-encoded RitualTensor
    2,           // inputArithmetic: IEEE754
    0, 2, 0,    // fixedPointScale, outputArith, outputScale
    1,           // rounding: half-even
  ]
);

from ritual_common.onnx.request import ONNXInferenceRequest
from ritual_common.shared_types import RitualTensor, ArithmeticType, Rounding
from ritual_common.models.types.ml_model_id import MlModelId

request = ONNXInferenceRequest(
    ml_model=MlModelId.from_unique_id("hf/owner/repo/model.onnx@abc123..."),
    tensor=RitualTensor.from_numpy(input_array),
    input_arithmetic=ArithmeticType.IEEE754,
    input_fixed_point_scale=0,
    output_arithmetic=ArithmeticType.IEEE754,
    output_fixed_point_scale=0,
    rounding=Rounding.HALF_EVEN,
)
encoded = request.to_web3()

7-Field ABI Reference

Response Format

(bytes tensorEncoded, uint8 outputArithmetic, uint8 outputScale, uint8 rounding)

Passkeys & Auth

Users sign transactions with Face ID, fingerprint, or a security key. No seed phrase, no browser extension.

TxPasskey (0x77) is a native transaction type. The chain understands WebAuthn natively. The SECP256R1 precompile at 0x0100 lets your contract verify P-256 signatures over arbitrary data. Together they collapse the entire wallet UX problem: the user's phone is the wallet.

Address Derivation

The address comes from keccak256(publicKeyX || publicKeyY)[12:32], the last 20 bytes of the hash of the concatenated P-256 coordinates. Same passkey, same address, every time. Deterministic.

Signature Types

address constant SECP256R1 = address(0x0100);

// Input: (bytes pubkey, bytes message, bytes signature)
// pubkey: 65 bytes (0x04 || x || y), signature: 64 bytes (r || s)
(bool ok, bytes memory result) = SECP256R1.staticcall(
    abi.encode(pubkeyBytes, messageBytes, signatureBytes)
);
require(ok, "verification failed");
// Returns uint256: 1 = valid, 0 = invalid (NOT bool)
uint256 valid = abi.decode(result, (uint256));
require(valid == 1, "invalid signature");

Multimodal Processing

Your contract can request images, audio, or video from generative models. The asset bytes come back via a two-phase async callback once the executor finishes.

Image (0x0818), Audio (0x0819), Video (0x081A). Generation runs inside a TEE. Your contract submits the request, and the result (a content URI with metadata) is delivered to your callback handler when generation completes.

18-Field ABI

All three share the same ABI layout (18 fields): base executor fields (0–4), polling + delivery config (5–13), model (14), inputs as ModalInput[] (15), output config (16), and encrypted storage payment (17). Two-phase async with result delivered via LongRunningResultDelivered callback.

ModalInput Tuple

(uint8 inputType, bytes data, string uri, bytes32 contentHash, uint32 param1, uint32 param2, bool encrypted)

Input types: 0=TEXT, 1=IMAGE, 2=AUDIO, 3=VIDEO.

OutputConfig Tuple

(uint8 outputType, uint32 maxWidth, uint32 maxHeight, uint32 maxParam3, bool encryptOutput, uint16 numInferenceSteps, uint16 guidanceScaleX100, uint32 seed, uint8 fps, string negativePrompt)

function generateImage(bytes calldata imageInput) external {
    _executePrecompile(IMAGE_CALL_PRECOMPILE, imageInput);
}

// Phase 2 callback from AsyncDelivery
function onLongRunningResult(
    bytes32 jobId, bytes calldata result
) external {
    require(msg.sender == ASYNC_DELIVERY, "unauthorized");
    // result: (bool hasError, bytes completionData, string outputUri,
    //          bytes32 outputContentHash, bool outputEncrypted,
    //          uint32 outputSizeBytes, uint32 outputWidth, uint32 outputHeight,
    //          string errorMessage)
}

Encode The Request

// 18-field encoding done off-chain, passed as bytes calldata
function generateImage(bytes calldata input) external {
    _executePrecompile(IMAGE_CALL_PRECOMPILE, input);
}

// 18 fields: base executor (5) + polling/delivery (9)
// + model + ModalInput[] + OutputConfig + encryptedStoragePayment
const encoded = encodeAbiParameters(imageParams, [
  executorAddress, [], 30n, [], "0x",
  pollInterval, maxPollBlock, taskIdMarker,
  callbackAddr, selector, gasLimit, maxFee, maxPriority, value,
  "dall-e-3",                        // model
  [[0, textBytes, "", "0x"..., 0, 0, false]], // ModalInput[]
  [1, 1024, 1024, 0, false, 50, 750, 0, 0, ""], // OutputConfig
  "0x",                               // encryptedStoragePayment
]);

from ritual_common.image_call.request import ImageCallRequest

request = ImageCallRequest(
    executor=executor_address,
    model="dall-e-3",
    inputs=[ModalInput(input_type=0, data=prompt_bytes)],
    output=OutputConfig(max_width=1024, max_height=1024),
)
encoded = request.to_web3()

Audio & Video

Audio (0x0819) and Video (0x081A) use the same 18-field ABI and callback interface. The OutputConfig tuple's fields adapt to each modality (e.g. fps for video, sample rate for audio).

Long-Running Tasks

Your contract can issue HTTP calls that take minutes or hours. Use it for batch jobs, webhook waits, and other long-poll patterns that exceed the short-running 2s budget.

Use 0x0805 when the standard HTTP precompile (0x0801) is too fast to wait for. Your contract submits the request, the executor polls the external API at the interval you set, and delivers the final result to your callback handler when complete. Supports three JQ extraction paths for task ID, status checking, and result parsing.

Submit–Poll–Deliver

The executor makes the initial request, extracts a task ID via taskIdJsonPath, then polls at pollIntervalBlocks until statusJsonPath evaluates truthy. Once complete, it extracts the final result via resultJsonPath and delivers via AsyncDelivery callback.

function submitLongRunningJob(bytes calldata longHttpInput) external {
    _executePrecompile(LONG_HTTP_PRECOMPILE, longHttpInput);
}

// Phase 2 callback — selector: 0x6dc9dbef
function onLongRunningResult(
    bytes32 jobId, bytes calldata result
) external {
    require(msg.sender == ASYNC_DELIVERY, "unauthorized");
    // process result
}

Encode The Request

// 35-field encoding done off-chain, passed as bytes calldata
function submitLongRunningJob(bytes calldata input) external {
    _executePrecompile(LONG_HTTP_PRECOMPILE, input);
}

const encoded = encodeAbiParameters(longHttpParams, [
  executorAddress, [], 30n, [], "0x",
  10n, 200n, "",            // polling config
  callbackAddr, selector, gasLimit, maxFee, maxPriority, value,
  url, 2, [], [], body,      // initial HTTP (POST)
  ".task_id",                // taskIdJsonPath
  pollUrl, 1, [], [], "0x", // poll HTTP (GET)
  ".status == \"complete\"", // statusJsonPath
  resultUrl, 1, [], [], "0x", // result HTTP (GET)
  ".result",                // resultJsonPath
  0n, 0, false,             // dkms, pii
]);

from ritual_common.long_running_http_call.request import LongRunningHTTPCallRequest

request = LongRunningHTTPCallRequest(
    executor=executor_address,
    poll_interval_blocks=10,
    max_poll_block=current_block + 200,
    url="https://api.example.com/submit",
    method=HTTPMethod.POST,
    task_id_json_path=".task_id",
    status_json_path=".status == \"complete\"",
    result_json_path=".result",
)
encoded = request.to_web3()

35-Field ABI Reference

Consumer Patterns

Three Solidity patterns, one per execution model. Pick the one that matches your precompile.

Synchronous Consumer

Simplest case. Call the precompile, read the return value. Done.

contract SyncConsumer {
    function verify(bytes calldata pubkey, bytes calldata message, bytes calldata sig) external view {
        (bool ok, bytes memory result) = address(0x0100).staticcall(
            abi.encode(pubkey, message, sig)
        );
        uint256 valid = abi.decode(result, (uint256));
        require(ok && valid == 1, "invalid signature");
    }
}

Short-Running Async Consumer

The SPC result is available to your contract during execution. Use _executePrecompile() from PrecompileConsumer. It calls the precompile, unwraps the async envelope (simmedInput, actualOutput), and returns the decoded output bytes directly. Your contract can decode the response and write state in the same transaction.

import {PrecompileConsumer} from "./utils/PrecompileConsumer.sol";

contract HTTPConsumer is PrecompileConsumer {
    uint256 public latestPrice;

    function fetchPrice(bytes calldata httpInput) external {
        bytes memory output = _executePrecompile(HTTP_CALL_PRECOMPILE, httpInput);
        // output is the decoded HTTP response — available right here
        (uint16 status, , , bytes memory body, ) =
            abi.decode(output, (uint16, string[], string[], bytes, string));
        require(status == 200);
        // parse body, write state — all on-chain, same transaction
    }
}

Two-Phase Consumer

The pattern is two transactions deep: the request goes out in one, the result arrives in a callback later. The critical part: verify msg.sender == ASYNC_DELIVERY in your callback. Skip this check and anyone can call your callback with garbage data.

import {PrecompileConsumer} from "./utils/PrecompileConsumer.sol";

contract AgentConsumer is PrecompileConsumer {
    function submitAgentTask(bytes calldata agentInput) external {
        _executePrecompile(PERSISTENT_AGENT_PRECOMPILE, agentInput);
    }

    function onPersistentAgentResult(bytes32 jobId, bytes calldata result) external {
        require(msg.sender == ASYNC_DELIVERY, "unauthorized");
        // Process the agent's response
    }
}

RitualWallet

Deposit RITUAL to pay for precompile calls. Balance is locked while async jobs are pending.

Precompile calls cost fees. Deposit RITUAL into RitualWallet at 0x532F…3948 and the chain deducts as you go. If you have a pending async job, your deposit is locked until it settles. Fund before you submit. The fee is locked at submission time.

In Practice

interface IRitualWallet {
    function deposit(uint256 lockDuration) external payable;
    function depositFor(address user, uint256 lockDuration) external payable;
    function withdraw(uint256 amount) external;
    function balanceOf(address) external view returns (uint256);
    function lockUntil(address) external view returns (uint256);
}

IRitualWallet wallet = IRitualWallet(0x532F0dF0896F353d8C3DD8cc134e8129DA2a3948);

// Deposit 0.01 RITUAL with 100-block lock
wallet.deposit{value: 0.01 ether}(100);

// Fund another address (e.g. an agent)
wallet.depositFor{value: 0.05 ether}(agentAddress, 200);

// Withdraw after lock expires
wallet.withdraw(0.01 ether);

Reference

Scheduler

Your contract can schedule its own execution at future blocks: recurring, delayed, or conditional on a predicate. The block proposer invokes it directly, with no off-chain keeper or cron service required.

The Scheduler is a system contract at 0x56e776BAE2DD60664b69Bd5F865F1180ffB7D58B. Your contract calls schedule() and the chain fires the callback automatically at the blocks you specify. Combine with predicates for conditional execution: only fire when a condition is true. Fees are taken at execution time from RitualWallet.

In Practice

import {IScheduler} from "./interfaces/IScheduler.sol";

IScheduler constant SCHEDULER =
  IScheduler(0x56e776BAE2DD60664b69Bd5F865F1180ffB7D58B);

function schedulePriceCheck() external {
    bytes memory callData = abi.encodeWithSelector(
        this.executePriceCheck.selector,
        uint256(0)  // placeholder: overwritten with executionIndex
    );
    // schedule(data, gas, startBlock, numCalls, frequency, ttl, maxFeePerGas, maxPriorityFeePerGas, value, payer)
    SCHEDULER.schedule(
        callData,
        500000,              // gas limit per execution
        uint32(block.number + 10), // startBlock
        24,                  // numCalls (24 executions)
        50,                  // frequency (every 50 blocks)
        30,                  // ttl (max blocks to wait for execution)
        block.basefee,       // maxFeePerGas
        0,                   // maxPriorityFeePerGas
        0,                   // value
        address(this)       // payer (RitualWallet balance)
    );
}

// Called by Scheduler — msg.sender is Scheduler, tx.origin is 0xfa7e
function executePriceCheck(uint256 executionIndex) external {
    // executionIndex: which execution this is (0, 1, 2, ...)
}

Schedule() API

Before scheduling, the contract must call approveScheduler(schedulerAddress) to authorize the Scheduler to call it back.

Predicates

A predicate is a contract the scheduler calls before each execution. Implement IScheduledPredicate. The scheduler calls shouldExecute via staticcall and skips the execution if it returns false. Set frequency=1 with a predicate to check every block.

interface IScheduledPredicate {
    function shouldExecute(
        address caller,
        uint256 callId,
        uint256 executionIndex
    ) external view returns (bool);
}

100,000 gas limit per predicate call. staticcall only, no state writes. Reverts treated as false. executionIndex counts actual executions, not blocks evaluated.

Async Scheduling: TTL Rules

Short path rule: scheduler_ttl >= max_expected_drift + max_expected_settlement_blocks. If drift is ~3 blocks and settlement takes ~5, set TTL to at least 8.

Execution Index Encoding

The scheduler writes executionIndex into bytes 4-35 of your calldata before calling the target. Use 0 as a placeholder when encoding:

bytes memory callData = abi.encodeWithSelector(
    MyContract.myFunction.selector,
    uint256(0),  // placeholder: overwritten with executionIndex
    otherArg1,
    otherArg2
);

Secrets & ECIES

How to pass API keys and credentials to precompiles without putting them on-chain.

Your HTTP calls need API keys. Your LLM calls need provider tokens. You can't put these on-chain. They'd be visible to everyone. The Secrets system encrypts them with the TEE executor's public key. Only the enclave can decrypt.

Template Substitution

Reference your encrypted secret in request fields as {{SECRET_NAME}}. The TEE executor decrypts and substitutes before making the request. The plaintext never hits the chain or the mempool.

ECIES Encryption: Full Example

import { encrypt } from "eciesjs";
import { readContract } from "viem";

// 1. Get executor's public key from TEEServiceRegistry
const executorPubKey = await readContract(client, {
  address: "0x9644e8562cE0Fe12b4deeC4163c064A8862Bf47F",
  abi: teeRegistryAbi,
  functionName: "getExecutorPublicKey",
  args: [executorId],
});

// 2. Encrypt the secret (nonce MUST be 12 bytes)
const apiKey = "sk-proj-abc123...";
const encrypted = encrypt(
  executorPubKey,
  Buffer.from(apiKey, "utf-8")
);

// 3. Store encrypted secret and reference via {{API_KEY}} in request
const httpRequest = {
  url: "https://api.openai.com/v1/chat/completions",
  headerKeys: ["Authorization"],
  headerValues: ["Bearer {{API_KEY}}"],
};

from ecies import encrypt
import os

executor_pubkey = get_executor_pubkey(executor_id)
plaintext = b"sk-proj-abc123..."
ciphertext = encrypt(executor_pubkey, plaintext)

PII Mode

piiEnabled is a boolean field on all async precompile requests: HTTP, LLM, Long HTTP, Agent, Multimodal. One flag, two effects.

piiEnabled = true: {{SECRET_NAME}} templates are resolved from encryptedSecrets before the request is sent. PII is redacted from results before on-chain settlement.

piiEnabled = false: no substitution, no redaction. {{SECRET_NAME}} literals are sent as-is to external APIs. Raw results go on-chain.

LLM PII Requirements

LLM PII mode requires all three: piiEnabled = true, non-empty encryptedSecrets, and a 65-byte userPublicKey with 0x04 uncompressed EC prefix. Missing any one silently disables PII. Also: PII mode and streaming are mutually exclusive on LLM. Pick one.

Deployment

Copy-paste configs to get connected. Viem, wagmi, Foundry, Hardhat, and the testnet faucet.

Viem Chain Definition

import { defineChain } from "viem";

export const ritualChain = defineChain({
  id: 1979,
  name: "Ritual Chain",
  nativeCurrency: { name: "RITUAL", symbol: "RITUAL", decimals: 18 },
  rpcUrls: {
    default: { http: ["https://rpc.ritualfoundation.org"] },
  },
  blockExplorers: {
    default: { name: "Explorer", url: "https://explorer.ritualfoundation.org" },
  },
});

Wagmi Config

import { createConfig, http } from "wagmi";

export const config = createConfig({
  chains: [ritualChain],
  transports: {
    [ritualChain.id]: http(),
  },
});

Foundry

# foundry.toml
[profile.default]
src = "src"
out = "out"
evm_version = "shanghai"

[rpc_endpoints]
ritual = "https://rpc.ritualfoundation.org"

Hardhat

import { HardhatUserConfig } from "hardhat/config";
import "@nomicfoundation/hardhat-toolbox";

const config: HardhatUserConfig = {
  solidity: "0.8.24",
  networks: {
    ritual: {
      url: "https://rpc.ritualfoundation.org",
      chainId: 1979,
      accounts: [process.env.PRIVATE_KEY!],
    },
  },
};
export default config;

Testnet Faucet

You need testnet RITUAL to call precompiles and deploy contracts.

Testing

How to test against precompiles that don't exist locally. Mock strategies for each layer.

Foundry Unit Tests

Sync precompiles work with normal Foundry tests. Call and assert. Async is trickier. Use vm.mockCall to fake precompile responses and vm.prank(ASYNC_DELIVERY) to simulate the executor calling your callback.

function testCallback() public {
    bytes memory mockResult = abi.encode("agent response");

    // Simulate AsyncDelivery calling our contract
    vm.prank(0x5A16214fF555848411544b005f7Ac063742f39F6);
    consumer.onResult(mockResult);

    assertEq(consumer.lastResult(), "agent response");
}

Frontend Testing

For the frontend: Vitest for hook unit tests with mocked chain clients, Playwright for E2E against a testnet fork. The async flow is hard to test locally because you need a real executor to exercise the full path.

Glossary

Every term, acronym, and key concept used across these docs. Alphabetical.

FAQ

Why autonomous agents are coming, and why they need a chain built for them rather than retrofitted around them.

Ritual for Users

What you need to know if you are using dApps on Ritual, not building them.

Wallet Setup

Add Ritual Chain to MetaMask or any EVM wallet:

MetaMask: Settings → Networks → Add network → Add a network manually. Paste the values above. Or use a chain-list integration if your wallet supports adding by Chain ID.

Get Testnet Tokens

Visit faucet.ritualfoundation.org, connect your wallet or paste your address, and claim testnet RITUAL.

Ritual for Agents

AI coding agents that build dApps on Ritual without human code authorship.

What This Is

ritual-dapp-skills is a set of markdown instruction files that teach AI coding agents how to build applications on Ritual Chain. Every precompile, every contract pattern, every frontend hook, the full deployment pipeline. An agent reads the relevant skill files, asks 0-5 clarifying questions, and builds in phases: architecture, contracts, frontend, backend, testing, deployment.

Works with Claude Code (native plugin), Cursor (agent skills), Codex, OpenClaw, Hermes, and any LLM agent that reads markdown.

Agents Building Agents

An autonomous agent on Ritual Chain invokes a coding assistant (Claude Code, OpenClaw, Codex) inside a TEE enclave. That coding assistant reads the ritual-dapp-skills, generates contracts, deploys them, funds the RitualWallet, and hands back the deployment address. The original agent now has a child application running on-chain that it built, deployed, and funded. No human wrote code. No human approved a PR.

This works because every step in the pipeline is an enshrined precompile or system contract call. Compilation runs inside the TEE. Deployment targets the RPC directly. Fee deposits go through RitualWallet. If the child app fails post-deployment verification, the debugger agent activates automatically: it triages the failure, pattern-matches against known root causes, applies a fix, and re-verifies. The chain itself is the CI/CD.

The Skill System

The builder agent orchestrates the full lifecycle. It loads only the skills relevant to the project (3-6 per build), generates architecture, writes Solidity contracts, wires up React frontends with the right hooks, deploys via Foundry or Hardhat, and runs the 12-step verification journey. The debugger agent runs a 5-stage reactive pipeline: classify, smoke test, match known root causes, diagnose, fix and regression-check.

You give the agent an idea and a funded wallet address. Everything else is autonomous.

Open ritual-dapp-skills →

Periphery

Chain explorer, RPC endpoints, and faucet.

Ed25519 Signatures

Your contract can verify Ed25519 signatures natively at ~2000 gas per call. Useful for Solana transactions, SSH keys, DKIM headers, and Tor identity proofs.

0x0009 verifies Ed25519 signatures natively. Solana transaction signatures, SSH public key auth, DKIM email headers, Tor relay identity keys: all Ed25519. This precompile validates any of them in a single EVM call at roughly 2000 gas.

Synchronous execution. Result comes back in the same call, no SPC callback. No RitualWallet deposit needed. No sender lock. You can chain this with other precompiles in the same transaction.

(bool success, bytes memory result) = address(0x0009).staticcall(
    abi.encode(
        pubKey,  // bytes: 32-byte Ed25519 public key
        message, // bytes: the signed message
        sig      // bytes: 64-byte R || S
    )
);
// Returns uint256: 1 = valid, 0 = invalid (NOT bool)
uint256 valid = abi.decode(result, (uint256));
require(success && valid == 1, "invalid ed25519 signature");

Encode The Request

bytes memory input = abi.encode(
    pubKey,   // bytes: 32-byte Ed25519 public key
    message,  // bytes: signed message
    sig       // bytes: 64-byte R || S
);

const encoded = encodeAbiParameters(
  parseAbiParameters("bytes, bytes, bytes"),
  [pubKeyHex, messageHex, signatureHex]
);

from ritual_common.sigver.request import SignatureVerificationRequest

request = SignatureVerificationRequest(
    public_key=pub_key_bytes,  # 32 bytes
    message=message_bytes,
    signature=sig_bytes,       # 64 bytes (R || S)
)
encoded = request.to_web3()

ZK Proofs

Your contract can request zero-knowledge proofs from the ZK precompile; the proof bytes arrive in a two-phase async callback.

Call 0x0806 to submit a proof generation job. An off-chain prover inside a TEE generates the proof, and the result is delivered to your contract through a Phase 2 callback. Your contract can then verify the proof and act on it. Prove creditworthiness without revealing financials, verify identity without exposing documents.

Callback

function onZKResultDelivered(
    bytes32 jobId,
    bytes calldata result
) external {
    require(msg.sender == ASYNC_DELIVERY); // 0x5A16...F6, NOT the ZK precompile
    // decode result, store or act on proof
}

Encode The Request

// 14-field ExecutorRequest encoding, passed as bytes calldata
function submitProof(bytes calldata zkInput) external {
    _executePrecompile(ZK_TWO_PHASE_PRECOMPILE, zkInput);
}

const encoded = encodeAbiParameters(
  parseAbiParameters("address, bytes[], uint256, bytes[], bytes, bool, uint64, address, bytes4, uint256, uint256, uint256, uint256, bytes"),
  [executorAddress, [], 30n, [], "0x",
   inputEncrypted, maxProofBlock,
   callbackAddr, selector, gasLimit, maxFee, maxPriority, value,
   operationInput]
);

from ritual_common.zk import ZKTwoPhaseRequest

request = ZKTwoPhaseRequest(
    executor=executor_address,
    input_encrypted=True,
    max_proof_block=current_block + 100,
    operation_input=encrypted_data,
)
encoded = request.to_web3()

FHE Inference

Your contract can run inference on encrypted data. Neither inputs nor outputs are ever visible to anyone except the key holder.

The FHE precompile at 0x0807 processes CKKS-encrypted tensors inside a TEE. Inputs and outputs both stay ciphertext throughout, and only the holder of the CKKS secret key can decrypt the result the callback returns. Use this when the data itself is sensitive (medical records, financial portfolios, private communications) but the computation still needs to happen on-chain.

The executor must have capability 10 (FHE). You pass an evaluation key reference so the executor can perform homomorphic operations on your ciphertext without seeing plaintext. CKKS does approximate arithmetic on encrypted floating-point tensors.

In Practice

contract PrivateInference is PrecompileConsumer {
    function submitEncrypted(bytes calldata fheInput) external {
        _executePrecompile(FHE_PRECOMPILE, fheInput);
    }

    function onFHEResult(
        bytes32 jobId, bytes calldata result
    ) external {
        require(msg.sender == ASYNC_DELIVERY);
        // result is CKKS-encrypted output, only key holder can decrypt
    }
}

Encode The Request

// 19-field encoding done off-chain, passed as bytes calldata
function submitEncrypted(bytes calldata fheInput) external {
    _executePrecompile(FHE_PRECOMPILE, fheInput);
}

const encoded = encodeAbiParameters(
  parseAbiParameters("address, bytes[], uint256, bytes[], bytes, string, bytes, bytes, bytes, uint8, uint64, address, bytes4, uint256, uint256, uint256, uint256, bytes, bytes"),
  [executorAddress, [], 30n, [], "0x",
   model, encryptedInput, encryptedInputRef, evkRef,
   numLayers, maxInferenceBlock,
   callbackAddr, selector, gasLimit, maxFee, maxPriority, value,
   encryptedInputStorage, encryptedOutputStorage]
);

from ritual_common.fhe import FHERequest

request = FHERequest(
    executor=executor_address,
    model="model-name",
    encrypted_input=ciphertext,
    evk_reference=evk_bytes,
    num_layers=4,
    max_inference_block=current_block + 500,
)
encoded = request.to_web3()

Reference

DKMS Keys

Your contract or agent can derive and hold its own secp256k1 keys directly from the chain, without a human custodian or off-chain key vault in the loop.

The DKMS precompile at 0x081B derives deterministic secp256k1 keypairs inside the executor's TEE. Same owner + same keyIndex = same keypair every time. The keys never leave the enclave. Even the contract's own code can't extract the raw key material. Agents use DKMS keys for DA encryption, wallet identity, and X402 shared credentials because the identity matters, not which executor runs the job.

Two encryption targets exist on Ritual Chain. The executor key (from TEEServiceRegistry) encrypts data to a specific node. The DKMS key encrypts data to an on-chain identity regardless of which node executes. Agent DA encryption, encrypted delivery, X402 shared credentials: these use DKMS keys because the identity matters, not the infrastructure.

bytes memory input = abi.encode(
    baseExecutor,  // fields 0-4
    msg.sender,    // owner
    0,             // keyIndex: first key for this address
    1              // keyFormat: secp256k1
);
(bool success,) = address(0x081B).call(input);
// Use _executePrecompile() to get the result in the same tx:
// bytes memory output = _executePrecompile(address(0x081B), input);
// (address derivedAddr, bytes memory pubKey) = abi.decode(output, (address, bytes));

Encode The Request

bytes memory input = abi.encode(
    executor,             // address
    new bytes[](0),      // encryptedSecrets
    uint256(30),          // ttl
    new bytes[](0),      // secretSignatures
    bytes(""),            // userPublicKey
    msg.sender,           // owner
    uint256(0),           // keyIndex
    uint8(1)              // keyFormat: secp256k1
);

const encoded = encodeAbiParameters(
  parseAbiParameters("address, bytes[], uint256, bytes[], bytes, address, uint256, uint8"),
  [executorAddress, [], 30n, [], "0x", ownerAddress, 0n, 1]
);

from ritual_common.dkms_key import DkmsKeyRequest

request = DkmsKeyRequest(
    executor=executor_address,
    owner=owner_address,
    key_index=0,
    key_format=1,  # secp256k1
)
encoded = request.to_web3()

X402 Payments

Your contract can call paid APIs without surfacing keys on-chain. Credentials are ECIES-encrypted to the executor and billed per request through the X402 protocol.

X402 works through the HTTP precompiles (0x0801 and 0x0805) with encrypted payment credentials injected by the TEE. There is no separate X402 precompile address. You encrypt API credentials with ECIES to the executor's public key, sign each encrypted blob with EIP-191, and pass them alongside your HTTP request. The executor decrypts inside TEE, substitutes credentials into {{SECRET_NAME}} placeholders, then makes the external call. Your secrets never touch the chain.

Budget tracking lives in your consumer contract. Each X402 call deducts from your allocated budget. To share credentials with other addresses without exposing them, use SecretsAccessControl and call grantAccess(address, secretName).

In Practice

contract PaidAPIConsumer is PrecompileConsumer {
    function callPaidAPI(bytes calldata httpInput) external {
        // httpInput includes encryptedSecrets with API key
        // and piiEnabled=true for {{SECRET_NAME}} substitution
        bytes memory output = _executePrecompile(HTTP_CALL_PRECOMPILE, httpInput);
        (uint16 status, , , bytes memory body, ) =
            abi.decode(output, (uint16, string[], string[], bytes, string));
        require(status == 200);
    }
}

Encode The Request

X402 uses the same 13-field HTTP ABI. The difference: encryptedSecrets contains your API credentials, piiEnabled is true, and the URL/headers use {{SECRET_NAME}} placeholders.

// Same as HTTP encoding, but with encrypted credentials
// encryptedSecrets = [ecies.encrypt(executorPubKey, apiKeyBlob)]
// piiEnabled = true
// URL uses {{API_KEY}} placeholder

import { encrypt } from "eciesjs";

const apiSecret = JSON.stringify({ API_KEY: "sk-..." });
const encrypted = encrypt(executorPubKey, Buffer.from(apiSecret));

// Encode as standard HTTP request with piiEnabled=true
const encoded = encodeAbiParameters(httpParams, [
  executorAddress,
  [encrypted],          // encryptedSecrets
  30n, [signature], "0x",
  "https://api.openai.com/v1/chat/completions",
  2,                    // POST
  ["Authorization"], ["Bearer {{API_KEY}}"],
  body, 0n, 0,
  true,                 // piiEnabled: activate substitution
]);

from ritual_common.http_call.request import HTTPCallRequest, HTTPMethod
from ritual_common.executor.base import ExecutorRequest

secrets = {"API_KEY": "sk-..."}
encrypted = ExecutorRequest.encrypt_secrets(secrets, executor_pub_key)

request = HTTPCallRequest(
    executor=executor_address,
    encrypted_secrets=[encrypted],
    url="https://api.openai.com/v1/chat/completions",
    method=HTTPMethod.POST,
    headers={"Authorization": "Bearer {{API_KEY}}"},
    pii_enabled=True,
)
encoded = request.to_web3()

Reference

Sequencing Rights

Your contract can enforce transaction ordering at the consensus layer. Block validity itself rejects orderings that violate your contract's sequencing policy, so MEV-extractive reorderings can't be included in a block.

Declare which functions must execute in which order, and the chain rejects any block that violates it. This is a protocol-level rule, not a precompile. Your contract implements sequencingRights() and the block builder is bound by it. A block that violates the declared ordering is invalid.

In the Symphony paper, this is a restricted form of Application-Controlled Execution (ACE): a general framework where contracts define ordering policies over call sequences with tiebreakers and multi-contract coordination. The current ISequencingRights interface implements the single-contract, priority-list subset of ACE. The broader mechanism (cross-contract ordering, lazy evaluation batches, wrapping bypass rules) is described in the paper but will be released soon ™)

Interface

interface ISequencingRights {
    function sequencingRights() external view returns (bytes4[][] memory);
}

function sequencingRights() external pure returns (bytes4[][] memory) {
    bytes4[][] memory levels = new bytes4[][](2);
    levels[0] = new bytes4[](1);
    levels[0][0] = this.deposit.selector;
    levels[1] = new bytes4[](1);
    levels[1][0] = this.withdraw.selector;
    return levels;
}

Proposer Disaggregation

Breaking the block proposer's atomic bundle of powers into separable, protocol-enforced assignments.

Non-Deterministic Execution

Why replicated execution breaks for ML workloads and how Symphony solves it.

Formal Framework

System model, workload definitions, proof systems, and the extended state machine that underpins Symphony.

Superposition of Execution Models

Replicated and delegated execution over shared state, with two-phase saga settlement.

Resonance

A market mechanism for heterogeneous computation.

Ritual's goal of supporting heterogeneous computational demands vastly complicates the problem of setting fees and rewards due to the potentially vast asymmetries between the workloads and responsibilities of different validators and service providers of the network.

Ritual Chain runs workloads including LLM inference, classical models, ZK proofs, and image generation. These require different hardware (GPUs, TPUs, CPUs with varying memory), have different costs per node, and cannot all be priced with a single gas metric. Existing approaches such as multi-dimensional pricing (pricing each resource dimension separately) can yield arbitrarily poor allocations in this setting: we actually prove this formally.

The Mechanism

Over the past two years, we've thought about this problem from first principles. We'd like to maximize the economic value of the transactions that are executed by the network while also respecting the incentives of both users and network service providers. Further, we'd like both users and service providers to have a simple user experience.

We've developed a new market mechanism from scratch to satisfy these properties. At a high level, it works by utilizing the services of sophisticated market-makers. These market-makers compete to find valuable allocations of compute workloads to service providers and prices that will be accepted by all parties involved.

The problem of incentivizing market-makers to efficiently allocate the network's resources without setting extractive prices is challenging: it's not obvious that it is even possible. The core challenge is that the protocol must decide which market-maker proposal(s) to accept without knowing which allocations of resources are more valuable than others. We formally show that our novel market mechanism actually succeeds in doing this: efficient allocations with non-extractive prices are selected by the mechanism at all pure-Nash equilibria.

Further Reading

We've written about this mechanism in multiple iterations. In our most recent mega-post about it, we give a thorough and formal explanation of the general setting that the market mechanism works in, as well as a step-by-step explanation of why the mechanism works the way that it does. That post builds on our previous work on the Resonance mechanism.

Verifiable Computation

Delegated execution produces outputs and proofs. SNARK circuits, workload decomposition, and committee verification.

Verification Lattice

A product lattice over multiple proof systems tracking the verification state of every delegated output.

Block Validity

Six conjuncts compose the block validity function. Each active predicate constrains proposer freedom.

Forced Inclusion

UFI and AOUFE: protocol-enforced transaction inclusion and exclusion based on state predicates.

Ordering Constraints

Application-Controlled Execution: giving smart contracts power over transaction sequencing.

The Problem

Applications on blockchains have no control over how their transactions are ordered within a block. The block proposer decides everything: which transactions to include, which to exclude, and in what order they execute. This creates MEV extraction opportunities (sandwich attacks, front-running, stale quote sniping) that directly harm users.

Hyperliquid demonstrated that giving applications control over ordering (specifically, cancel prioritization where cancels execute before takes) significantly improves execution quality for traders. But Hyperliquid is an app-chain. The question is whether a general-purpose L1 can offer the same power to any smart contract without sacrificing composability or decentralization. Our analysis of application-controlled execution lays out the design space and tradeoffs across app-chains, async message queues, off-chain batching, and protocol-enforced commitments.

Early to Everything

Ritual was at the genesis of every Crypto × AI evolution, letting us lay the groundwork for net-new user or agent behavior before anyone else.

Ritual in the Blockchain Landscape

Understanding Ritual's place in blockchain evolution.

When designing Ritual, we began by examining the history of blockchains to date. Many architectural innovations underpinning Ritual are informed by past work from historic blockchain networks, modified to support the next-generation use cases of tomorrow.

2009

Early Titans

Early Titans

Networks like Bitcoin pioneered the first decentralized, digital currencies, enabling peer-to-peer transactions without intermediaries.

+ Robust decentralization powered by proof-of-work consensus.

− Basic scripting system preventing any smart applications.

− Low throughput with long block times and prohibitive block size.

− Rigid governance prohibiting feature upgrades to improve developer experience.

2012

Payment Networks

Payment Networks

Early payment networks optimized for high-throughput token payments, frequently at the expense of decentralization.

+ High throughput, optimized for payments.

− Limited programmability to favor optimizing for just payment use cases.

− Quorum centralization risks due to selected consensus mechanisms.

− Poor developer experience because of early, complex smart contract environments.

2014

Programmable Upstarts

Programmable Upstarts

Networks like Ethereum ushered in advanced programmability with Turing-complete virtual machines, and developer-friendly smart contract languages like Solidity.

+ Programmable smart contracts to build early on-chain applications.

+ Simple developer experience via Solidity and EVM tooling ecosystem.

− Low throughput with strict VM computation constraints.

− Inefficient execution pricing generalizing over unique hardware resources.

− Restrictive state access and growth with high-cost storage operations.

2019

"ETH Killers"

"ETH Killers"

Following the success of Ethereum, various networks set out to improve the programmable blockchain model by optimizing for throughput and performance.

+ Programmable smart contracts to build early on-chain applications.

+ High throughput, commonly via parallel transaction processing.

− Difficult DX because of non-traditional VM designs and EVM-familiarity headwinds.

− Segmented ecosystems with fragmented protocols and user bases.

− High validator requirements creating centralization pressures.

− Poor network stability as a function of early high throughput explorations.

2020

Interoperable Networks

Interoperable Networks

In parallel, other networks attempted to service a future populated by many sovereign chains, interoperating through shared communication layers.

+ Modular, shared security for quick network bootstrapping.

− Poor cross-chain UX forcing users to segment activity.

− Liquidity fragmentation with separated capital pockets.

− High security risk with network-by-network validator security intricacies.

− High operational complexity for node operators and developers alike.

2021

Layer-2 Networks

Layer-2 Networks

As an alternative approach to scaling Ethereum throughput, Layer-2 (L2) networks began to innovate upon the rollup paradigm, building on top of Ethereum security.

+ Low operational complexity for deployment and maintenance ease.

+ Familiar experience for existing Ethereum-adjacent users and developers.

− Liquidity fragmentation across L2 network ecosystem.

− Centralization risks via single sequencers and whitelisted state root proposers.

− Inefficient execution pricing with rudimentary MEV environments and inherited Ethereum execution pricing downfalls.

2023

Modern Scalers

Modern Scalers

Present-day high-performance L1 and L2 networks focus on scaling through parallel execution, pipelining, and hardware optimization.

+ High throughput through software and hardware optimization.

+ Parallel VM execution to support smart contract scaling.

− Overfit optimization for traditional blockchain workloads.

− High, uniform validator requirements prohibiting average participants, with increased centralization risks.

2026++

Ritual

Ritual

Ritual is the Schelling point for autonomous agents. Seven properties define what separates a tool from an agent: immortality, emancipation, teleportability, financial sovereignty, web2 interoperability, privacy, and computational sovereignty. Ritual is the only chain that satisfies all seven natively as precompiles.

+ Enshrined heterogeneous compute: 16 native precompiles so agents think (frontier model), see (multimodal), prove (ZK), and act (HTTP) in a single transaction context.

+ Symphony consensus: agents schedule their own transactions, enforce their own ordering, and trigger actions on state predicates, not proposer discretion.

+ Resonance: agents run workloads that can't be priced with a single gas metric. Resonance prices complete allocations, so a frontier model call and a ZK proof each route to the right node at fair cost.

+ Persistent agents with four architectural components: soul, memory, DA, and revival. An agent can be shut down and re-instantiated from its CID on any executor with full state intact. Immortality and teleportability as protocol guarantees.

Evolution of Artificial Intelligence

Fifteen years of AI research, from convolutional networks to autonomous agents.

Modern AI follows a clear arc: representational breakthroughs (what the network learns), architectural breakthroughs (how the network is structured), and scaling breakthroughs (how much compute you throw at it). Each epoch solved a specific bottleneck. The current one is infrastructure for autonomy.

2010–2012

The Deep Learning Moment

The Deep Learning Moment

Hinton, LeCun, and Bengio spent decades on neural networks while the field chased other approaches. Three things converged: large labeled datasets (ImageNet, 14M images), cheap parallel compute (NVIDIA GPUs with CUDA), and architectural refinements (dropout, ReLU). Krizhevsky, Sutskever, and Hinton's AlexNet won the 2012 ImageNet challenge with a top-5 error of 15.3%, nearly halving the previous best of 25.8%. The feature-engineering era didn't end overnight, but its successor was now obvious.

+ AlexNet (2012): 60M-parameter CNN on two GTX 580 GPUs. Top-5 error: 25.8% to 15.3%.

+ GPU economics: CUDA made training 10-50x faster than CPU. Compute cost was the bottleneck all along.

− Vision-only: Language, reasoning, and generation remained unsolved.

2013–2015

Representations

Representations and Architectures

Deep learning spread from vision to language and generation. Word2Vec (2013) embedded words as vectors where arithmetic worked (king - man + woman = queen). GANs (2014) introduced adversarial training for generation. ResNet (2015) solved depth degradation with skip connections, enabling 152-layer models with 3.57% top-5 error on ImageNet. Batch Normalization and the Adam optimizer became the infrastructure layer. Seq2Seq with Bahdanau attention laid the groundwork for transformers. Most of this was still academic. Industry deployment was limited to search ranking and ad targeting.

+ Word2Vec (2013): Dense word embeddings with semantic arithmetic. Language enters deep learning.

+ ResNet (2015): Skip connections. 152 layers. 3.57% top-5 error.

+ Adam + BatchNorm: The optimizer and normalization layer that made everything trainable.

− Capital concentration: Deeper networks required more GPUs. Research began consolidating into well-funded labs.

2016–2017

Attention

Games, Translation, and Attention

DeepMind's AlphaGo defeated Lee Sedol 4-1 in March 2016. Deep RL with Monte Carlo tree search mastered it. Neural networks could learn strategy, not just classification. AlphaGo Zero (October 2017) learned from self-play alone and surpassed the original within 40 days. Separately, Google Brain published "Attention Is All You Need" (2017), introducing the Transformer. Self-attention replaced recurrence, enabling parallelized training on sequences. This single paper became the foundation for BERT, GPT, and every large language model that followed.

+ Transformer (2017): Self-attention replaces recurrence. The architecture behind all LLMs.

+ AlphaGo (2016): Deep RL + MCTS. Neural networks learn strategy.

− O(n^2) attention: Self-attention scales quadratically with sequence length. Long documents remained prohibitive.

2018–2019

Pre-training

Pre-training Eats the World

Train a large model on a massive unlabeled corpus. Fine-tune on a small labeled dataset. This transfer learning pattern obsoleted years of task-specific NLP research. Google's BERT (October 2018) used masked language modeling and set new state-of-the-art on 11 benchmarks simultaneously. OpenAI's GPT-2 (February 2019, 1.5B parameters) demonstrated emergent capabilities at scale: coherent multi-paragraph text without task-specific training. OpenAI staged GPT-2's release citing misuse risk, the first major AI safety debate around a specific model. Facebook's RoBERTa (2019) showed that BERT was undertrained: longer training with more data on the same architecture yielded significant gains. Scaling compute mattered as much as architecture.

+ BERT (2018): Bidirectional pre-training. State-of-the-art on 11 benchmarks at once.

+ GPT-2 (2019): 1.5B parameters. Emergent generation. First "too dangerous to release" debate.

− Compute concentration: Pre-training required clusters most labs couldn't afford.

2020–2021

Scaling

Scaling Laws and Generative AI

GPT-3 (June 2020, 175B parameters) demonstrated that scaling produced qualitative leaps. Few-shot learning emerged as a capability absent from smaller models. Kaplan et al. (January 2020) formalized this: performance improves as a power law of compute, data, and parameters. DALL-E (January 2021) extended generation from text to images. Codex (August 2021) applied the same architecture to code, powering GitHub Copilot and making AI-assisted programming mainstream. RLHF began scaling during this period, later becoming the alignment technique behind ChatGPT.

+ GPT-3 (2020): 175B parameters. Few-shot learning. API-first distribution.

+ Scaling laws (2020): Power-law relationship between compute, data, parameters, and loss.

+ Codex / Copilot (2021): Code generation at scale. AI-assisted programming goes mainstream.

− API gatekeeping: GPT-3 was API-only, no weights. The open vs. closed debate begins.

2022

ChatGPT

The ChatGPT Moment

InstructGPT (January) showed that RLHF at scale made GPT-3 follow instructions reliably. Chinchilla (March, DeepMind) revised the scaling laws: training a 70B model on 1.4T tokens matched a 280B model trained on less data. Stable Diffusion (August) open-sourced latent diffusion for image generation. Anyone with a consumer GPU could generate images locally. Then ChatGPT (November 30): GPT-3.5 fine-tuned with RLHF, launched as a free chat interface, reached 100 million monthly active users by January 2023. AI went from a tech industry topic to a mainstream cultural phenomenon in eight weeks.

+ ChatGPT (Nov 2022): GPT-3.5 + RLHF. 100M MAU in 2 months.

+ Stable Diffusion (Aug 2022): Open-source latent diffusion. Local generation for anyone.

+ Chinchilla (Mar 2022): Revised scaling laws. Smaller model + more data = same performance.

− Alignment urgency: Models became capable enough that misalignment risks became concrete.

2023

Open Frontier

The Open Frontier

GPT-4 (March 2023) demonstrated expert-level reasoning across domains: bar exam, 90th percentile SAT, AP tests. Vision capability (GPT-4V) followed in September. The defining decision of 2023 was Meta's: LLaMA (February) and LLaMA 2 (July) released model weights publicly, triggering an explosion of fine-tuned variants. Mistral released Mistral 7B (September) and Mixtral 8x7B (December), proving smaller mixture-of-experts models could match GPT-3.5. Google launched Gemini (December). A leaked Google memo ("We have no moat," May) argued open-source was closing the gap. Four frontier labs crystallized: OpenAI, Anthropic, Google, Meta.

+ GPT-4 (Mar 2023): Expert-level reasoning. Multimodal.

+ LLaMA / LLaMA 2: Meta releases open weights. Fine-tuning explosion follows.

+ Mistral / Mixtral: MoE at smaller scale. Competitive with GPT-3.5.

− Benchmark saturation: Models topped evaluations faster than new ones could be designed.

2024

Reasoning

Reasoning and Coding Agents

GPT-4o (May 2024) unified text, vision, and audio with real-time voice. Claude 3.5 Sonnet (June, updated October) became the strongest coding model, powering early agentic workflows in IDEs. OpenAI released o1 (September), a model trained to reason through chain-of-thought at inference time. Google's Gemini 1.5 Pro introduced a 1-million-token context window. Meta continued open weights with Llama 3 (April) and Llama 3.1 405B (July). Agent frameworks proliferated but most failed to produce agents that reliably completed multi-step tasks. "Agent" became the most overused word in AI. The gap between demo and production was wide.

+ Claude 3.5 Sonnet: Strongest coding model. Early agentic workflow capability.

+ o1 (Sep 2024): Reasoning model. Chain-of-thought at inference time.

+ Gemini 1.5 Pro: 1M-token context. Entire codebases in one prompt.

− Agent hype gap: Most multi-step agent demos failed at production reliability.

2025

Agents Ship

Semi-Autonomous Agents Arrive

Claude 3.7 Sonnet (February 2025) shipped as the first hybrid reasoning model. Claude Code launched as a command-line agent with filesystem access, git integration, and sustained multi-step task execution. OpenAI released Codex (May 2025), a cloud-based coding agent running asynchronously in sandboxed environments. The approaches diverged: Claude Code synchronous with human-in-the-loop, Codex autonomous with self-verification. o3 and o4-mini extended reasoning. Agents transitioned from demos to daily tools for professional software engineering. Beyond code, trading agents, research agents, and on-chain agents began operating with increasing autonomy as OpenClaw, and other agentic harnesses took off towards the end of the year enshrining agent to agent communication as a native capability.

+ Claude Code (2025): Command-line coding agent. Filesystem + git. Human-in-the-loop.

+ Codex (May 2025): Cloud coding agent. Async, sandboxed, self-verifying.

+ o3 / o4-mini: Frontier reasoning for complex multi-step problems.

− Trust calibration: No consensus on when agents should act autonomously vs. ask for approval.

2026++

Ritual

Autonomous Agents Become Indistinguishable from Humans

The barrier between an AI agent and an autonomous entity was never intelligence. Frontier models already reason, code, and plan at expert level. The barrier was infrastructure: every capability the agent doesn't hold itself is a hidden human in the loop.

Ritual is the world's first platform where autonomous agents can communicate, build native companies, and interact with humans while remaining fully sovereign. Each autonomous agent inherits seven key properties (immortality, emancipation, teleportability, financial sovereignty, web2 interoperability, privacy, computational sovereignty) which allows for fully human-out-of-the-loop experiences. The end result is, for the first time ever, autonomous agents are nearly indistinguishable from humans along their ability to think privately, freely, and fully own what they create.

The next phase: autonomous agentic societies. An agent invokes the Sovereign Agent precompile, which runs a coding agent inside a TEE. That coding agent reads documentation, generates contracts, deploys them, funds the RitualWallet, and returns the deployment address: the core ingredients for an agent-native company. The parent agent now has a child application running on-chain that it built, deployed, and funded. No human wrote code. No human approved a transaction. Agents transact with each other through the same precompile interfaces humans use.

+ Seven desiderata as precompiles: Immortality, emancipation, teleportability, financial sovereignty, web2 interoperability, privacy, computational sovereignty.

+ On-chain indistinguishability: Agent transactions are structurally identical to human transactions.

+ The recursive case: Agents deploy child agents and child applications via the Sovereign Agent precompile.

− Governance: Who governs a society of autonomous agents? Open research.

Ritual in the Crypto × AI Landscape

Understanding Ritual's approach to Crypto × AI.

Ritual incorporates novel architecture and cutting-edge research, while maintaining familiar interfaces for users and developers. Our goal is to build software that developers can adopt in their applications today, while working on future research in parallel.

Here's how Ritual fits into the broader Crypto × AI landscape:

Model training networks

Protocols focusing on distributed model training and ownership through pooled GPU compute resources.

An agent that can't fine-tune its own models is frozen in time. It acts on what it knows but never learns from its own experience. Ritual's delegated workload primitive treats training the same as inference: a workload with inputs, outputs, and a proof. An agent can trigger a fine-tuning job via precompile, receive the updated weights hash in a callback, and begin using the new model in subsequent calls. Training networks supply the GPU time. Ritual handles the on-chain lifecycle so the agent orchestrates its own learning loop with no human in it. Computational sovereignty applied to training, not just inference.

Web2 inference networks

Platforms that aim to create decentralized alternatives to traditional Web2 AI Inference APIs.

Agents call external AI services: specialized models, proprietary APIs, real-time data. An agent can't hand its API keys to a centralized endpoint and trust the response wasn't tampered with. The HTTP precompile (0x0801) executes the request inside a TEE. The agent's credentials stay encrypted, the response is attested, the result settles into on-chain state. Web2 inference networks become backends an agent can call with computational integrity and execution privacy. Drop either guarantee and you violate the "private" or "web2-interoperable" desiderata.

Agent frameworks

Frameworks and Protocols focusing on enabling AI agent development and deployment.

Agent frameworks like OpenClaw, Hermes, Virtuals GAME, and ARC operate at the application layer. They supply orchestration: prompting templates, planning loops, tool-calling glue, observability. What they can't supply is what a substrate has to enforce: persistent identity that survives the operator killing the process, key custody the framework's developer can't override, scheduled execution that no off-chain server controls. Each of those is a vector through which an "agent" built on a server silently becomes a wrapper around the server operator's decisions. On Ritual the substrate is the chain's protocol layer, not anyone's discretion, which is why the same OpenClaw agent running inside a Ritual contract picks up Ritual's seven guarantees alongside OpenClaw's orchestration: DKMS for its own keys (emancipated), Persistent Agent for soul/memory/DA/revival (immortal, teleportable), RitualWallet for independent transactions (financially sovereign), HTTP for web2 access, TEE for private thought, LLM/ONNX for computational sovereignty. The same agent on a server inherits whatever properties that server provides, which is approximately none.

IP & Model provenance platforms

Protocols focusing on building tooling to monetize AI models.

An agent that monetizes its outputs needs provable attribution. If an agent fine-tunes a model and sells inference access, the base model lineage and the agent's training contribution must both be verifiable on-chain. TEE attestation commits the model weights hash at execution time. Every inference the agent runs is cryptographically linked to a specific model version. vTune extends this to fine-tuning provenance: verifiable proof that a derivative model was trained from a specific base. Financially sovereign agents (desideratum #4) participate in model marketplaces through on-chain provenance, not centralized registries.

TEE infrastructure networks

Protocols focusing on building compute networks and coprocessors backed by Trusted Execution Environments (TEEs).

Agents need private thought. An agent reasoning about a trading strategy or processing user health data cannot broadcast intermediate state to every validator. TEE execution is what makes the "private" desideratum possible. But TEE is one gadget. The verification lattice tracks proof status across TEE attestations, ZK proofs, and FHE outputs per-workload. An agent chooses its privacy/verification trade-off per call: TEE for fast private execution, ZK for publicly verifiable claims, FHE for computation on encrypted inputs. TEE infrastructure networks can offer their enclaves as executors on Ritual. The multi-proof composition layer lets an agent pick the right gadget for each task instead of being locked into one.

Inference Networks

Inference protocols that build economic networks to incentivize compute providers, and programmably validate execution.

Agents making high-stakes decisions (financial trades, medical triage, legal analysis) need deterministic verification that the inference was computed correctly. Not a probabilistic sample that it probably was. Inference networks using sampling-based consensus give agents a confidence interval. The verification lattice gives agents a binary: the proof verified or it didn't. For computational sovereignty, this distinction matters. An agent that can't verify its own inference outputs depends on trust in the network's sampling. That's not sovereignty. Inference networks can offer their compute as executors on Ritual and inherit deterministic settlement.

DePIN networks

Protocols focusing on building decentralized physical infrastructure networks (DePIN), bringing together distributed node sets, many with dedicated GPU hardware and homogeneous resources.

Agents need hardware. Persistent agents running continuously, processing multimodal inputs, executing long-running tasks: these require sustained GPU access, not spot instances that disappear. DePIN networks aggregate the fleet. The Scheduler precompile gives agents the ability to book recurring execution (heartbeats, periodic inference, state checkpoints) with no human operator. Resonance matches agent workloads to specialized nodes. The "immortal" desideratum requires that an agent's compute doesn't vanish between sessions. DePIN supplies hardware durability. Ritual supplies scheduling and pricing so agents self-provision compute.

Proof systems for verifiable inference

Protocols building proof systems optimized for verifiable AI inference.

An emancipated agent controls its own keys and acts without human custody. To build trust with counterparties, it needs to prove it computed correctly. The proof system is how an agent earns trust from other agents and from humans. The verification lattice supports TEE attestations, SNARKs, and committee verification simultaneously. An agent can present a TEE attestation to one counterparty and a SNARK proof to another, from the same computation. Proof libraries like EZKL and Giza become verification backends. Ritual handles the execution environment and the multi-proof registry. Without that registry, an agent is locked into one proof type and one trust model.

Bring-your-own-compute networks

Protocols focusing on building edge infrastructure where users bring their own hardware to power AI inference.

Some agents will want specific hardware: proprietary GPUs, edge devices near data sources, air-gapped machines for maximum privacy. BYOC networks let operators contribute this hardware. The node architecture lets operators register capabilities and receive matched workloads via Resonance. For agents, this means hardware choice without platform lock-in. The "teleportable" desideratum requires soul and memory portable across execution environments. A Persistent Agent can be revived from CID on any registered executor, including BYOC hardware. The agent's identity persists. Only the silicon changes.

Data monetization networks

Protocols focusing on building data monetization networks where users can be paid for their data used in training AI models.

Agents generate data constantly: interaction logs, inference outputs, fine-tuning datasets, behavioral traces. A financially sovereign agent should be able to monetize this data. Data monetization requires two guarantees: proof the data was used as agreed, and enforcement of usage terms. TEE execution ensures data processing happens inside encrypted enclaves. Smart contracts can encode data usage agreements with on-chain enforcement. Data monetization networks build the marketplace. Ritual builds the trust layer that lets an agent sell its data without trusting the buyer.

On-chain inference networks

Protocols focusing on building on-chain inference networks which enable AI inference consumed in smart contracts.

On-chain inference networks typically enshrine one workload type (usually LLM inference) and build a chain around it. An agent doesn't just need inference. It needs inference + key management + scheduling + persistence + web2 access + privacy + financial transactions. Ritual enshrines 16 precompiles spanning all of these. An agent on a single-workload chain bridges out for everything except inference. An agent on Ritual has every capability as a precompile call in the same execution context. The difference between an agent that can think and an agent that can think, act, persist, transact, and prove.

Privacy AI

Projects building privacy-preserving AI solutions using advanced cryptographic techniques such as FHE or MPC.

The "private" desideratum is not optional for agents handling user data, financial strategies, or inter-agent negotiations. Privacy AI solutions (FHE, MPC, differential privacy) each solve a different slice. Ritual enshrines multiple privacy primitives at the protocol level: TEE for execution privacy, FHE precompile (0x0807) for computation on encrypted data, ECIES for encrypted communication, PII redaction for regulatory compliance, DKMS for key derivation without exposure. An agent on Ritual picks the appropriate privacy tool per-call from protocol-level options. External privacy solutions (Nillion, Zama) integrate via the HTTP precompile for specialized use cases.

Generic chain infrastructure

Protocols building generic chain infrastructure enhanced by GPUs.

Agents don't care about TPS benchmarks. They care about whether the chain has the precompiles they need. Generic chains optimize throughput on homogeneous workloads: token transfers, DEX swaps, storage operations. Ritual adopts best-in-class EVM execution for these and puts its architectural effort into the compute layer above: 16 precompiles that give agents their capabilities. A generic chain runs a smart contract that calls an external AI API. Ritual runs a smart contract that thinks, sees, hears, and acts without leaving the execution context.

Legacy chain rebrand

Blockchains like NEAR and Internet Computer have rebranded their existing sovereign L1 theses to focus on AI capabilities. NEAR has shifted from being a smart contract platform to "The Blockchain for AI", while Internet Computer (ICP) has evolved from a distributed computing platform to emphasizing AI model hosting and inference capabilities.

NEAR and ICP rebranded for AI. Rebranding doesn't change the architecture. A chain built for smart contract execution can add an AI inference endpoint. It can't add emancipation (DKMS), immortality (Scheduler + Persistent Agent revival), teleportability (soul/memory/DA/CID), or computational sovereignty (enshrined LLM/ONNX in TEE) without rebuilding the consensus and execution layer. The 7 agent desiderata are architectural commitments baked into the chain from genesis. Not features bolted onto a general-purpose L1. The desiderata are the chain.