Execution Service

Overview

The Execution Service is a container with the task execution logic, called by the Performer node. The service acts as a micro-service for executing tasks and can be written in any programming language.

Key Responsibilities

• Task Execution: Execute task logic specific to your use case.

• Proof Generation: Generate and return proofOfTask upon successful task execution.

• RPC Communication: Communicate with other AVS operators via JSON-RPC calls.

When a task is triggered, the Performer is responsible for ensuring the task is executed by the execution service and submitted to the peer-to-peer (p2p) network via an RPC call.

Building your Execution Service

This guide explains how to create your own Execution Service, using the Simple Price Oracle AVS Example as a reference.

Task definitions can be configured using attestationCenter contract, as outlined here. Tasks can be initiated either manually via an API call or automatically in response to specific events. You can find different methods for triggering events in the examples section below.

1

Task execution logic

Your service should:

• Receive task execution requests.

• Execute the task logic (e.g., fetching data from an API or performing calculations).

• Generate a proofOfTask (e.g., storing results in IPFS and returning the CID).

2

Triggering Task Execution

Task execution can be initiated through different methods, depending on the architecture:

• Via API Endpoint: You can define an endpoint (e.g., /task/execute) that allows operator nodes (Performers) to trigger task execution. For example, a curl request to trigger task execution could look like this:

  curl -X POST \
    http://localhost:4003/task/execute \
    -H 'Content-Type: application/json' \
    -d '{
      "taskDefinitionID": "your_task_definition_id"
    }'

• Via Events: Alternatively, task execution can be triggered automatically through events, such as system signals or blockchain events, without the need for manual API requests.

3

Send Task Results

Once the task is executed, submit the proofOfTask to the p2p network using the sendTask RPC call. A new task is generated off-chain when the Performer node initiates the sendTask RPC call. This is the format for the RPC call:

{
  "jsonrpc": "2.0",
  "method": "sendTask",
  "params": [
    <proofOfTask>, 
    <data>, 
    <taskDefinitionId>, 
    <performerAddress>, 
    <signature>,
    <signatureType>,
    <targetChainId>
  ]
}

Parameter	Type	Description
proofOfTask	string	Any string that the Attesters can use to verify that the Performer has executed its task as expected
data	bytes	Additional data to be added to the consensus
taskDefinitionId	uint16	The ID of specific Task definition
performerAddress	address	The address of the Task Performer
signature	bytes	Task Performer ECDSA signature
signatureType	string	An optional parameter to specify the type of the signature: 'ecdsa' (default) or 'bls'.
targetChainId	uint	The ID of the L2 chain where the transaction should be submitted. To use this parameter, signatureType must be explicitly specified.

Important notes:

data: in order to significantly reduce transaction gas fees, consider storing large decoded data in an efficient storage solution such as IPFS (InterPlanetary File System). Instead of including the entire data payload in the transaction, you can include a reference link (e.g., an IPFS URI) that points to the stored data.

taskDefinitionId: the unique identifier for the task definition. This is typically provided as part of the request, allowing the performer to know which task logic to execute. In the example, it is retrieved from the request body as req.body.taskDefinitionId.

signature: a cryptographic signature that authenticates the task submission. This proves that the performer node is the one submitting the task.

signatureType: specifies the type of cryptographic signature used to authenticate the Performer to the P2P network. The supported values are:

• 'ecdsa' (default)

• 'bls'

If using BLS signatures, you must explicitly set signatureType to 'bls'. This enables the P2P network to correctly verify the signature using BLS.

targetChainId - The ID of the L2 chain where the transaction should be submitted. In the case of multi-L2s, this value can be used to target a specific L2. The submit Task transaction will then be sent to the Attestation Center contract deployed on the specified chain. If not provided, it defaults to the first chain configured via environment variables. For example, ifL2_CHAIN=85432,80002 , then the transaction will be submitted to the Base Sepolia chain (chain ID 85432), which is the first Id.

signatureType: since signatureType is an optional parameter, if you wish to use targetChainId, you must fill signatureType as well (i.e. 'ecdsa' ).

4

Containerization with Docker

The Execution Service should be containerized using Docker for ease of deployment and scalability. This ensures the service is isolated and easily managed, replicated, and scaled across different environments. Refer to the example in the Simple Price Oracle AVS repository for guidance on how to set up your containerized service.

---

AVS Boilerplates

• Simple Price Oracle AVS Example JS
• Simple Price Oracle AVS Example Go
• Simple Price Oracle AVS Example Rust

In the Simple Price Oracle AVS, tasks are triggered via an API call to /task/execute. Upon triggering, the Execution Service retrieves the price of the requested assets and generates a proof of task. This proof is then gossiped to the p2p network using the sendTask RPC call until it is attested and successfully submitted as a valid on-chain task.

---

Example Use Cases

Uniswap Dynamic Fee

In this AVS, Tasks are triggered every hour to dynamically calculate fee based on market volatility. When triggered, the Execution Service retrieves the ETH/USDT volatility, calculates swap fee, stores the results in IPFS and generates a proof of task. This proof is then gossiped to the p2p network using the sendTask RPC call. Once the task is successfully submitted on-chain, the updated fee is reflected in the Uniswap Hook contract.

Parallel EVM Transactions

In this AVS, Tasks are run every 5 seconds using a cron job that makes an API call to /task/execute. Once triggered, the service retrieves the latest block from a custom client, enabling parallel processing. It uses a ParallelPool to keep track of pending transactions and groups parallelizable transactions into batches and uses smart prioritization to determine optimal execution order. The full block data is then published to IPFS, while the generated hash is used as proof of task. The storage key for this data is included in the task payload and propagated to the p2p network using the sendTask RPC call.

AI Powered Prediction Markets

In this AVS, the Execution Service retrieves real-time currency price data from Binance and leverages a Social Media Analysis Oracle to assess Twitter sentiment and detect content patterns for resolving prediction markets. All processed data is stored on IPFS, and a proof of task is generated. Additionally, it integrates Uniswap v4 Hooks for binary betting and sentiment-driven market analysis.

Distributed GPU

In this AVS, the Execution Service is responsible for handling and executing computational tasks on remote GPU nodes through a REST API. The service invokes GPU-optimized computation via the compute_tensor function, which communicates with a remote tensor processing engine. This proof is then gossiped to the p2p network using the sendTask RPC call.

DNS Registry AVS

This example demonstrates how a DNS Registry AVS can manage domain name registration tasks. The Task Performer triggers the Execution Service to process tasks like registering or updating domain records. Upon successful execution, the service generates a proofOfTask, which is then submitted to the p2p network via an RPC call.