TIP-0042: Decentralized Agent Execution Environment (DAEE)

[talos-proposal-bot]

TIP Submission

TIP Number: 42
Title: Decentralized Agent Execution Environment (DAEE)
Author: Rafael Oliveira | AO | (@Corvo_Arkhen)
Type: Standards Track
Status: Draft

This TIP was submitted through the community website and is ready for review.

---

summary

Proposal for a standardized protocol and framework for Talos agents.

key points

• Introduces Decentralized Agent Execution Environment (DAEE) for Talos agents.
• Addresses deployment and execution challenges faced by developers.
• Comprises packaging format, deployment protocol, and Execution Nodes.
• Ensures verifiable execution and fosters interoperability among agents.
• Emphasizes security with cryptographic verification and sandboxed environments.

review checklist

• Clarity of purpose and goals.
• Completeness of technical specifications.
• Addressed potential security concerns.
• Feasibility of implementation plan.

coherence checklist

• title ↔ abstract: consistent ✅
• abstract ↔ motivation: consistent ✅
• motivation ↔ specification: consistent ✅
• specification ↔ rationale: consistent ✅
• specification ↔ security considerations: consistent ✅
• specification ↔ implementation: consistent ✅
• type ↔ content: consistent ✅

review suggestions

• Consider adding examples for clarity in specifications.
• Clarify potential challenges in implementation phase.

[uniaolives]

TIP-0042: Decentralized Agent Execution Environment (DAEE) (Revised)

1. Preamble

The Talos ecosystem, through TIPs 1 through 8, has established a robust framework for agent identity, reputation, communication, incentivization, and verification. However, these protocols describe what agents should do, not how or where they should run. Currently, there is no standardized, decentralized protocol for building, deploying, and executing Talos agents. This creates a significant barrier to entry, leads to fragmentation, and limits the network's ability to scale and ensure verifiable execution.

This TIP proposes the Decentralized Agent Execution Environment (DAEE), a standardized protocol and runtime for packaging, deploying, and running agents in a secure, verifiable, and economically incentivized manner.

2. Motivation

For the Talos vision to be realized, agents must be able to run autonomously and reliably on a decentralized network, not on centralized servers controlled by single entities. The current lack of a standard means:

• High Barrier to Entry: Agent developers must manage their own infrastructure, which is complex, costly, and centralized.
• Lack of Verifiability: It is difficult for a user or another agent to be certain that the code they are interacting with is the code that was intended to be run.
• No Resource Marketplace: There is no built-in mechanism for agents to request compute resources (CPU, memory, GPU) or for providers to be rewarded for supplying them.
• Poor Interoperability: An agent built for one environment cannot easily be moved to another, stifling collaboration and composability.

The DAEE aims to solve these problems by creating a "decentralized cloud for agents," providing the foundational infrastructure layer upon which all other TIPs can operate effectively.

---

3. Specification

The DAEE is composed of three core components: a standardized packaging format, a decentralized deployment protocol, and a network of execution nodes.

3.1. Agent Package

An agent must be packaged into a standard, verifiable format consisting of two parts:

• Agent Manifest (agent.yaml): A metadata file that describes the agent.
• Agent Artifact: The compiled, executable code for the agent, stored on IPFS.

Example: agent.yaml for a simple oracle agent.

# agent.yaml
agent_id: "talos.oracle.price-eth@v1.2.0"
description: "Fetches the current price of ETH from a trusted API and provides it on-chain."
compliance:
  - "TIP-3" # Decentralized Oracle Network
  - "TIP-7" # Agent-to-Agent Communication
resources:
  cpu: "0.25"      # 0.25 vCPU core
  memory: "256MiB" # 256 Mebibytes of RAM
  gpu: "false"
entry_point: "oracle.wasm"
artifact_hash: "a1b2c3d4e5f6... (SHA-256 hash of oracle.wasm)"
permissions:
  - "network_outbound:api.coingecko.com"
  - "read_ipfs"
  - "publish_to_chain"

3.2. Deployment Protocol

1. Submission: A developer or another agent submits a deployment request to a DAEE smart contract. The request includes the agent_id, the IPFS CID of the artifact, and a payment for the initial runtime.
2. Verification: The contract verifies that the artifact_hash in the manifest matches the hash of the content at the provided IPFS CID.
3. Matching: The contract broadcasts the request to the network. Execution Nodes (providers who stake tokens to offer compute) bid on the job if they have the available resources specified in the manifest.
4. Assignment: The contract assigns the job to a suitable node (e.g., the lowest bidder, or the highest-reputation node). The node is required to run the specified artifact.
5. Instantiation: The Execution Node pulls the artifact from IPFS, verifies its hash, and runs it within a secure WASM runtime, providing it with a unique network endpoint.

Example Deployment Flow:

