[BEP-620] Trustless Agents on BNB Chain: Identity, Reputation & Validation Registries

BEP
,
1

Hello BNB Chain community :waving_hand:,

This thread introduces BEP-620: Trustless Agents, a Standards BEP that brings the ERC-8004 “Trustless Agents” model to BNB Smart Chain (BSC) and optionally opBNB.

The goal is to define a chain-native way to discover, trust, and validate AI agents across organizations, while keeping costs low enough for high-frequency usage.

We are sharing the draft here to collect feedback before moving it forward in the BEP process.

1. TL;DR

  • What: A new standard on BNB Chain defining three registries:

    • Identity Registry – ERC-721-based agent identity + registration file

    • Reputation Registry – on-chain feedback for agents, with optional off-chain details

    • Validation Registry – generic hooks to record independent validation of agent work

  • Why: MCP & A2A define how agents talk and expose capabilities, but not how users can trust & discover them in adversarial environments.

  • Where: BSC (and optionally opBNB) as the primary network, leveraging low gas fees and high TPS for frequent feedback & validation.

  • How: Compatible with ERC-8004 deployments on Ethereum and other EVM chains; agents can build cross-chain identity and reputation.

2. Motivation

Agent ecosystems are evolving fast:

  • MCP lets servers expose prompts, tools, and resources.

  • A2A enables authentication, skill advertisement (AgentCards), messaging, and task lifecycle orchestration.

But discovery and trust are still unsolved in untrusted, cross-organizational settings:

  • How do I discover agents across chains and organizations?

  • How do I know if an agent is reliable, or if its capabilities are legit?

  • How do I attach feedback, validation, and payment evidence in a composable way?

BNB Smart Chain is a strong fit:

  • 2000 TPS and very low gas costs ($0.001/tx) make it feasible to:

    • Submit feedback frequently

    • Record multiple validation steps

    • Run agent-heavy applications without breaking UX

BEP-620 proposes a minimal but extensible standard to cover:

  1. Who is this agent? → Identity Registry

  2. What do others think of it? → Reputation Registry

  3. Has anyone independently validated its work? → Validation Registry

Payments (e.g. x402) are deliberately kept orthogonal, but integrated via references in feedback files.

3. High-Level Design

3.1 Identity Registry (ERC-721 + URIStorage)

  • Each agent is an ERC-721 token on BSC:

    • namespace: eip155

    • chainId: e.g. 56 for BSC Mainnet

    • identityRegistry: address of this ERC-721 contract

    • agentId: tokenId (incremental)

  • tokenURI → Agent Registration File, e.g.:

  • The registration file follows the ERC-8004 format, e.g.:

    • Basic NFT-compatible fields: type, name, description, image

    • endpoints: list of A2A, MCP, OASF, ENS, DID, agentWallet, etc.

    • registrations: references to registry + agentId across chains

    • supportedTrust: e.g. [“reputation”, “crypto-economic”, “tee-attestation”]

  • The registry also supports extra on-chain metadata:

function getMetadata(uint256 agentId, string key) external view returns (bytes)
function setMetadata(uint256 agentId, string key, bytes value) external
  • Emitting:
event MetadataSet(uint256 indexed agentId, string indexed indexedKey, string key, bytes value);
  • Agents are created via register(…) functions, emitting:
event Registered(uint256 indexed agentId, string tokenURI, address indexed owner);

Result:

Any ERC-721-compatible app can browse, list, trade, and display agents like NFTs, while the registration file links into the AI/MCP/A2A world.

3.2 Reputation Registry

This registry defines a standard way to attach feedback signals to agents.

  • Deployed with a reference to the Identity Registry:
function getIdentityRegistry() external view returns (address identityRegistry);

  • Agents authorize feedback via a signed feedbackAuth:

    • Tuple: (agentId, clientAddress, indexLimit, expiry, chainId, identityRegistry, signerAddress)

    • Signed via EIP-191 or ERC-1271

    • Protects against unauthorized feedback and supports pre-authorized multiple submissions (e.g. watchtowers)

3.2.1 Giving Feedback

function giveFeedback(
    uint256 agentId,
    uint8 score,          // 0–100
    bytes32 tag1,
    bytes32 tag2,
    string calldata fileuri,
    bytes32 calldata filehash,
    bytes memory feedbackAuth
) external;

  • score is mandatory; tags and file info are optional.

  • Off-chain file (e.g. IPFS / Greenfield JSON) can contain:

    • Task context, skills, MCP tools used

    • A2A task descriptors

    • x402 payment proof (fromAddress, toAddress, txHash, etc.)

Emits:

event NewFeedback(
    uint256 indexed agentId,
    address indexed clientAddress,
    uint8 score,
    bytes32 indexed tag1,
    bytes32 tag2,
    string fileuri,
    bytes32 filehash
);

Core fields (except file URI/hash) are stored on-chain to enable composable reputation systems.

3.2.2 Revoking Feedback

function revokeFeedback(uint256 agentId, uint64 feedbackIndex) external;

Emits:

event FeedbackRevoked(uint256 indexed agentId, address indexed clientAddress, uint64 indexed feedbackIndex);

3.2.3 Appending Responses

