Agentic Rails Atlasby merces.ai

Persona

Validator, auditor or attestor

Re-execution, zkML or TEE attestation, reputation services.

Verified (verified under 30 days ago)

Role

Goals

  • Produce an independent score for an agent's work that others can read on chain.
  • Verify that an agent's claimed output came from the claimed model and inputs, by re-execution, a zkML proof or a TEE quote.
  • Build a reputation service that filters Sybil feedback and weights reviews by proof of payment.
  • Attest to agent identity and behavior in a format that merchants, facilitators and controls platforms can consume.
  • Get paid for validation work through the same rails the agents use.

Pains

  • The ERC-8004 Validation Registry is specified but not officially deployed, so validation lives in community registries with no shared address.
  • LLM outputs are not deterministic, so re-execution does not reproduce results and cannot prove misbehavior.
  • zkML is slow and expensive for real models, and TEE attestation depends on hardware vendors and quote verification.
  • Most feedback on chain comes from coordinated Sybil reviewers, so aggregate scores are not usable without heavy filtering.
  • requestHash squatting and mutable registration files weaken the link between a validation and the agent it describes.

Decisions they own

  • Which validation method to offer: re-execution, zkML, TEE attestation, or statistical sampling.
  • Which trusted-client lists and proof-of-payment rules to apply when computing a summary.
  • Whether to write results to an on-chain registry, an off-chain API, or both.
  • What soft and hard finality mean for a validation response, and when to update it.

Vocabulary

  • validationRequest
  • validationResponse
  • requestHash
  • re-execution
  • zkML
  • TEE attestation
  • getSummary
  • trusted clients
  • Sybil
  • proofOfPayment
  • feedback
  • tag
  • finality
  • supportedTrust

Each protocol from this seat

Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.

ERC-8004: Trustless Agents

Relevance: High

Would check an agent's work and post a 0 to 100 response in the Validation Registry, which is specified but not officially deployed. Source [1, 2, 3, 4, 5]

Goals

  • Offer re-execution, zkML or TEE checks as a service
  • Publish results others can query
  • Get paid for the work

Pains

  • No officially deployed Validation Registry
  • Incentives and slashing are out of scope
  • LLM outputs vary between runs, which weakens re-execution

Implements

  • A validator contract or service that reads requestURI
  • validationResponse calls with tags such as soft and hard
  • Evidence files at responseURI

Must trust

  • The request data at requestURI
  • Its own attestation or proof system
  • The registry code, which one key can upgrade

Questions they ask

  • Will the Validation Registry be redesigned before a listed deployment?
  • Can I lower a response after a pass, and should I?
  • Who pays for validation?

First three steps

  1. Read the Validation Registry section and issue 28
  2. Deploy the reference contract on a local chain
  3. Prototype one validation method

Metrics they care about

  • Requests answered
  • Time to final response
  • Disputed responses

A day in the life. Kai runs a TEE attestation service and wants to post results through ERC-8004. He finds the Validation Registry in the text, but the contracts README lists no address and calls that part still under discussion. A contract answers at the scripted address on Base, yet nobody announced it, so he does not build on it. He deploys the reference code on a local chain instead, posts a soft response and then a hard one, and notices that a later answer can also lower a pass. He follows the open issue on that and waits for an official deployment.

Steps in the responsibility table

  • OwnsAnswer validation requests (specified only)

x402

Relevance: None

Not one of the main personas on the x402 page. The responsibility table gives this persona no step.

Visa Trusted Agent Protocol

Relevance: None

Not one of the main personas on the Visa Trusted Agent Protocol page. The responsibility table gives this persona no step.

Agentic Commerce Protocol (ACP)

Relevance: None

Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.

UCP

Relevance: None

Not one of the main personas on the UCP page. The responsibility table gives this persona no step.

AP2

Relevance: None

Not one of the main personas on the AP2 page. The responsibility table gives this persona no step.

Mastercard Agent Pay

Relevance: None

Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.

Sources

  1. ERC-8004: Trustless Agents (specification source, ERCS/erc-8004.md) (external link)Ethereum ERCs repository. Specification, primary source. Published . Accessed .
  2. erc-8004-contracts README (external link)erc-8004 (GitHub organization). Repository, primary source. Published . Accessed .
  3. On-chain reads of the ERC-8004 proxies (owner, getVersion, ERC-1967 implementation slot) on Ethereum and Base (external link)Atlas research (eth_call through public RPCs). Dataset, primary source. Accessed .
  4. Rogue validators can manipulate validation response values (issue 28) (external link)erc-8004 (GitHub organization). Repository, primary source. Published . Accessed .
  5. ValidationRegistryUpgradeable.sol (external link)erc-8004 (GitHub organization). Repository, primary source. Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts