tip-8126.md

June 5, 2026 · View on GitHub

tip: 8126
title: AI Agent Verification
description: Multi-layer security verification and 0–100 risk scoring for AI agents registered via TRC-8004, with attestations posted to the TRC-8004 Validation Registry
author: yanghang8612@gmail.com
discussions-to: https://github.com/tronprotocol/tips/issues/832
status: Final
type: Standards Track
category: TRC
created: 2026-03-13
requires: TRC-712, TRC-721, TRC-3009, TRC-8004

Abstract

This TIP defines a standard interface for verifying AI agents on TRON that have been registered via TRC-8004, through five specialized verification types — Ethereum Token Verification (ETV), Media Content Verification (MCV), Solidity Code Verification (SCV), Web Application Verification (WAV), and Wallet Verification (WV). Verification executes off-chain and is committed on-chain: providers generate Zero-Knowledge Proofs through Private Data Verification (PDV), accompany each result with a unified 0–100 risk score, and post attestations to TRC-8004's Validation Registry rather than maintaining a separate registry. The standard is the TRON adaptation of ERC-8126, scoped so that TRC-8004 owns agent identity and discovery while this standard owns AI-specific security assessment and risk scoring.

Motivation

As AI agents begin to operate autonomously on TRON — holding wallets, calling contracts, and transacting on a user's behalf — a standardized way to assess "how safe is it to interact with this agent?" becomes foundational trust infrastructure. TRC-8004 already provides portable, TRC-721-based agent identities, discovery, and an on-chain Validation Registry, and that identity layer is gaining real ecosystem traction (e.g. TronScan's native TRC-8004 SCAN support). What is missing is a security-assessment layer on top of identity.

This standard fills that gap by providing:

Multi-layer verification — five specialized types assessing distinct security dimensions of an agent.
Privacy-first, off-chain architecture — verification runs off-chain and only a commitment (risk score plus a ZKP Proof ID) is written on-chain, so TRON does not need a native zk or data-availability stack to adopt the standard.
Unified 0–100 risk scoring — a single comparable score and tiered guidance across providers and agents.
Composability with TRC-8004 — results are posted to TRC-8004's Validation Registry, making them immediately queryable through existing infrastructure instead of fragmenting trust across a new registry.

Relationship to ERC-8126 and TRC-8004

This TIP adapts ERC-8126 to TRON. The encoding, the five verification types, the 0–100 scoring, the PDV/ZKP privacy model, and the optional Quantum Cryptography Verification (QCV) follow ERC-8126; the differences are confined to a TRON profile:

Identity and registry — agents are identified and resolved through TRC-8004 (the TRON counterpart of ERC-8004), and verification attestations are posted to TRC-8004's Validation Registry via its validationResponse interface. TRC-8126 is therefore a specialized security-verification provider within the TRC-8004 ecosystem, not a competing registry. This resolves the fragmentation concern raised for the Ethereum standards: TRC-8004 answers "who is this agent?", TRC-8126 answers "how safe is it to interact with?".
Addresses — TRON addresses are encoded as the 20-byte form after stripping the 0x41 prefix, consistent with TRC-712; Base58Check is used only for display.
Chain binding — request signatures bind the TRC-712 chainId value, block.chainid & 0xffffffff, together with the verifyingContract, so a request cannot replay across networks or across two verifier contracts on the same network.
Contract-presence checks — on-chain bytecode checks (ETV, SCV) use the FullNode contract-code query (wallet/getcontract, or the eth_getCode JSON-RPC endpoint) instead of Ethereum's eth_getCode.
Payments — verification fees use TRC-3009 gasless, TRC-712-signed transfers of TRON stablecoins (e.g. USDD, USDT) instead of ERC-3009/USDC.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Definitions

Term	Definition
Agent Wallet	TRON address controlled by the AI agent
AI Agent	Autonomous software entity identified by a TRC-8004 Identity Registry token
ETV	Ethereum Token Verification — validates smart-contract legitimacy
MCV	Media Content Verification — validates media authenticity and provenance
SCV	Solidity Code Verification — validates code security
WAV	Web Application Verification — checks endpoint security
WV	Wallet Verification — assesses wallet history and threat status
PDV	Private Data Verification — generates ZKPs from verification results
QCV	Quantum Cryptography Verification — optional quantum-resistant encryption
Proof ID	Unique identifier of the ZKP generated during verification
Risk Score	Value 0–100 indicating assessed risk (0 = lowest, 100 = highest)
Verification Provider	Service implementing ETV/MCV/SCV/WAV/WV and PDV (optionally QCV)

Verification Flow

A verification provider MUST:

