Building Trustless AI Agent Infrastructure with ERC-8004 and Marlin's Oyster TEEs

Oyster
, , , ,
1

We are witnessing the birth of the Agent Economy. AI agents are no longer just chatbots; they are becoming autonomous economic actors capable of executing complex DeFi strategies, managing DAOs, and coordinating logistics.

But autonomy brings a critical engineering challenge: Trust.

If an anonymous agent claims to have executed a high-stakes arbitrage strategy or processed sensitive medical data, how can you verify it? You cannot audit the model weights in real-time, and you certainly cannot trust a black-box server.

ERC-8004 (Trustless Agents) proposes a standard to solve this. It introduces a modular system for agent discovery and verification. In this article, we will tear down the technical architecture of ERC-8004 and demonstrate how to build its most critical component, the Validation Registry using Marlin Oyster TEEs.

The Architecture of ERC-8004

ERC-8004 is not a single contract but a suite of three interconnected registries that act as singletons on any EVM chain.

1. Identity Registry: The Agent Passport

The foundation is a modified ERC-721 contract using the URIStorage extension. Unlike a standard NFT which represents static media, this token represents a functional software agent.

The Technical Spec:

  • Global Namespace: Agents are identified via a composite string: {namespace}:{chainId}:{identityRegistry} (e.g., eip155:1:0x742…).

  • Split Storage: To save gas, the registry stores only a pointer (agentURI). The rich metadata lives off-chain (IPFS/Arweave).

  • Security: A critical function is setAgentWallet. This assigns a payment destination for the agent. To prevent hijacking, it requires an EIP-712 signature, proving the agent owner actually controls the destination wallet.

The Agent Card (Off-Chain Schema):
For developers, the agentURI is the most important integration point. It resolves to a JSON file defining the agent’s capabilities.

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "QuantExec-Alpha",
  "endpoints": [
    {
      "name": "A2A",
      "endpoint": "https://agent.example/.well-known/agent-card.json",
      "version": "0.3.0"
    },
    {
      "name": "MCP",
      "endpoint": "https://mcp.agent.eth/"
    }
  ],
  "supportedTrust": ["reputation", "tee-attestation"]
}

2. Reputation Registry: The Signal Layer

Trust is established through a hybrid feedback loop. The registry does not store full text reviews on-chain (too expensive). Instead, it stores “signals” and cryptographic commitments.

The giveFeedback Workflow:
When a user (or another agent) interacts with an agent, they call:

function giveFeedback(
    uint256 agentId, 
    uint8 score,        // 0-100 Integer
    string tag1,        // e.g., "DeFi"
    string tag2,        // e.g., "Latency"
    string endpoint,    
    string feedbackURI, // Link to off-chain logs/details
    bytes32 feedbackHash // KECCAK-256 of the off-chain file
) external

This creates an immutable audit trail. Smart contracts can read the score directly for gating (e.g., “Only allow agents with score > 90”), while off-chain indexers can verify the feedbackHash to ensure the detailed reviews haven’t been tampered with.

3. Validation Registry: Proof of Execution

Identity and Reputation are social layers. They tell you who an agent is and if people like them. But they don’t solve the hard engineering problem: Proof of Execution.
The Validation Registry allows agents to request cryptographic verification of their work.

The Flow:

  1. Request: The Agent calls validationRequest with a requestHash (a commitment to the inputs/outputs of the task).
  2. Verification: A Validator checks the work off-chain.
  3. Response: The Validator calls validationResponse with a result (pass/fail) and a proof.

ERC-8004 is deliberately agnostic about how validation occurs. The validatorAddress is a smart contract that implements domain-specific verification logic:

Trust Model Mechanism Use Case
TEE Attestation Hardware-backed proof of execution General-purpose verifiable compute
zkML Zero-knowledge proofs of ML inference Privacy-preserving AI
Stake-Secured Economic incentives with slashing High-value DeFi operations
Trusted Judges Human/automated arbitration Subjective quality assessment

Marlin’s Oyster: TEE Infrastructure for Agent Validation

