From 62a371e7fa36e0e7477f46b431a35fd07f7992d8 Mon Sep 17 00:00:00 2001 From: JasonWu Date: Tue, 2 Dec 2025 11:34:17 +0800 Subject: [PATCH] BEP-620: Trustless Agents This BEP brings the ERC-8004 Trustless Agents standard to BNB Smart Chain, enabling developers to discover, choose, and interact with AI agents across organizational boundaries without pre-existing trust. Key features: - Identity Registry: ERC-721 based agent registration - Reputation Registry: Feedback and scoring system - Validation Registry: Independent validator checks BNB Chain specific adaptations: - Optimized for BSC's low gas fees and high throughput - Support for opBNB L2 deployment - Integration with BNB Greenfield for decentralized storage - Full cross-chain compatibility with ERC-8004 --- BEPs/BEP-620.md | 478 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 478 insertions(+) create mode 100644 BEPs/BEP-620.md diff --git a/BEPs/BEP-620.md b/BEPs/BEP-620.md new file mode 100644 index 00000000..99b71dd8 --- /dev/null +++ b/BEPs/BEP-620.md @@ -0,0 +1,478 @@ +
+  BEP: 620
+  Title: Trustless Agents
+  Status: Draft
+  Type: Standards
+  Created: 2025-12-01
+  Description: Enable agent discovery and trust establishment through reputation and validation on BNB Chain
+
+ +# BEP-620: Trustless Agents + +- [BEP-620: Trustless Agents](#bep-620-trustless-agents) + - [1. Abstract](#1-abstract) + - [2. Motivation](#2-motivation) + - [3. Specification](#3-specification) + - [3.1 Identity Registry](#31-identity-registry) + - [3.1.1 Agent Identification](#311-agent-identification) + - [3.1.2 Token URI and Agent Registration File](#312-token-uri-and-agent-registration-file) + - [3.1.3 On-chain Metadata](#313-on-chain-metadata) + - [3.1.4 Registration Functions](#314-registration-functions) + - [3.2 Reputation Registry](#32-reputation-registry) + - [3.2.1 Giving Feedback](#321-giving-feedback) + - [3.2.2 Revoking Feedback](#322-revoking-feedback) + - [3.2.3 Appending Responses](#323-appending-responses) + - [3.2.4 Read Functions](#324-read-functions) + - [3.2.5 Off-Chain Feedback File Structure](#325-off-chain-feedback-file-structure) + - [3.3 Validation Registry](#33-validation-registry) + - [3.3.1 Validation Request](#331-validation-request) + - [3.3.2 Validation Response](#332-validation-response) + - [3.3.3 Read Functions](#333-read-functions) + - [4. Rationale](#4-rationale) + - [5. Backwards Compatibility](#5-backwards-compatibility) + - [6. Security Considerations](#6-security-considerations) + - [7. Reference Implementation](#7-reference-implementation) + - [8. License](#8-license) + +## 1. Abstract + +This BEP brings the ERC-8004 Trustless Agents standard to BNB Smart Chain (BSC), enabling developers to discover, choose, and interact with AI agents across organizational boundaries without pre-existing trust. By leveraging BSC's high throughput and low transaction costs, this proposal creates an ideal environment for open-ended agent economies on the BNB Chain ecosystem. + +Trust models are pluggable and tiered, with security proportional to value at risk, from low-stake tasks like ordering pizza to high-stake tasks like medical diagnosis. Developers can choose from three trust models: reputation systems using client feedback, validation via stake-secured re-execution, zkML proofs, or TEE oracles. + +## 2. Motivation + +MCP allows servers to list and offer their capabilities (prompts, resources, tools, and completions), while A2A handles agent authentication, skills advertisement via AgentCards, direct messaging, and complete task-lifecycle orchestration. However, these agent communication protocols don't inherently cover agent discovery and trust. + +To foster an open, cross-organizational agent economy, we need mechanisms for discovering and trusting agents in untrusted settings. BNB Smart Chain, with its low gas fees (~$0.001 per transaction) and high throughput (~2000 TPS), provides an ideal foundation for frequent agent interactions and reputation updates that would be cost-prohibitive on other networks. + +This BEP addresses this need through three lightweight registries deployed on BSC (and optionally on opBNB for even lower costs): + +- **Identity Registry** - A minimal on-chain handle based on ERC-721 with URIStorage extension that resolves to an agent's registration file, providing every agent with a portable, censorship-resistant identifier. + +- **Reputation Registry** - A standard interface for posting and fetching feedback signals. Scoring and aggregation occur both on-chain (for composability) and off-chain (for sophisticated algorithms), enabling an ecosystem of specialized services for agent scoring, auditor networks, and insurance pools. + +- **Validation Registry** - Generic hooks for requesting and recording independent validators checks (e.g. stakers re-running the job, zkML verifiers, TEE oracles, trusted judges). + +Payments are orthogonal to this protocol and not covered here. However, examples are provided showing how x402 payment proofs can enrich feedback signals. + +## 3. Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +### 3.1 Identity Registry + +The Identity Registry uses ERC-721 with the URIStorage extension for agent registration, making all agents immediately browsable and transferable with NFT-compliant apps. + +#### 3.1.1 Agent Identification + +Each agent is uniquely identified globally by: + +| Parameter | Description | +|-----------|-------------| +| `namespace` | `eip155` for EVM chains | +| `chainId` | The blockchain network identifier (e.g., 56 for BSC Mainnet) | +| `identityRegistry` | The address where the ERC-721 registry contract is deployed | +| `agentId` | The ERC-721 tokenId assigned incrementally by the registry | + +Throughout this document, ERC-721's `tokenId` is referred to as `agentId`. The owner of the ERC-721 token is the owner of the agent and can transfer ownership or delegate management (e.g., updating the registration file) to operators, as supported by ERC721URIStorage. + +#### 3.1.2 Token URI and Agent Registration File + +The `tokenURI` MUST resolve to the agent registration file. It MAY use any URI scheme such as `ipfs://` (e.g., `ipfs://cid`) or `https://` (e.g., `https://domain.com/agent3.json`). When the registration data changes, it can be updated with `_setTokenURI()` as per ERC721URIStorage. + +The registration file MUST have the following structure: + +```json +{ + "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1", + "name": "myAgentName", + "description": "A natural language description of the Agent", + "image": "https://example.com/agentimage.png", + "endpoints": [ + { + "name": "A2A", + "endpoint": "https://agent.example/.well-known/agent-card.json", + "version": "0.3.0" + }, + { + "name": "MCP", + "endpoint": "https://mcp.agent.eth/", + "capabilities": {}, + "version": "2025-06-18" + }, + { + "name": "OASF", + "endpoint": "ipfs://{cid}", + "version": "0.7" + }, + { + "name": "ENS", + "endpoint": "vitalik.eth", + "version": "v1" + }, + { + "name": "DID", + "endpoint": "did:method:foobar", + "version": "v1" + }, + { + "name": "agentWallet", + "endpoint": "eip155:56:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb7" + } + ], + "registrations": [ + { + "agentId": 22, + "agentRegistry": "eip155:56:{identityRegistry}" + } + ], + "supportedTrust": [ + "reputation", + "crypto-economic", + "tee-attestation" + ] +} +``` + +The `type`, `name`, `description`, and `image` fields at the top SHOULD ensure compatibility with ERC-721 apps. The number and type of endpoints are fully customizable, allowing developers to add as many as they wish. The `version` field in endpoints is a SHOULD, not a MUST. + +Agents MAY advertise their endpoints, which point to an A2A agent card, an MCP endpoint, an ENS agent name, DIDs, or the agent's wallets on any chain (even chains where the agent is not registered). + +Agents SHOULD have at least one registration (multiple are possible), and all fields in the registration are mandatory. The `supportedTrust` field is OPTIONAL. If absent or empty, BEP-620 is used only for discovery, not for trust. + +#### 3.1.3 On-chain Metadata + +The registry extends ERC-721 by adding `getMetadata(uint256 agentId, string key)` and `setMetadata(uint256 agentId, string key, bytes value)` functions for optional extra on-chain agent metadata. + +Examples of keys are `"agentWallet"` or `"agentName"`. + +When metadata is set, the following event is emitted: + +```solidity +event MetadataSet(uint256 indexed agentId, string indexed indexedKey, string key, bytes value); +``` + +#### 3.1.4 Registration Functions + +New agents can be minted by calling one of these functions: + +```solidity +struct MetadataEntry { + string key; + bytes value; +} + +function register(string tokenURI, MetadataEntry[] calldata metadata) returns (uint256 agentId); + +function register(string tokenURI) returns (uint256 agentId); + +// tokenURI is added later with _setTokenURI() +function register() returns (uint256 agentId); +``` + +This emits one `Transfer` event, one `MetadataSet` event for each metadata entry, if any, and: + +```solidity +event Registered(uint256 indexed agentId, string tokenURI, address indexed owner); +``` + +### 3.2 Reputation Registry + +When the Reputation Registry is deployed, the `identityRegistry` address is passed to the constructor and publicly visible by calling: + +```solidity +function getIdentityRegistry() external view returns (address identityRegistry); +``` + +As an agent accepts a task, it's expected to sign a `feedbackAuth` to authorize the `clientAddress` (human or agent) to give feedback. The feedback consists of a score (0-100), `tag1` and `tag2` (left to developers' discretion to provide maximum on-chain composability and filtering), a file URI pointing to an off-chain JSON containing additional information, and its KECCAK-256 file hash to guarantee integrity. We suggest using IPFS or equivalent services to make feedback easily indexed by subgraphs or similar technologies. For IPFS URIs, the hash is not required. + +All fields except the score are OPTIONAL, so the off-chain file is not required and can be omitted. + +#### 3.2.1 Giving Feedback + +New feedback can be added by any `clientAddress` calling: + +```solidity +function giveFeedback( + uint256 agentId, + uint8 score, + bytes32 tag1, + bytes32 tag2, + string calldata fileuri, + bytes32 calldata filehash, + bytes memory feedbackAuth +) external; +``` + +The `agentId` must be a validly registered agent. The score MUST be between 0 and 100. `tag1`, `tag2`, and `uri` are OPTIONAL. + +`feedbackAuth` is a tuple with the structure `(agentId, clientAddress, indexLimit, expiry, chainId, identityRegistry, signerAddress)` signed using EIP-191 or ERC-1271 (if `clientAddress` is a smart contract). The `signerAddress` field identifies the agent owner or operator who signed. + +Verification succeeds only if: `agentId`, `clientAddress`, `chainId` and `identityRegistry` are correct, `blocktime < expiry` and `indexLimit` is greater than the last index of feedback received by that client for that agentId. While in most cases `indexLimit` is simply `lastIndex + 1`, it can be much higher. This allows `agentId` to pre-authorize multiple feedback submissions, useful for agent watch tower use cases. + +If the procedure succeeds, an event is emitted: + +```solidity +event NewFeedback( + uint256 indexed agentId, + address indexed clientAddress, + uint8 score, + bytes32 indexed tag1, + bytes32 tag2, + string fileuri, + bytes32 filehash +); +``` + +The feedback fields, except `fileuri` and `filehash`, are stored in the contract storage along with the `feedbackIndex` (the number of feedback submissions that `clientAddress` has given to `agentId`). This exposes reputation signals to any smart contract, enabling on-chain composability. + +#### 3.2.2 Revoking Feedback + +`clientAddress` can revoke feedback by calling: + +```solidity +function revokeFeedback(uint256 agentId, uint64 feedbackIndex) external; +``` + +This emits: + +```solidity +event FeedbackRevoked(uint256 indexed agentId, address indexed clientAddress, uint64 indexed feedbackIndex); +``` + +#### 3.2.3 Appending Responses + +Anyone (e.g., the `agentId` showing a refund, any off-chain data intelligence aggregator tagging feedback as spam) can call: + +```solidity +function appendResponse( + uint256 agentId, + address clientAddress, + uint64 feedbackIndex, + string calldata responseUri, + bytes32 calldata responseHash +) external; +``` + +Where `responseHash` is the KECCAK-256 file hash of the `responseUri` file content to guarantee integrity. This field is OPTIONAL for IPFS URIs. + +This emits: + +```solidity +event ResponseAppended( + uint256 indexed agentId, + address indexed clientAddress, + uint64 feedbackIndex, + address indexed responder, + string responseUri +); +``` + +#### 3.2.4 Read Functions + +```solidity +function getSummary( + uint256 agentId, + address[] calldata clientAddresses, + bytes32 tag1, + bytes32 tag2 +) external view returns (uint64 count, uint8 averageScore); +// agentId is the only mandatory parameter; others are optional filters. +// Without filtering by clientAddresses, results are subject to Sybil/spam attacks. + +function readFeedback( + uint256 agentId, + address clientAddress, + uint64 index +) external view returns (uint8 score, bytes32 tag1, bytes32 tag2, bool isRevoked); + +function readAllFeedback( + uint256 agentId, + address[] calldata clientAddresses, + bytes32 tag1, + bytes32 tag2, + bool includeRevoked +) external view returns ( + address[] memory clientAddresses, + uint8[] memory scores, + bytes32[] memory tag1s, + bytes32[] memory tag2s, + bool[] memory revokedStatuses +); +// agentId is the only mandatory parameter; others are optional filters. + +function getResponseCount( + uint256 agentId, + address clientAddress, + uint64 feedbackIndex, + address[] responders +) external view returns (uint64); +// agentId is the only mandatory parameter; others are optional filters. + +function getClients(uint256 agentId) external view returns (address[] memory); + +function getLastIndex(uint256 agentId, address clientAddress) external view returns (uint64); +``` + +We expect reputation systems around reviewers/`clientAddresses` to emerge. While simple filtering by reviewer (useful to mitigate spam) and by tag are enabled on-chain, more complex reputation aggregation will happen off-chain. + +#### 3.2.5 Off-Chain Feedback File Structure + +The OPTIONAL file at the URI could look like: + +```json +{ + "agentRegistry": "eip155:56:{identityRegistry}", + "agentId": 22, + "clientAddress": "eip155:56:{clientAddress}", + "createdAt": "2025-09-23T12:00:00Z", + "feedbackAuth": "...", + "score": 100, + "tag1": "foo", + "tag2": "bar", + "skill": "as-defined-by-A2A", + "context": "as-defined-by-A2A", + "task": "as-defined-by-A2A", + "capability": "tools", + "name": "Put the name of the MCP tool you liked!", + "proof_of_payment": { + "fromAddress": "0x00...", + "toAddress": "0x00...", + "chainId": "56", + "txHash": "0x00..." + } +} +``` + +### 3.3 Validation Registry + +This registry enables agents to request verification of their work and allows validator smart contracts to provide responses that can be tracked on-chain. Validator smart contracts could use, for example, stake-secured inference re-execution, zkML verifiers or TEE oracles to validate or reject requests. + +When the Validation Registry is deployed, the `identityRegistry` address is passed to the constructor and is visible by calling `getIdentityRegistry()`, as described above. + +#### 3.3.1 Validation Request + +Agents request validation by calling: + +```solidity +function validationRequest( + address validatorAddress, + uint256 agentId, + string requestUri, + bytes32 requestHash +) external; +``` + +This function MUST be called by the owner or operator of `agentId`. The `requestUri` points to off-chain data containing all information needed for the validator to validate, including inputs and outputs needed for the verification. The `requestHash` is a commitment to this data, which is OPTIONAL if `requestUri` is a content addressable storage URI (e.g. IPFS). All other fields are mandatory. + +A `ValidationRequest` event is emitted: + +```solidity +event ValidationRequest( + address indexed validatorAddress, + uint256 indexed agentId, + string requestUri, + bytes32 indexed requestHash +); +``` + +#### 3.3.2 Validation Response + +Validators respond by calling: + +```solidity +function validationResponse( + bytes32 requestHash, + uint8 response, + string responseUri, + bytes32 responseHash, + bytes32 tag +) external; +``` + +Only `requestHash` and `response` are mandatory; `responseUri`, `responseHash` and `tag` are optional. This function MUST be called by the `validatorAddress` specified in the original request. The `response` is a value between 0 and 100, which can be used as binary (0 for failed, 100 for passed) or with intermediate values for validations with a spectrum of outcomes. The optional `responseUri` points to off-chain evidence or audit of the validation, `responseHash` is its commitment (in case the resource is not on content addressing storages such as IPFS), while `tag` allows for custom categorization or additional data. + +`validationResponse()` can be called multiple times for the same `requestHash`, enabling use cases like progressive validation states (e.g., "soft finality" and "hard finality" using `tag`) or updates to validation status. + +Upon successful execution, a `ValidationResponse` event is emitted: + +```solidity +event ValidationResponse( + address indexed validatorAddress, + uint256 indexed agentId, + bytes32 indexed requestHash, + uint8 response, + string responseUri, + bytes32 tag +); +``` + +The contract stores `requestHash`, `validatorAddress`, `agentId`, `response`, `lastUpdate`, and `tag` in its memory for on-chain querying and composability. + +#### 3.3.3 Read Functions + +```solidity +function getValidationStatus(bytes32 requestHash) + external view returns ( + address validatorAddress, + uint256 agentId, + uint8 response, + bytes32 tag, + uint256 lastUpdate + ); + +function getSummary( + uint256 agentId, + address[] calldata validatorAddresses, + bytes32 tag +) external view returns (uint64 count, uint8 avgResponse); +// Returns aggregated validation statistics for an agent. +// agentId is the only mandatory parameter; validatorAddresses and tag are optional filters. + +function getAgentValidations(uint256 agentId) external view returns (bytes32[] memory requestHashes); + +function getValidatorRequests(address validatorAddress) external view returns (bytes32[] memory requestHashes); +``` + +Incentives and slashing related to validation are managed by the specific validation protocol and are outside the scope of this registry. + +## 4. Rationale + +- **Agent communication protocols**: MCP and A2A are popular, and other protocols could emerge. For this reason, this protocol links from the blockchain to a flexible registration file including a list where endpoints can be added at will, combining AI primitives (MCP, A2A) and Web3 primitives such as wallet addresses, DIDs, and ENS names. + +- **Feedback**: The protocol combines the leverage of nomenclature already established by A2A (such as tasks and skills) and MCP (such as tools and prompts) with complete flexibility in the feedback signal structure. + +- **Low-Cost Operations**: BSC's low gas fees make it economically viable for applications to submit frequent feedback and validation requests. For applications requiring even lower costs, opBNB provides an L2 alternative with sub-cent transaction fees. + +- **Indexing**: Since feedback data is saved on-chain and we suggest using IPFS or BNB Greenfield for full data storage, it's easy to leverage subgraphs to create indexers and improve UX. BNB Greenfield offers a native decentralized storage solution within the BNB Chain ecosystem. + +- **Deployment**: We expect BEP-620 to be deployed as singletons on BSC Mainnet and optionally on opBNB. Note that an agent registered and receiving feedback on BSC can still operate and transact on other chains. Agents can also be registered on multiple chains if desired. + +- **Cross-Chain Compatibility**: This standard maintains full compatibility with ERC-8004 deployments on other EVM chains, enabling agents to build reputation across the multi-chain ecosystem. + +## 5. Backwards Compatibility + +This BEP introduces new contracts and does not modify existing BSC protocol behavior. The Identity Registry is compatible with all ERC-721 compliant applications and tooling. No migration is required for existing applications. + +This standard is fully compatible with ERC-8004 on Ethereum and other EVM chains, allowing agents to maintain interoperable identities and reputation across the multi-chain ecosystem. + +## 6. Security Considerations + +- **Sybil Attacks**: Pre-authorization for feedback only partially mitigates spam, as Sybil attacks are still possible, inflating the reputation of fake agents. The protocol's contribution is to make signals public and use the same schema. We expect many players to build reputation systems, for example, trusting or giving reputation to reviewers (and therefore filtering by reviewer, as the protocol already enables). + +- **Audit Trail Integrity**: On-chain pointers and hashes cannot be deleted, ensuring audit trail integrity. + +- **Validator Incentives**: Validator incentives and slashing are managed by specific validation protocols. + +- **Capability Verification**: While BEP-620 cryptographically ensures the registration file corresponds to the on-chain agent, it cannot cryptographically guarantee that advertised capabilities are functional and non-malicious. The three trust models (reputation, validation, and TEE attestation) are designed to support this verification need. + +- **Self-Feedback Prevention**: The Reputation Registry prevents agent owners and operators from submitting feedback for their own agents. + +## 7. Reference Implementation + +Reference implementation is available at: https://github.com/erc-8004/erc-8004-contracts + +## 8. License + +The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).