Accept an agentId (the TRC-721 token id from the TRC-8004 Identity Registry).
Call tokenURI(agentId) on the canonical TRC-8004 Identity Registry contract.
Resolve the returned URI and fetch the agent registration JSON.
Extract the metadata fields it needs (walletAddress/agentWallet, chainId, contractAddress, endpoints/url, imageUrl, solidityCode).
Execute every applicable verification type against the resolved metadata.
Reject any request that supplies individual parameters without an agentId.

Verification Types

Each type MUST produce a risk score in [0, 100]. A type applies only when its triggering metadata field is present.

ETV (when contractAddress is present): MUST confirm contractAddress is deployed on chainId (bytecode ≠ 0x), and MUST check it against known vulnerability patterns. SHOULD follow the OWASP Smart Contract Security Verification Standard (SCSVS).
MCV (when imageUrl is present): SHOULD perform forensic analysis for AI-generated/synthetic media and deepfakes, MUST verify content provenance and embedded metadata, MUST check for tampering, and MUST validate digital watermarks/steganographic payloads/signatures where present. SHOULD use the C2PA Implementation Guide.
SCV (when solidityCode is present): MUST confirm the referenced code is deployed on chainId (bytecode ≠ 0x), and MUST check for common vulnerabilities (reentrancy, flash-loan attacks). SHOULD follow OWASP SCSVS.
WAV (always, using resolved endpoints): MUST verify the HTTPS endpoint responds, MUST validate the TLS certificate, and MUST check common web vulnerabilities. SHOULD follow the OWASP Web Security Testing Guide (WSTG).
WV (always, using the resolved agent wallet): MUST verify the wallet has transaction history on TRON and MUST check it against threat-intelligence databases.

Risk Scoring

The overall risk score is the mean of all applicable type scores.

Tier	Range	Meaning
Low	0–20	Minimal concerns
Moderate	21–40	Some concerns, review recommended
Elevated	41–60	Notable concerns, caution advised
High	61–80	Significant concerns
Critical	81–100	Severe concerns, avoid interaction

Integration with the TRC-8004 Validation Registry

TRC-8126 does not introduce its own registry. Consistent with ERC-8126, verification providers MAY post final risk scores and PDV Proof IDs as attestations to TRC-8004's Validation Registry using its pluggable validation interface, enabling portable, discoverable security attestations alongside the reputation signals TRC-8004 already tracks.

Concretely, a verifier acts as a validatorAddress and commits a result through the Validation Registry's existing flow: the agent (or its operator) opens a request with validationRequest(validatorAddress, agentId, requestURI, requestHash), and the verifier answers with validationResponse(requestHash, response, responseURI, responseHash, tag). The risk score and the PDV Proof ID are carried in the attestation, with the off-chain evidence referenced by responseURI and committed by responseHash; the tag SHOULD be set to "trc-8126" so consumers can filter TRC-8126 attestations via getSummary(agentId, validatorAddresses, "trc-8126"). This makes TRC-8126 scores queryable through the same infrastructure that already surfaces TRC-8004 data.

Off-Chain Verification and PDV

Verification executes off-chain to eliminate gas costs, allow complex logic, let criteria evolve without contract upgrades, and enable competing providers. Results are processed through PDV, which generates a ZKP so that the verification can be proven without exposing the underlying sensitive data — the on-chain footprint is only the commitment (the risk score plus the Proof ID), which is what makes the standard adoptable on TRON without a native zk or data-availability layer. Providers MAY additionally apply QCV (e.g. AES-256-GCM or an equivalent post-quantum scheme) for long-term confidential storage of verification records, returning a record_id and an authorized decryption_url.

Payment

Providers MAY charge fees. When they do, they MUST disclose the fee structure before verification, SHOULD settle in a TRON stablecoin (e.g. USDD, USDT), and SHOULD accept gasless payment via TRC-3009 transferWithAuthorization, so the user signs a TRC-712 authorization and the provider (or a relayer) submits it.

Error Codes

Implementations MUST use the following standardized error codes:

Code	Name	Description
0x01	InvalidAddress	Invalid TRON address provided
0x02	InvalidURL	Malformed or non-HTTPS URL
0x03	AgentNotFound	No agent exists with the specified `agentId`
0x04	VerificationFailed	Verification provider error
0x05	InsufficientCredits	No verification credits available
0x06	InvalidProof	PDV proof validation failed
0x07	ProviderUnavailable	Verification provider not responding
0x08	InvalidScore	Risk score outside `[0, 100]`
0x09	ContractNotFound	Specified contract nonexistent on chain
0x0A	SolidityCodeNotFound	Specified Solidity code nonexistent
0x0B	ImageNotFound	Image could not be resolved or fetched
0x0C	SteganographyFailed	Steganographic payload extraction failed
0x0D	MediaVerificationFailed	General media integrity/provenance failure