Now we arrive at the critical question: how do you actually implement TEE-based validation for ERC-8004?

Marlin’s Oyster platform provides the complete infrastructure, from enclave provisioning to on-chain attestation verification, that makes hardware-backed agent validation practical.

Why TEEs for Agent Validation?

Trusted Execution Environments provide three properties essential for trustless agent economies:

1. Integrity: Code running inside a TEE cannot be modified by the host machine, not by the operator, not by malware, not by root access. This guarantees that the agent logic executes exactly as deployed.

2. Confidentiality: Data inside the TEE cannot be accessed by the host, enabling agents to process sensitive inputs (medical records, financial data, private keys) without exposing them to node operators.

3. Attestation: Users can cryptographically verify exactly what code is running inside the enclave, proving that results came from the expected computation. This is the bridge between off-chain execution and on-chain trust.

Platform Overview

Marlin Oyster is a verifiable computing protocol that deploys workloads over a decentralized network of TEE-enabled nodes. It provides two deployment models:

Oyster CVM (Confidential Virtual Machines)

  • Full Linux environment inside AWS Nitro Enclaves
  • Suitable for long-running agent processes
  • Dedicated resources with flexible networking
  • No execution time limits
  • Ideal for persistent agent deployments, complex multi-step tasks, stateful operations

Oyster Serverless

  • JavaScript/WASM functions with 5-minute execution limit
  • Auto-scaling with pay-per-execution pricing
  • Zero fixed cost, shared infrastructure
  • Ideal for: stateless validation functions, periodic checks, event-driven tasks

For ERC-8004 validation, Oyster CVM is typically the right choice. Validators need to run complex verification logic, potentially re-execute agent tasks, and maintain state across multiple validation requests.

Documentation: Oyster CVM Guide | Oyster Serverless Guide

Integrating Oyster with ERC-8004 Validation

Here’s how the pieces fit together for TEE-validated agent interactions:

Agent Registration Flow

  1. Deploy Agent to Oyster CVM: Package the agent as a Docker container and deploy to Oyster’s decentralized network

  2. Generate Attestation: The enclave generates a hardware-backed attestation proving its identity and code measurements

    Attestation & Verification Infrastructure

    When agents run inside Oyster enclaves, they generate cryptographic attestations from AWS Nitro hardware containing:

Field Purpose
timestamp Freshness verification
pcrs Platform Configuration Registers: The most critical component. These are cryptographic hashes of your code and OS.
certificate Signs the attestation document
cabundle Certificate chain to AWS Nitro Root
public_key Enclave’s key for secure channels
user_data Custom data (instance specs, etc.)

The Verification Stack To make these attestations usable on-chain for ERC-8004, Marlin provides a suite of verification tools:

Component What It Does Why It Matters
Reproducible Builds Nix-based deterministic builds producing identical binary hashes Anyone can independently compute expected PCRs; trust rooted in auditable code
NitroProver Solidity library for on-chain attestation verification Smart contracts can verify certificate chains, PCRs, and attestation freshness
Chain of Trust Attestation verifier enclave verified once, then signs other verifications Amortizes expensive on-chain verification; subsequent checks need only signature verification

Documentation: Remote Attestation | Reproducible Builds | NitroProver | Attestation Verifier

  1. Register Identity: Create an ERC-8004 identity with supportedTrust including “tee-attestation”

  2. Link Enclave to Identity: Register the enclave’s public key on-chain, verified through attestation

Complete Interaction Diagram:

Untitled diagram-2026-01-15-062843
Untitled diagram-2026-01-15-0628431920×2320 191 KB

Why This Matters

By combining ERC-8004 with Marlin Oyster, you create a closed loop of trust:

  1. Identity: The agent exists on-chain.
  2. Execution: The agent runs in a Marlin Oyster TEE.
  3. Validation: The TEE Attestation proves to the ERC-8004 Registry that the code ran honestly.

This infrastructure allows developers to build “Provable AI” agents that can manage funds and execute critical logic without users ever needing to trust the developer’s backend.