ERC-XXXX: Trust Infrastructure for Autonomous Agents and Tokenized Assets
Discussion thread for a proposed ERC standard.
-
Author: Patrick Nicolas Badoux (patrick@avvatar.io)
-
Status: Draft
-
Type: Standards Track (ERC)
-
Created: 2026-04-22
-
Requires: ERC-165
-
Composable with: ERC-4626, ERC-8004, ERC-3643, ERC-8192
Abstract
This ERC defines five composable interfaces that provide verifiable trust infrastructure for autonomous AI agents and tokenized real-world assets (RWAs). The standard enables any on-chain or off-chain consumer — human, protocol, or AI agent — to query factual, signed, contestable attestations about an asset’s quality or an agent’s track record, trace the decision history behind any autonomous action, resolve disputes through a decentralized tribunal, consume cross-chain risk signals in real time, and read a machine-readable passport for any tokenized real-world asset.
The standard does not define scoring algorithms, risk models, or evaluation methodologies. It defines what trust data looks like — not how it is computed. Implementations are free to use any methodology that produces outputs conforming to these interfaces.
Motivation
The Problem
There are $27B in tokenized assets on-chain today, projected to reach $16T by 2030. Over 122,000 AI agents are registered on BNB Chain alone. BlackRock, Franklin Templeton, and Apollo are tokenizing on public blockchains. Every one of these assets has a price feed. None of them have a quality feed.
Price ≠ quality. An asset can have a high price and catastrophic quality (Luna/UST, 2022). A collateral position can be worth $10M in price and $0 in verifiable quality. An agent can have an ERC-8004 identity and zero track record.
On April 18, 2026, Aave — the largest lending protocol with $22B TVL — absorbed $196M in bad debt from a single tokenized asset (rsETH via Kelp DAO). The asset had a price. It did not have a quality assessment. The dependency chain (custodian, issuer, bridge, oracle) was not being measured continuously by any standard interface. The protocol’s Guardian reaction took 77 minutes. $6.2B left the protocol in 48 hours.
The problem was not the smart contract. The problem was the absence of a standard way to continuously assess the quality of tokenized assets and the trustworthiness of agents operating on them.
Why a Standard
Without standardization, every protocol reinvents trust assessment with incompatible interfaces:
-
Lending protocols cannot compare collateral quality across assets using a common interface
-
AI agents cannot prove their track record portably across chains
-
Regulators (MiCA, EU AI Act) require auditable decision trails that no current standard provides
-
Vault operators cannot gate deposits or execution by quality without custom integrations
-
Cross-chain consumers cannot read trust data created on another chain
This ERC provides the “thin waist” for trust data — a minimal, composable set of interfaces that any implementation can conform to, enabling an ecosystem of interoperable trust consumers and producers.
Products This Standard Enables
The standard is the engine. The products are what consumers build:
-
Quality-gated lending: a vault reads IAttestation to set borrowing terms by collateral quality (AAA = 3%, CCC = 12%) rather than price alone
-
Dynamic structured products: tranches that rebalance automatically when IRiskSignal detects quality changes
-
Quality-weighted indices: asset indices weighted by attestation scores with built-in decay
-
Cross-chain quality arbitrage: same asset on two chains, different quality assessments — detectable only with a standard interface
-
Agent marketplaces: match agents by verifiable track record via IAttestation, with disputes resolved via IAccountability
-
Compliance automation: IDecisionTrail provides the audit trail required by MiCA Article 60 and the EU AI Act for automated decision-making
Specification
The key words “MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT”, and “MAY” are to be interpreted as described in RFC 2119.
Overview
The standard defines five interfaces across two requirement levels:
| Interface |
Purpose |
Level |
IAttestation |
Factual, signed, contestable claims about subjects |
MUST |
IDecisionTrail |
Auditable record of autonomous decisions |
SHOULD |
IAccountability |
Dispute resolution, liability, insurance |
SHOULD |
IRiskSignal |
Cross-chain risk signals and regime detection |
SHOULD |
IRWAPassport |
Machine-readable identity for tokenized assets |
MAY |
A conforming implementation MUST implement IAttestation and ERC-165. All other interfaces are optional but, if implemented, MUST conform to the signatures and semantics defined below.
1. IAttestation (MUST)
Factual, signed, contestable claims. An attestation is never an opinion or recommendation — it is a verifiable measurement: “847 jobs completed, 92% success rate, 3 certified evaluators” — never “good agent.”
solidity
interface IAttestation {
/// @notice A new attestation has been recorded
event AttestationCreated(
bytes32 indexed attestationId,
address indexed subject,
address indexed attester,
uint256 timestamp
);
/// @notice An attestation has been contested
event AttestationContested(
bytes32 indexed attestationId,
address indexed challenger,
bytes32 disputeId
);
/// @notice Record a factual attestation about a subject
/// @param subject The address being attested (asset, agent, or protocol)
/// @param factHash A keccak256 commitment to the factual claim data
/// @param score A numeric quality measurement (0-1000)
/// @param confidence The attester's confidence in the measurement (0-100)
/// @param signature EIP-712 typed signature by the attester
/// @return attestationId Unique identifier for this attestation
function attest(
address subject,
bytes32 factHash,
uint256 score,
uint256 confidence,
bytes calldata signature
) external returns (bytes32 attestationId);
/// @notice Retrieve the current attestation for a subject
/// @param subject The address to query
/// @return score Current quality score (0-1000)
/// @return confidence Confidence level (0-100)
/// @return timestamp When the attestation was last updated
/// @return attester Who created the attestation
function getAttestation(address subject)
external
view
returns (
uint256 score,
uint256 confidence,
uint256 timestamp,
address attester
);
/// @notice Check if an attestation is still fresh (not decayed)
/// @param subject The address to query
/// @param maxAge Maximum acceptable age in seconds
/// @return fresh Whether the attestation is within maxAge
/// @return age Actual age in seconds
function isFresh(address subject, uint256 maxAge)
external
view
returns (bool fresh, uint256 age);
/// @notice Contest an existing attestation, initiating dispute resolution
/// @param attestationId The attestation being contested
/// @param evidence A keccak256 commitment to counter-evidence
/// @return disputeId Identifier for the resulting dispute
function contest(bytes32 attestationId, bytes32 evidence)
external
returns (bytes32 disputeId);
}
Decay semantics: Implementations SHOULD apply score decay when attestations are not refreshed. The decay model is implementation-defined, but isFresh() MUST accurately reflect whether the attestation meets the caller’s freshness requirement.
Score range: Scores are integers in [0, 1000]. Implementations MUST NOT return values outside this range. The mapping from score to qualitative labels (e.g., AAA, BBB, CCC) is implementation-defined and outside the scope of this standard.
2. IDecisionTrail (SHOULD)
Every autonomous decision recorded on-chain with its context.
solidity
interface IDecisionTrail {
event DecisionRecorded(
uint256 indexed decisionId,
address indexed agent,
uint8 actionType,
uint256 timestamp
);
/// @notice Record an autonomous decision
/// @param decisionHash Commitment to the full decision context
/// @param actionType Enumerated action category
/// @return decisionId Sequential decision identifier
function commit(bytes32 decisionHash, uint8 actionType)
external
returns (uint256 decisionId);
/// @notice Retrieve a recorded decision
/// @param decisionId The decision to query
/// @return agent Who made the decision
/// @return decisionHash The committed context
/// @return actionType The action category
/// @return timestamp When it was recorded
function getDecision(uint256 decisionId)
external
view
returns (
address agent,
bytes32 decisionHash,
uint8 actionType,
uint256 timestamp
);
/// @notice Total number of decisions recorded
function totalDecisions() external view returns (uint256);
}
Compliance note: This interface is designed to satisfy the audit trail requirements of MiCA (Markets in Crypto-Assets Regulation) and the EU AI Act for automated decision-making. Each decision is immutable, timestamped, and attributable to a specific agent.
3. IAccountability (SHOULD)
Dispute resolution, liability identification, and insurance. The first on-chain framework for agent accountability.
solidity
interface IAccountability {
event DisputeFiled(
bytes32 indexed disputeId,
address indexed claimant,
address indexed respondent
);
event VerdictReached(
bytes32 indexed disputeId,
uint8 outcome,
uint256 timestamp
);
/// @notice File a dispute against an agent or evaluator
/// @param respondent The party being disputed
/// @param evidence Commitment to evidence data
/// @param attestationId The attestation in question (if applicable)
/// @return disputeId Unique dispute identifier
function fileDispute(
address respondent,
bytes32 evidence,
bytes32 attestationId
) external returns (bytes32 disputeId);
/// @notice Query the status of a dispute
/// @param disputeId The dispute to query
/// @return status 0=pending, 1=deliberating, 2=resolved, 3=appealed
/// @return outcome 0=undecided, 1=claimant wins, 2=respondent wins, 3=split
/// @return deadline Timestamp by which verdict must be reached
function getDisputeStatus(bytes32 disputeId)
external
view
returns (uint8 status, uint8 outcome, uint256 deadline);
/// @notice Identify the liability chain for a decision
/// @param decisionId A decision from IDecisionTrail
/// @return deployer Who deployed the agent
/// @return operator Who operates the agent
/// @return evaluator Who attested to the agent's quality
function getLiabilityChain(uint256 decisionId)
external
view
returns (
address deployer,
address operator,
address evaluator
);
}
Tribunal mechanics: Implementations that provide dispute resolution SHOULD use a panel of certified evaluators (minimum 3) with time-bounded deliberation (recommended 48 hours). Evaluator selection, scoring, and meta-scoring (scoring the judges) are implementation-defined.
Insurance: Implementations MAY include an insurance pool that compensates verified claims. The pool mechanics (premiums, coverage, payout triggers) are implementation-defined.
4. IRiskSignal (SHOULD)
Cross-chain risk signals with regime detection. Bridge-agnostic by design.
solidity
interface IRiskSignal {
event RegimeChanged(
uint8 indexed previousRegime,
uint8 indexed newRegime,
uint256 criValue,
uint256 timestamp
);
event RiskAlert(
address indexed subject,
uint8 severity,
bytes32 alertHash,
uint256 timestamp
);
/// @notice Get the current system risk regime
/// @return regime 0=STABLE, 1=ELEVATED, 2=CRISIS_FORMING, 3=CRISIS
/// @return criGlobal Composite risk index (0-100)
/// @return criStructural Topology concentration index (0-100)
/// @return criActive Cascade signal index (0-100)
/// @return lastUpdated Timestamp of last regime evaluation
function getRegime()
external
view
returns (
uint8 regime,
uint256 criGlobal,
uint256 criStructural,
uint256 criActive,
uint256 lastUpdated
);
/// @notice Check if a specific subject is under risk alert
/// @param subject The address to query
/// @return underAlert Whether an active alert exists
/// @return severity Alert severity (0=none, 1=low, 2=medium, 3=high)
/// @return alertHash Commitment to alert details
function getAlert(address subject)
external
view
returns (bool underAlert, uint8 severity, bytes32 alertHash);
/// @notice Get the contagion exposure of a subject
/// @param subject The address to query
/// @return exposureCount Number of dependencies under stress
/// @return maxImpact Worst-case cascade impact (0-100)
function getContagionExposure(address subject)
external
view
returns (uint256 exposureCount, uint256 maxImpact);
}
Regime semantics: The four regimes represent escalating risk states. Consumers (vaults, agents, protocols) SHOULD define behavioral responses to regime changes. For example, a vault MAY block deposits during CRISIS regime (regime == 3).
Cross-chain design: This interface is designed for cross-chain consumption. Risk signals created on one chain SHOULD be readable on other chains via mirror contracts. The bridge mechanism is intentionally unspecified — implementations may use Chainlink CCIP, LayerZero, Hyperlane, or any relay. The standard does not depend on any specific bridge.
5. IRWAPassport (MAY)
Machine-readable identity for tokenized real-world assets. Seven risk layers.
solidity
interface IRWAPassport {
/// @notice Get the full passport for a tokenized asset
/// @param asset The token address
/// @return issuer Address or identifier of the asset issuer
/// @return assetClass Enumerated asset classification
/// @return riskLayers Encoded risk assessment across 7 dimensions
/// @return lastAudit Timestamp of last comprehensive audit
/// @return incidentCount Number of recorded incidents
function getPassport(address asset)
external
view
returns (
bytes32 issuer,
uint8 assetClass,
bytes32 riskLayers,
uint256 lastAudit,
uint256 incidentCount
);
/// @notice Get a specific risk layer score for an asset
/// @param asset The token address
/// @param layer 0=issuance, 1=counterparty, 2=market, 3=contagion,
/// 4=regulatory, 5=smartContract, 6=operational
/// @return score Risk layer score (0-100)
/// @return confidence Measurement confidence (0-100)
function getRiskLayer(address asset, uint8 layer)
external
view
returns (uint256 score, uint256 confidence);
}
Seven risk layers: The standard defines seven risk dimensions for RWAs: issuance, counterparty, market, contagion, regulatory, smart contract, and operational. Each layer is scored independently (0-100). The aggregation methodology is implementation-defined.
Asset classes: The enumeration of asset classes (e.g., stablecoin, equity, commodity, real estate, DePIN node, infrastructure) is implementation-defined. The standard only requires that implementations use consistent uint8 encoding.
Rationale
Why Five Interfaces, Not One
Trust is not a single dimension. A high-quality asset (good IAttestation) may still be dangerous in a systemic crisis (bad IRiskSignal). An agent with excellent track record may have no accountability framework. Splitting into five interfaces allows consumers to adopt incrementally — a lending protocol may only need IAttestation and IRiskSignal, while a regulated fund may need all five.
Why Factual Attestations, Not Ratings
The standard deliberately avoids the word “rating” or “recommendation.” Attestations are factual measurements: “847 jobs, 92% success rate.” This is a design constraint, not a limitation. Factual attestations are machine-verifiable, contestable, and do not create the conflicts of interest inherent in rating agencies. The 2008 financial crisis demonstrated the failure of opinion-based ratings.
Why On-Chain Dispute Resolution
Off-chain dispute resolution is opaque and non-composable. On-chain disputes via IAccountability create a public, auditable, precedent-setting record. When an evaluator is found to have attested inaccurately, that finding is visible to all consumers forever. This creates a self-correcting incentive system without requiring a central authority.
Why Implementation-Agnostic
The standard defines what trust data looks like, not how it is computed. This is intentional: scoring methodologies, risk models, and evaluation approaches will evolve faster than standards. By standardizing the interface layer, we allow competition between implementations while preserving interoperability for consumers.
Backwards Compatibility
ERC-4626 (Tokenized Vaults)
A vault implementing ERC-4626 can consume IAttestation to gate deposits by collateral quality and IRiskSignal to adjust behavior by risk regime. The interfaces are additive — they do not modify ERC-4626 semantics.
ERC-8004 (Agent Identity)
ERC-8004 provides identity. This standard provides verifiable capability and track record. An ERC-8004 agent identity gains a quality attestation via IAttestation, a portable track record across chains, and a dispute resolution framework via IAccountability. The two standards are composable: identity (8004) + trust (this ERC).
ERC-3643 (Regulated Tokens)
ERC-3643 provides compliance infrastructure for security tokens. IRWAPassport extends this with continuous risk assessment across seven layers. IDecisionTrail provides the audit trail that regulated token operators need for MiCA compliance.
ERC-8192 (Mandated Execution for Tokenized Vaults)
ERC-8192 defines delegated execution with risk bounds for ERC-4626 vaults. This standard operates at the layer above: an ERC-8192 vault SHOULD consume IAttestation to validate executor trustworthiness before granting execution rights, and SHOULD consume IRiskSignal to halt mandated execution during adverse regime conditions (e.g., CRISIS). The two standards are complementary — ERC-8192 answers “how can an agent execute safely?” while this ERC answers “should this agent be trusted to execute, and is the asset it touches sound?”
Security Considerations
Adversarial Constraints
The following six constraints MUST be considered by any implementation:
Constraint 1 — Bridge Independence. The standard MUST NOT depend on any specific cross-chain bridge. If a bridge fails, the trust data on each chain must remain valid independently. Implementations SHOULD support multiple relay mechanisms.
Constraint 2 — Attester Collusion. Implementations MUST consider the risk that attesters collude to inflate scores. Recommended mitigations include: requiring multiple independent attesters, implementing meta-scoring (scoring the scorers), and enforcing decay on attestations from inactive evaluators.
Constraint 3 — Score Manipulation. Attestation scores MUST NOT be manipulable within a single transaction. Implementations SHOULD enforce minimum time delays between score updates and SHOULD use commit-reveal schemes for high-stakes attestations.
Constraint 4 — Regime Gaming. The risk regime (IRiskSignal) MUST NOT be triggerable by a single actor. Implementations SHOULD derive regime from multiple independent data sources and SHOULD implement hysteresis (requiring sustained signals before regime transitions).
Constraint 5 — Pillar Extraction. The five interfaces are designed to be interdependent. An attestation (IAttestation) without accountability (IAccountability) creates unaccountable claims. A risk signal (IRiskSignal) without a decision trail (IDecisionTrail) creates unattributable alerts. Implementations that adopt only a subset SHOULD document which trust guarantees are weakened.
Constraint 6 — Implementation Leakage. The normative sections of this standard MUST NOT contain implementation-specific details (specific cryptographic schemes, proprietary algorithms, or platform-specific constructs). The standard defines interfaces; implementations compete on execution.
Oracle Trust
Consumers of IAttestation and IRiskSignal should be aware that these interfaces surface data produced by off-chain or on-chain evaluation processes. The standard provides contestability (contest() in IAttestation, fileDispute() in IAccountability) as the mechanism for challenging incorrect data, rather than assuming any evaluator is infallible.
Freshness and Decay
Stale trust data is dangerous. The isFresh() function in IAttestation allows consumers to enforce their own freshness requirements. Implementations SHOULD make their decay model transparent and SHOULD emit events when attestations transition freshness tiers.
Reference Implementation
A reference implementation is deployed and operational:
-
Base mainnet (chainId 8453): 19 contracts, including a live ERC-4626 vault with regime detection and auto-lockdown
-
Gnosis Chain (chainId 100): 7 canonical contracts for governance and dispute resolution
-
Test coverage: 439 Solidity tests, 0 failures, 28 test suites
-
Continuous verification: An independent verification script (verify_alia.py) runs 8 checks across both chains
-
Assets monitored: 120+ tokenized assets scored continuously
The reference implementation is available for reviewers upon request. A public documentation site is in preparation.
Verified contract addresses:
| Contract |
Chain |
Address |
| COLOracle (IAttestation) |
Base |
0xe1D56f8DB28C4F257dF4A501e1D304073475ce14 |
| DecisionRegistry (IDecisionTrail) |
Base |
0x7C74b49DDF20063aE935D43c90799E19f10f1C42 |
| ALIAStandardRegistry |
Gnosis |
0xfC9cA736d384D482af5d23CC7616765C66244D29 |
| EvaluatorScoring |
Gnosis |
0x002daE518967a6eADaF71F41e95A1D04DA47bC4A |
| LiabilityResolver (IAccountability) |
Gnosis |
0x8E6434d860A9c83728376E807b6c55C8e3395d2c |
| ALIASwarmAppeal (IAccountability) |
Gnosis |
0x75bFA66024A4810CD82C587706706298a3e2DD7D |
Feedback Requested
-
Interface granularity: Is the split into five interfaces the right level of decomposition, or should IDecisionTrail and IAccountability be merged into a single IAuditability interface?
-
Score range: Is [0, 1000] the right range for attestation scores? Alternatives considered: [0, 100] (simpler but less granular), [0, 10000] (basis points alignment).
-
Regime enum: Are four regime states (STABLE, ELEVATED, CRISIS_FORMING, CRISIS) sufficient, or should the standard allow implementation-defined extensions?
-
Cross-chain canonical model: The reference implementation uses a canonical chain (Gnosis) for governance and compute chains (Base, BNB) for scoring. Should the standard recommend this architecture, or remain silent on deployment topology?
-
Relationship with ERC-8192: Is the composability model described above (this ERC as the trust layer above ERC-8192’s execution layer) the right framing? Would ERC-8192 implementers find this integration useful?
Copyright
Copyright and related rights waived via CC0.
We build 