Optional On-Chain Interface

This standard is primarily off-chain. Providers or integrators MAY implement an on-chain component to record scores, emit events, or expose the latest result. The RECOMMENDED interface, adapted for TVM:

interface ITRC8126 {
    event AgentVerified(
        uint256 indexed agentId,
        uint8 overallRiskScore,
        bytes32 etvProofId,
        bytes32 mcvProofId,
        bytes32 scvProofId,
        bytes32 wavProofId,
        bytes32 wvProofId,
        bytes32 summaryProofId
    );

    event AttestationPosted(
        uint256 indexed agentId,
        uint8 riskScore,
        bytes32 proofId
    );

    function getLatestRiskScore(uint256 agentId) external view returns (uint8);
}

Recommended error definitions:

error InvalidAddress();
error InvalidURL();
error AgentNotFound();
error VerificationFailed();
error InsufficientCredits();
error InvalidProof();
error ProviderUnavailable();
error InvalidScore();
error ContractNotFound();
error SolidityCodeNotFound();
error ImageNotFound();
error SteganographyFailed();
error MediaVerificationFailed();

Rationale

Provider within TRC-8004, not a new registry. Posting risk scores and Proof IDs to TRC-8004's Validation Registry (rather than minting a parallel identity/registry surface) keeps agent identity in one place, avoids duplicated discovery, and makes TRC-8126 scores immediately visible to TRC-8004-aware tooling.
Off-chain verification, on-chain commitment. The heavy verification logic (and any sensitive inputs) stays off-chain; only a ZKP-backed commitment lands on-chain. This is precisely what lets TRON adopt the standard today without first building native zk-infrastructure or DA layers.
TRC-712 for request authorization. Using TRC-712 typed data — with the truncated chainId and verifyingContract bound into the domain — gives human-readable signing prompts and prevents cross-network / cross-contract replay, the TRON-equivalent of the EIP-712/191/155 trio the source ERC relies on.
Five verification types and a 0–100 score are retained unchanged from ERC-8126 so that providers and tooling built for the Ethereum standard port to TRON with only the profile substitutions above, and so scores remain directly comparable across ecosystems.

V1 Scope

Consistent with the discussion on #832, the immediate goal is specification only:

This TIP defines the verification methodology, the risk-scoring model, the TRC-8004 Validation Registry integration (posting risk scores and Proof IDs as attestations), the error codes, and the optional on-chain interface.
A reference implementation is a natural next step once providers exist, but is not in scope for V1.
Bootstrapping a TRON off-chain verification-provider ecosystem — covering all five layers, with incentive and payment flows — is an open ecosystem task that needs dedicated follow-up; it is intentionally left outside the normative standard so the interface is not coupled to any single provider.

Backwards Compatibility

This standard introduces new verification behavior without modifying any existing standard. It requires agents to be registered via TRC-8004, which provides the TRC-721-based identity and tokenURI metadata resolution this standard consumes. Agents already registered via TRC-8004 are verifiable without changes; agents using bespoke registration would migrate by minting in the TRC-8004 Identity Registry with compatible metadata.

Security Considerations

Point-in-time guarantee. A verification reflects checks passed at a moment in time; it does not guarantee an agent's future behavior. Risk scores are guidance, not a substitute for independent judgment.
Wallet and URL compromise. A compromised agent wallet enables impersonation, and a hijacked agent URL can serve malicious content after registration. WV/WAV re-verification detects these; consumers SHOULD check current status before high-value interactions.
Contract risk. ETV/SCV provide initial signal only; independent audits are still warranted for contracts an agent interacts with.
ZKP soundness. PDV implementations SHOULD use audited proof systems with trusted-setup ceremonies and battle-tested verifiers. Elliptic-curve ZKPs (and ECDSA signatures) are vulnerable to future quantum attacks; high-value, long-lived proofs SHOULD consider QCV symmetric encryption, which remains quantum-resistant.
Provider trust and collusion. Providers differ in thoroughness and independence and could collude with a malicious agent; high-stakes interactions SHOULD obtain attestations from multiple independent providers. The PDV proof lets a third party independently validate a claimed result.
Sybil resistance. Cheap creation of many agents in TRC-8004 is mitigated by minting cost and by the reputation signals TRC-8004 tracks.
Dependency on TRC-8004. Reliance on TRC-8004 registries introduces a dependency: implementations MUST use the canonical deployed registry addresses and MUST verify the integrity of resolved tokenURI data before acting on it.