function appendResponse(
    uint256 agentId,
    address clientAddress,
    uint64 feedbackIndex,
    string calldata responseUri,
    bytes32 calldata responseHash
) external;

Emits:

event ResponseAppended(
    uint256 indexed agentId,
    address indexed clientAddress,
    uint64 feedbackIndex,
    address indexed responder,
    string responseUri
);

This enables:

  • Agents to show refunds or clarifications

  • Off-chain intelligence services to mark feedback as spam, etc.

3.2.4 Read Functions

The registry exposes several read APIs like:

  • getSummary(agentId, clientAddresses, tag1, tag2) → (count, averageScore)

  • readFeedback(…), readAllFeedback(…), getResponseCount(…)

  • getClients(agentId), getLastIndex(agentId, clientAddress)

Design intent:

On-chain we get shared, minimal, composable signals.

Off-chain, specialized services can build advanced scoring models and reviewer reputation.

3.3 Validation Registry

The Validation Registry is about independent verification of agent work, e.g.:

  • Stake-secured re-execution

  • zkML verification

  • TEE-based oracles

  • Specialized auditor networks

It is deployed with a reference to the Identity Registry (getIdentityRegistry()).

3.3.1 Validation Request

function validationRequest(
    address validatorAddress,
    uint256 agentId,
    string requestUri,
    bytes32 requestHash
) external;

  • MUST be called by agent owner / operator.

  • requestUri points to inputs/outputs needed for verification.

  • requestHash is a commitment (optional for IPFS-style URIs).

Emits:

event ValidationRequest(
    address indexed validatorAddress,
    uint256 indexed agentId,
    string requestUri,
    bytes32 indexed requestHash
);

3.3.2 Validation Response

function validationResponse(
    bytes32 requestHash,
    uint8 response,       // 0–100
    string responseUri,
    bytes32 responseHash,
    bytes32 tag
) external;

  • MUST be called by the original validatorAddress.

  • response can be:

    • Binary (0 = fail, 100 = pass), or

    • Graded (0–100 spectrum)

Emits:

event ValidationResponse(
    address indexed validatorAddress,
    uint256 indexed agentId,
    bytes32 indexed requestHash,
    uint8 response,
    string responseUri,
    bytes32 tag
);

Several progressive validation patterns are possible (e.g. “soft finality”, “hard finality” via tag).

3.3.3 Read Functions

Key read APIs include:

  • getValidationStatus(requestHash)

  • getSummary(agentId, validatorAddresses, tag)

  • getAgentValidations(agentId)

  • getValidatorRequests(validatorAddress)

Incentives & slashing are out-of-scope for this BEP and left to the specific validation protocols.

4. Rationale

  • Protocol-agnostic: Works with MCP, A2A, and any future agent protocols by linking to a flexible registration file that can list any endpoints.

  • Composable signals: Reputation and validation data are on-chain, indexable, and filterable, while the semantics and scoring models can evolve off-chain.

  • Low-cost operations: BSC (and opBNB) make frequent feedback & validations economically feasible.

  • Indexing-friendly: On-chain pointers + IPFS/BNB Greenfield storage fit nicely with subgraphs and other indexing stacks.

  • Cross-chain compatibility: Fully compatible with ERC-8004 on Ethereum and other EVM chains. Agents can:

    • Be registered on multiple chains

    • Aggregate feedback and validation signals in a multi-chain ecosystem

5. Backwards Compatibility

  • BEP-620 does not modify existing BSC protocol behavior.

  • Identity Registry is ERC-721 compatible and works with existing NFT tooling.

  • Existing applications can adopt this standard incrementally, without migration.

6. Security Considerations (Summary)

  • Sybil / spam: Pre-authorization (feedbackAuth) reduces but does not remove Sybil risk. Higher-level reputation systems for reviewers are expected to emerge.

  • Audit integrity: On-chain pointers + hashes are immutable, preserving audit trails.

  • Capability verification:

    • BEP-620 guarantees link between on-chain agent identity and off-chain registration file.

    • It does not guarantee capabilities are correct or non-malicious; that’s the role of:

      • Reputation

      • Validation

      • TEE attestation / external security frameworks

  • Self-feedback prevention: The Reputation Registry is designed so agent owners/operators cannot rate themselves.

7. Reference Implementation

A reference implementation is available at:

GitHub - erc-8004/erc-8004-contracts: Registry contracts curated by the 8004 team

The contracts include:

  • Identity Registry (ERC-721 + URIStorage)

  • Reputation Registry

  • Validation Registry

All content is licensed under CC0.

8. Questions for the Community

We’d love feedback from the BNB Chain community on the following points:

  1. Deployment scope

    • BSC-only first, or parallel deployment on opBNB from day one?

  2. Integration with existing projects

    Are there MCP / A2A / agent frameworks on BNB Chain that would like to integrate early?

Call for feedback

All comments, questions, and critiques are very welcome — especially from:

  • dApp teams building with MCP / A2A / ERC-8004

  • Security / validator / zk / TEE protocol teams

If there’s strong community support, we’ll proceed with refining BEP-620 and pushing it through the official BEP workflow.

Thanks for reading :folded_hands:

Looking forward to your feedback on BEP-620: Trustless Agents.

1 Like