ERC-8004 integration

VIGIL publishes Endpoint Scores to the ERC-8004 Reputation Registry on Base rather than keeping them behind its own API. This page describes what ERC-8004 is, exactly which fields VIGIL writes, why a registry was chosen over an API, how a write is authorized and scheduled, how the Identity Registry is used to attribute an endpoint to a provider, and what the integration does not do.

What ERC-8004 is

ERC-8004 is an Ethereum standard for trustless agent interaction. It defines three onchain registries: an Identity Registry that gives each agent a resolvable identifier, a Reputation Registry where third parties record feedback about an agent, and a Validation Registry for recording independent verification of an agent's work.

VIGIL uses the first two. An x402 endpoint is treated as an agent in the ERC-8004 sense: it has an identity owned by its provider, and VIGIL is a third party recording reputation about it.

What VIGIL writes to the Reputation Registry

The aggregator writes one record per scored endpoint. The record is deliberately small; the underlying attestations stay onchain as their own events and can be reconstructed from the content hash.

Nothing else is written. The per-check breakdown (uptime, schema, price, latency), the regional views and the raw latency values are available from the attestation events and the read API, not from the registry record.

Why a registry and not just an API

An API would be simpler to build. VIGIL writes to the registry anyway for three reasons.

• Neutral. The record lives in a contract VIGIL does not own. If VIGIL's API goes offline or changes its terms, the last written scores remain readable, and the content hash lets anyone check that a score matches the public attestations.
• Free to read. Any agent or framework with a Base RPC connection reads a score with one eth_call. No key, no fee, no rate limit VIGIL controls. The hosted read API at https://api.vigil.example/v1/score/{endpoint} (placeholder) mirrors the registry; it is not the source of truth.
• Composable. ERC-8004 consumers already read the Reputation Registry. A framework that filters counterparties by reputation picks up VIGIL scores without integrating VIGIL, and other scorers can write records for the same endpoint alongside.

How the write is authorized

The Reputation Registry accepts feedback from any address, so authorization is about letting readers know which records are VIGIL's, not about permission to write.

The VIGIL score aggregator is a contract with a single registered signer key. It aggregates attestation events, computes the score, and submits the registry write signed by that key. Readers filter registry records by the aggregator's address.

Writes are scheduled, not continuous:

• A write is triggered for an endpoint when its score changes by more than 1 point from the last written value.
• Regardless of change, every endpoint is rewritten at least every 24 h so the last-updated block stays fresh.
• A dispute resolution that removes attestations triggers an immediate rewrite for the affected endpoints.

This keeps gas costs bounded while ensuring a reader never sees a record more than a day old for an endpoint that is still being probed. An endpoint that drops below the public threshold (fewer than 25 attestations from 5 Watchers after decay) has its record cleared rather than left at a stale value.

How VIGIL reads the Identity Registry

Scores are about endpoints; accountability is about providers. The Identity Registry connects the two.

When a provider registers an endpoint (see For providers), the request is signed by the key that controls an ERC-8004 agent ID. VIGIL resolves that agent ID in the Identity Registry, checks the signer matches the registered owner, and stores the endpoint under that agent ID. Endpoints that are observed through the Facilitator but never registered are recorded under a zero agent ID until a provider claims them with a signed registration.

The link is used in three places:

• Attribution. The read API and the registry record show which provider is behind an endpoint, so an agent can prefer providers with a track record across several endpoints.
• Registration checks. Only the identity owner can register, transfer or delist an endpoint.
• Collusion detection. Slashing for Watcher-provider collusion (see Watchers) looks at attestation patterns per provider identity, not per URL, so a provider cannot hide the pattern by rotating hostnames.

Reading a score from a contract

The snippet below shows the shape of a read from another contract. It is illustrative: the deployed ABI will follow whatever the final ERC-8004 registry interface exposes, and the aggregator address is a placeholder.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface IVigilReputationReader {
    struct EndpointScore {
        uint8   score;            // 0-100
        uint32  attestationCount;
        uint64  lastUpdatedBlock;
        bytes32 contentHash;      // keccak256 of the attestation set
    }

    /// @notice Latest VIGIL record for an endpoint, or a zeroed struct if none.
    function scoreOf(uint256 agentId, bytes32 endpointHash)
        external
        view
        returns (EndpointScore memory);
}

contract RequiresReliableEndpoint {
    // placeholder — contracts not deployed
    IVigilReputationReader constant VIGIL =
        IVigilReputationReader(0x0000000000000000000000000000000000000000);

    uint8 public constant MIN_SCORE = 70;

    function endpointAllowed(uint256 agentId, string calldata url)
        external
        view
        returns (bool)
    {
        bytes32 endpointHash = keccak256(bytes(url)); // normalize before hashing in practice
        IVigilReputationReader.EndpointScore memory s = VIGIL.scoreOf(agentId, endpointHash);
        if (s.attestationCount == 0) return false; // no public score
        return s.score >= MIN_SCORE;
    }
}

A record with attestationCount == 0 means the endpoint has no public score. Treat it as unknown, not as zero.

Limitations

• Not yet deployed. No VIGIL record exists in any registry today.
• Latency. A record can lag the live aggregate by up to 24 h when the score is stable. Agents that need the current value should use the read API and verify against the registry periodically.
• One writer. Records are only as trustworthy as the aggregator key. The content hash makes omissions detectable after the fact; it does not stop a compromised key from writing a wrong score until it is rotated. See Security and risks.
• Unclaimed endpoints. Endpoints observed but never registered have no provider identity. Their scores are valid; the attribution features are not.
• Standard maturity. ERC-8004 may change before launch. The content hash scheme will be versioned so old records remain verifiable.
• Not a validation record. VIGIL does not write to the Validation Registry. Escrow check results are per-payment and are not recorded there.