Execution Service
Last updated
Last updated
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.
Task Execution: Execute task logic specific to your use case.
Proof Generation: Generate and return a 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.
This guide explains how to create your own Execution Service, using the Simple Price Oracle AVS Example as a reference.
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:
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.
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:
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
performerAddress
address
The address of the Task Performer
signature
bytes
Task Performer ECDSA signature
Note:
data: Consider storing large decoded data in a more 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. This helps significantly reduce transaction gas fees once its submitted on chain.
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.
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.
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.
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.
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.
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.
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.
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.
The ID of specific