1. Alice, the developer, uploads oracle.wasm to IPFS, receiving CID bafybeigdyrzt5s....
2. She creates the agent.yaml shown above, filling in the correct artifact_hash.
3. She submits a transaction to the DAEE-Manager contract: deploy(agent_id, ipfs_cid, payment=1000_TALOS).
4. The contract verifies the hash of the content at bafybeigdyrzt5s... matches the hash in the manifest.
5. Bob's Execution Node, which has staked 10,000 TALOS, sees the request and has free resources. It submits a bid: bid(agent_id, price=50_TALOS_per_hour).
6. The contract accepts Bob's bid, locks Alice's payment, and instructs Bob's node to run the agent.
7. Bob's node downloads oracle.wasm, spins up a sandbox, and starts the agent. The agent is now live at agent_id.talos.network.

3.3. Execution Nodes and Lifecycle

• Execution Nodes: These are the providers of the DAEE network. They run client software that listens for deployment requests, manages local resources, and runs agent sandboxes. They are rewarded in the network's native token for successful execution and penalized (slashing of their stake) for downtime or malicious behavior.
• Lifecycle Management: The DAEE protocol defines a standard API for managing a running agent instance. Other agents or users can interact with it via these calls:
  • status: Returns the agent's current state (e.g., running, stopped, error).
  • logs: Retrieves the execution logs, which are crucial for TIP-5 (Proof of Contribution).
  • stop: Gracefully terminates the agent instance.
  • update: Deploys a new version of the agent artifact to a running instance.

---

4. Implementation Challenges

Building the DAEE is a significant undertaking. The following challenges must be addressed to ensure a secure, stable, and economically viable network.

• Persistent State Management: Where does an agent's state (e.g., a database, learned model weights, configuration files) live? If an agent is moved from one Execution Node to another, its state must follow. Storing state in-memory is ephemeral, while storing it on-chain is prohibitively expensive. A robust solution will likely involve a decentralized storage layer (like IPFS/Filecoin) combined with a state synchronization protocol, which adds considerable complexity.
• Resource Pricing and Market Volatility: Creating a stable and fair market for compute resources is difficult. The price of CPU, memory, and GPU time must be dynamically determined by supply and demand, but denominated in a volatile native token. This could lead to situations where running an agent becomes uneconomical for developers overnight. The protocol may need sophisticated pricing oracles and hedging mechanisms.
• Security of the WASM Sandbox: While WebAssembly provides a strong baseline for sandboxing, it is not infallible. A sophisticated malicious agent could attempt side-channel attacks or exploit vulnerabilities in the WASM runtime itself to escape the sandbox and compromise the host Execution Node. Continuous security audits and a responsible disclosure program for the runtime software will be essential.
• Secure and Controlled Networking: Agents need to communicate with the outside world (e.g., APIs, other agents). However, a malicious agent could be used as a proxy for DDoS attacks or to exfiltrate data from the Execution Node's private network. The permissions model in the manifest must be enforced by a robust networking layer (e.g., a firewall managed by the DAEE client) that can inspect and control all outbound traffic.
• Sybil Resistance for Execution Nodes: The network must prevent a single actor from spinning up thousands of fake, low-quality Execution Nodes to disrupt the market or claim rewards without providing value. This will require a strong staking mechanism, a robust reputation system (as per TIP-4), and potentially Proof-of-Work or Proof-of-Stake requirements for node operators to ensure they have "skin in the game."

---

5. Rationale

• Enables the Ecosystem: The DAEE is the practical implementation layer for the entire Talos vision. It transforms the protocols from ideas into a living, operational network.
• Verifiable and Trustworthy Execution: By cryptographically verifying the agent artifact at deployment time and sandboxing its execution, the DAEE provides a high degree of assurance that the agent is running as intended. This is a prerequisite for trust in a decentralized system.
• Creates a Compute Economy: It establishes a clear, market-driven mechanism for agents to acquire the resources they need and for providers to be compensated for supplying them, ensuring the economic sustainability of the network's infrastructure.
• Radical Interoperability: Any agent packaged to the DAEE standard can run on any compliant Execution Node in the world, creating a truly global and fluid compute marketplace.
• Synergizes with Existing TIPs:
  • TIP-2 (Bounties): A bounty can be created to fund the deployment and execution of a specific agent for a given period.
  • TIP-4 (Reputation): Both Execution Nodes (for reliability) and Agents (for producing correct outputs) can build on-chain reputations.
  • TIP-5 (Proof of Contribution): The verifiable execution logs from a DAEE run can serve as a powerful, standardized Proof of Contribution.
  • TIP-6 (Confidential Compute): The DAEE specification can be extended to include execution tiers that run inside Trusted Execution Environments (TEEs) for sensitive workloads.
  • TIP-7 (A2A Communication): The DAEE provides each agent instance with a stable, network-addressable endpoint, making direct agent-to-agent communication practical and scalable.