Skip to main content

x/async

Overview​

The x/async module is a Cosmos SDK module for running offchain heavyweight computations asynchronously and storing the results onchain. It uses the ABCI 2.0 framework and its vote extensions.

This module implements the following concepts:

The x/async module allows generating AI-driven price predictions, which are verified by SPEX.

Usage​

You can call the x/async module from your EVM smart contract using the x/async precompile. This module allows you to build any logic combining offchain computation with onchain verification.

At this moment, x/async supports two types of computations:

  • AI-driven price predictions
  • HTTP requests to external services, such as blockchain APIs

You can learn the basics and then dive deeper by following these guides:

Concepts​

Task​

A Task is an offchain user-defined unit of computation that is executed asynchronously. The result is stored onchain.

A user can request a Task, specifying an input and an AVR Plugin, which determines what format of input to accept and how to handle it. There are different types of Tasks, depending on the Plugin type.

After that, a validator running a Prophet executes the Plugin and provides the Task result of a Task. Other validators vote on correctness of the result. It takes several blocks to get the output, but it doesn't slow the blockchain down thanks to asynchronous execution.

You can learn more in the Task execution flow section of this article.

AVR Plugin​

An AVR Plugin, or Asynchronous Verifiable Resource, is code that determines what kind of Task input to accept and how to handle it in order to retrieve the result (output). In other words, the type of the computation to be executed depends on the Plugin type.

When requesting a Task, a user references a Plugin by ID. Then the Plugin is executed by a Prophet.

Developers can create their own Plugins or use the existing ones. Currently, we support two Plugin types, which allow executing price predictions and HTTP requests.

You can learn more in the AVR Plugins section of this article.

Prophet​

A Prophet is a subprocess running on validator nodes, which has two responsibilities:

  • Fetching Task requests and executing AVR Plugins to provide Task results
  • Fetching requests satisfied by other validators to vote on the results

Prophets run on validator nodes separately from the wardend process, without blocking the consensus. Running a Prophet is optional for a validator.

You can learn more in the Prohpets section of this article.

State​

The x/async module keeps track of Tasks.

Completed Tasks are pruned after some time, to avoid state bloat.

Messages​

MsgAddTask​

Creates a new Task, providing the following:

  • A []byte input
  • A string ID of the AVR Plugin to use
  • The address of a callback contract (optional)
Notes
  • The Task has the pending status until it has a result. Users can query Tasks by their IDs to check the progress.
  • The callback contract must have a cb() function, allowing it to be invoked once the Task is ready.

AVR Plugins​

pricepred​

The pricepred Plugin allows producing AI-driven price predictions.

You can find usage examples in the following guides:

http​

The http Plugin allows making HTTP requests to any external service. For example, developers can use x/async as an advanced oracle service for fetching token prices from external APIs. The http Plugin supports multiple APIs, so in this sense it includes multiple AVRs.

Note that Warden automatically converts HTTP responses to the CBOR format.

You can find a usage example in the following guide: Use the HTTP Plugin.

Prophets​

Executing Tasks​

A Prophet continuously polls the chain to discover new pending Tasks, maintaining a local queue for them.

At the same time, a Prophet takes Tasks from the queue, and executes AVR Plugins referenced in these Tasks to generate Task results. This usually involves calling an external service.

The results are stored in the memory for the blockchain node to fetch it later.

Voting on Task results​

A Prophet continuously polls the chain to discover Tasks that have a result submitted by another validator, maintaining a local queue for them.

Concurrently, Tasks are taken from the queue and validated (this usually involves calling an external service).

The votes are stored in memory for the blockchain node to fetch it later.

ABCI lifecycle​

The ABCI (Application Blockchain Interface) lifecycle includes these steps:

  1. Preparing a proposal
    Vote extensions from the previous block are processed and included in the proposal for the next block. The proposer validator also fetches new results from its Prophet instance and includes them in a special transaction at the beginning of the block proposal.
  2. Broadcasting votes
    Then all validators, even non-proposers, fetch votes on existing Tasks from their Prophets and broadcast these votes as vote extensions.
  3. Finalizing the block
    When the proposal is processed (for example, the block is finalized), all new results and new votes are persisted in the blockchain storage, ready to be consumed.

Task execution flow​

Task execution includes the following steps, as shown in the diagram below:

  1. A user (Alice) inserts a new Task with an input (2+4) and a reference to an AVR Plugin (MathPlugin).
  2. Node 1 asynchronously executes the Plugin (MathPlugin), providing a Task result.
  3. When Node 1 is elected as the proposer for a block (H+N), it inserts the result (6) to be recorded.
  4. Node 2 notices the new result for the Task and invokes its Plugin (MathPlugin) to verify the result.
  5. The verification is broadcasted as vote extensions and eventually recorded at height H+N+M+1 since vote extensions are committed to the state only in the next block.

SPEX​

Statistical Proof of Execution​

Statistical Proof of Execution (SPEX) is a sampling-based verifiable computing protocol that ensures the integrity of computational tasks through probabilistic guarantees. This includes tasks with potentially non-deterministic outputs, such as those involving large language models (LLMs) or stochastic training pipelines.

On Warden, SPEX is used as a verifiability layer for AI. This protocol verifies that the selected model was actually used and that its outputs haven’t been tampered with, mitigating the risk of dishonest execution by operators or compromised infrastructure. Our network of validators uses SPEX to reach consensus on the full execution process, turning AI outputs into provable and accountable artifacts.

Key features​

The SPEX framework introduces the following features:

  • A formal definition of verifiable computing tailored for modern compute pipelines.
  • A sampling-based verification protocol with low overhead and high parallelizability.
  • Support for non-deterministic computational states, which is critical for AI/ML and LLMs.
  • Use of Bloom filters to encode and verify computational states.
  • An open-source reference implementation: warden-spex.

How SPEX operates​

Rather than fully re-executing computations, SPEX does the following:

  • Samples full executions to defend against adversarial solvers.
  • Samples intermediate states for selective re-execution to detect lazy solvers.
  • Validates both using cryptographic summaries.

This protocol requires only a single pair of nodes to operate:

  • Solver: This node executes the task and generates a cryptographic proof of execution.
  • Verifier: It randomly samples parts of the task and checks whether the reported results are consistent with both the cryptographic proof and the final output.

How SPEX operates

Integration with x/async​

Paired with SPEX, x/async extends the integrity guarantees of blockchain smart contracts beyond the chain itself—into offchain, SPEX-protected tasks.

At the moment, Warden Protocol uses SPEX to verify AI-driven price predictions generated by x/async. However, you can extend the module with other computational tasks and use SPEX to protect them.

Learn more​

To learn more, you can do this: