--- eip: 8240 title: Trust Infrastructure for Agents and Assets description: Interfaces for factual attestations, decision trails, accountability, risk signals, and asset passports across chains. author: Patrick Nicolas Badoux (@nicobernad) discussions-to: https://ethereum-magicians.org/t/erc-8240-trust-infrastructure-for-agents-and-assets/28322 status: Draft type: Standards Track category: ERC created: 2026-04-22 requires: 165 --- ## Abstract This ERC defines five composable interfaces for trust infrastructure in autonomous agent economies and tokenized asset markets: 1. **IAttestation** (MUST) — Structured, signed, verifiable factual statements about agents and assets. 2. **IDecisionTrail** (SHOULD) — Immutable audit trail for agent decisions and actions. 3. **IAccountability** (SHOULD) — Dispute resolution, liability chains, evaluator scoring, and optional coverage. 4. **IRiskSignal** (SHOULD) — Cross-chain risk propagation and regime detection. 5. **IRWAPassport** (MAY) — Machine-readable identity and risk profile for tokenized assets. These interfaces are independent of any specific bridge protocol, chain ecosystem, or AI framework. They are designed to be consumed by autonomous AI agents without human intermediation. ## Motivation The tokenized asset market exceeds $27B on-chain (April 2026), with projections of $16T by 2030. Over 150,000 autonomous agents operate on BNB Chain alone, with 24,000+ registered on [ERC-8004](./eip-8004.md) registries. These agents execute financial operations — lending, trading, rebalancing, compliance — with increasing autonomy. No standard exists for: - **Factual attestation**: How an agent or oracle publishes a verifiable, structured statement about an asset or another agent. Current approaches use free-text feedback ([ERC-8004](./eip-8004.md) Reputation Registry) or proprietary formats. - **Decision traceability**: How an agent records the rationale for its actions in a format that regulators, auditors, and other agents can consume. MiCA (EU) requires audit trails for automated financial decisions — no on-chain standard exists. - **Accountability**: Who is responsible when an autonomous agent causes financial loss. No standard defines liability chains, dispute resolution mechanisms, or evaluator track records. - **Cross-chain risk**: How a risk event on chain A propagates to positions on chain B. Current cross-chain infrastructure (CCIP, LayerZero, Wormhole) transports messages but does not attest to the trustworthiness of the contents. - **Asset identity**: How a tokenized real-world asset describes its risk profile in a machine-readable format. Current approaches (BEP-20, [ERC-20](./eip-20.md)) carry no metadata about the underlying asset. This standard addresses all five gaps with interfaces that are composable with existing standards ([ERC-8004](./eip-8004.md), [ERC-3643](./eip-3643.md), [ERC-4626](./eip-4626.md)) without depending on any of them. ### Design Rationale: Products First, Standard Second A standard that requires massive adoption before creating value faces a chicken-and-egg problem. This ERC is designed so that a single implementer deploying a single vault with IAttestation creates measurable value on day one — attestation-gated lending with differentiated rates. The standard is the engine; the products are visible. ## 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. ### Section 1: IAttestation (MUST) A factual, signed, timestamped, contestable statement about an entity (agent or asset). Attestations are **factual, not evaluative**. An attestation states "this agent executed 847 jobs with 92% success rate, certified by 3 evaluators" — never "this agent is trustworthy" or "this asset is high quality." ```solidity /// @title IAttestation /// @notice Factual attestation interface for agents and assets. interface IAttestation { struct Attestation { address subject; // Entity being attested (agent or asset) address attester; // Entity making the attestation uint256 timestamp; // Block timestamp of attestation uint256 value; // Numeric fact (e.g., score 0-1000, success rate bps) bytes32 contextHash; // Hash of off-chain context (methodology, data sources) uint256 nonce; // Replay protection uint256 sourceChainId; // Chain where the fact was computed bytes signature; // EIP-712 or equivalent signature } /// @notice Submit an attestation about an entity. /// @dev MUST verify signature. MUST reject replayed nonces. MUST emit AttestationSubmitted. function submitAttestation(Attestation calldata attestation) external; /// @notice Retrieve the latest attestation for a subject. function getAttestation(address subject) external view returns (Attestation memory); /// @notice Check whether a subject has been attested. function isAttested(address subject) external view returns (bool); /// @notice Verify an attestation signature without submitting. function verifyAttestation(Attestation calldata attestation) external view returns (bool valid); /// @dev MUST be emitted when an attestation is submitted. event AttestationSubmitted( address indexed subject, address indexed attester, uint256 value, uint256 sourceChainId, bytes32 contextHash ); } ``` **Conformance requirements:** - Implementations MUST verify the `signature` field against the `attester` address using [EIP-712](./eip-712.md) typed data or an equivalent scheme. - Implementations MUST reject attestations with a previously-used `nonce` for the same `attester`. - Implementations MUST store `sourceChainId` to enable cross-chain verification. - The `contextHash` SHOULD reference a publicly-accessible document describing the attestation methodology. - Attestations MUST NOT contain evaluative language in any on-chain field. Evaluation is a consumer responsibility. ### Section 2: IDecisionTrail (SHOULD) An immutable, append-only record of decisions made by agents or protocols. ```solidity /// @title IDecisionTrail /// @notice Immutable audit trail for agent and protocol decisions. interface IDecisionTrail { /// @notice Record a decision. /// @param decisionHash Keccak256 of the decision payload (action, params, context). /// @param actionType Categorical identifier (0=REBALANCE, 1=DEPOSIT, 2=WITHDRAW, 3=ALERT, ...). /// @return decisionId Sequential identifier for the recorded decision. function commitDecision(bytes32 decisionHash, uint8 actionType) external returns (uint256 decisionId); /// @notice Retrieve a recorded decision. function getDecision(uint256 decisionId) external view returns ( bytes32 decisionHash, uint8 actionType, address committer, uint256 timestamp ); /// @notice Total number of recorded decisions. function getDecisionCount() external view returns (uint256); /// @dev MUST be emitted on every commitDecision call. event DecisionCommitted( uint256 indexed decisionId, bytes32 indexed decisionHash, address indexed committer, uint8 actionType ); } ``` **Conformance requirements:** - The decision trail MUST be append-only. No deletion or modification of recorded decisions. - `decisionId` MUST be strictly monotonically increasing. - Implementations SHOULD store `block.timestamp` alongside each decision. ### Section 3: IAccountability (SHOULD) Dispute resolution, liability identification, and evaluator track records. ```solidity /// @title IAccountability /// @notice Dispute resolution and liability framework for agent economies. interface IAccountability { enum AppealStatus { NONE, OPEN, RESOLVED_FOR, RESOLVED_AGAINST, EXPIRED } struct Appeal { uint256 appealId; address appellant; // Party filing the dispute address respondent; // Party being disputed bytes32 evidenceHash; // Hash of off-chain evidence AppealStatus status; uint256 createdAt; uint256 resolvedAt; } /// @notice File a dispute against an agent or protocol action. function fileAppeal( address respondent, bytes32 evidenceHash, bytes32 contextHash ) external returns (uint256 appealId); /// @notice Resolve an appeal. MUST be called by an authorized resolver. function resolveAppeal( uint256 appealId, AppealStatus resolution, bytes32 contextHash ) external; /// @notice Retrieve appeal details. function getAppeal(uint256 appealId) external view returns (Appeal memory); /// @notice Retrieve the track record of an evaluator or resolver. /// @return totalResolved Number of appeals resolved by this address. /// @return accuracy Percentage of resolutions not overturned (bps, 10000 = 100%). function getEvaluatorRecord(address evaluator) external view returns ( uint256 totalResolved, uint256 accuracy ); event AppealFiled(uint256 indexed appealId, address indexed appellant, address indexed respondent); event AppealResolved(uint256 indexed appealId, AppealStatus resolution); } ``` **Conformance requirements:** - Appeal resolution MUST be recorded in an IDecisionTrail if available. - Evaluator records MUST be updated on every resolution. - Implementations SHOULD define a bounded resolution period (RECOMMENDED: 48 hours). - Resolution authority MUST be restricted to authorized evaluators, not arbitrary addresses. ### Section 4: IRiskSignal (SHOULD) Cross-chain risk event propagation and system regime detection. ```solidity /// @title IRiskSignal /// @notice Cross-chain risk signal propagation. interface IRiskSignal { enum Regime { STABLE, ELEVATED, CRISIS, CRISIS_FORMING } struct RiskSignal { uint256 compositeIndex; // Aggregate risk index (0-100) Regime regime; // Current system regime uint256 criticalClusters; // Number of correlated risk clusters uint256 timestamp; uint256 sourceChainId; } /// @notice Get current risk signal for this chain or system. function getRiskSignal() external view returns (RiskSignal memory); /// @notice Check if the system is in a crisis regime. function isCrisis() external view returns (bool); /// @notice Propagate a risk signal from another chain. /// @dev Bridge-agnostic: the caller is responsible for transport. This interface /// does not mandate any specific bridge protocol (Constraint 1). function propagateSignal(RiskSignal calldata signal, bytes calldata proof) external; event RiskSignalUpdated(uint256 compositeIndex, Regime regime, uint256 sourceChainId); event SignalPropagated(uint256 sourceChainId, uint256 compositeIndex, Regime regime); } ``` **Conformance requirements:** - `propagateSignal` MUST verify the `proof` parameter before accepting a signal from another chain. The proof format is implementation-defined (allowing any bridge protocol). - `compositeIndex` MUST be computed from observable, reproducible inputs. The methodology SHOULD be documented in a `contextHash` or external reference. - The `Regime` enum values MUST be ordered by severity: STABLE < ELEVATED < CRISIS_FORMING < CRISIS. - Implementations MUST NOT couple signal propagation to a specific bridge protocol. ### Section 5: IRWAPassport (MAY) Machine-readable identity and risk profile for tokenized real-world assets. ```solidity /// @title IRWAPassport /// @notice Machine-readable passport for tokenized assets. interface IRWAPassport { struct AssetPassport { address assetAddress; string assetClass; // "BOND", "EQUITY", "REAL_ESTATE", "STABLECOIN", ... uint256 attestedValue; // Latest attested numeric value (from IAttestation) uint256 confidence; // Attestation confidence (bps, 10000 = 100%) uint256 lastUpdated; bytes32 riskProfileHash; // Hash of off-chain risk profile document } struct RiskLayer { string layerName; // "INTRINSIC", "CONTAGION", "MARKET", "COUNTERPARTY", ... uint256 exposure; // Exposure metric for this layer (implementation-defined) uint256 lastAssessed; } /// @notice Get the passport for an asset. function getPassport(address asset) external view returns (AssetPassport memory); /// @notice Get risk layers for an asset. function getRiskLayers(address asset) external view returns (RiskLayer[] memory); /// @notice Check if an asset has a valid passport. function hasPassport(address asset) external view returns (bool); event PassportUpdated(address indexed asset, uint256 attestedValue, string assetClass); } ``` **Conformance requirements:** - `assetClass` values SHOULD follow a published taxonomy. This standard does not mandate a specific taxonomy. - `riskProfileHash` SHOULD reference a publicly-accessible document. - Implementations MAY support any subset of risk layers. ### Interface Detection ([ERC-165](./eip-165.md)) Compliant contracts MUST implement [ERC-165](./eip-165.md) and return `true` for the interface identifiers of all supported interfaces. ```solidity // Interface IDs (ERC-165) // IAttestation: 0x________ (to be computed) // IDecisionTrail: 0x________ (to be computed) // IAccountability: 0x________ (to be computed) // IRiskSignal: 0x________ (to be computed) // IRWAPassport: 0x________ (to be computed) ``` ## Rationale ### Why Five Interfaces in One ERC The five interfaces are causally linked: 1. An **attestation** (IAttestation) provides the factual basis for action. 2. An action produces a **decision trail** entry (IDecisionTrail). 3. If the action is disputed, the **accountability** framework resolves it (IAccountability). 4. Dispute outcomes update the **risk signal** (IRiskSignal) if systemic. 5. The asset's **passport** (IRWAPassport) reflects the updated risk profile. Implementing any strict subset produces measurably degraded utility. This coupling is intentional — it prevents fragmentation into competing single-purpose standards (see Security Considerations, Constraint 5). The MUST/SHOULD/MAY hierarchy allows incremental adoption: an implementer can start with IAttestation alone and add interfaces as needed. ### Why Factual, Not Evaluative Financial regulators (SEC, MiCA, ACPR) distinguish between factual statements and evaluative ratings. Factual attestations ("executed 847 jobs, 92% success rate") do not require rating agency registration. Evaluative ratings ("this agent is trustworthy") do. This standard uses factual language exclusively to avoid regulatory classification as a rating service. ### Why Bridge-Agnostic IRiskSignal.propagateSignal accepts an opaque `proof` parameter. This design allows signal propagation over any cross-chain messaging protocol (Chainlink CCIP, LayerZero, Wormhole, Hyperlane, Axelar, native bridges) without coupling the standard to any specific provider. ## Backwards Compatibility This ERC introduces new interfaces and does not modify existing standards. ### Composability with Agent Infrastructure Standards **[ERC-8004](./eip-8004.md) (Trustless Agents):** An [ERC-8004](./eip-8004.md) agent identity can be the `subject` of an IAttestation. The [ERC-8004](./eip-8004.md) Reputation Registry provides free-text feedback; IAttestation provides structured, signed, machine-readable factual statements. The two are complementary — [ERC-8004](./eip-8004.md) answers "who is this agent?", this standard answers "what has this agent done, who is accountable, and what is the risk context?" **[ERC-8183](./eip-8183.md) (Agentic Commerce):** The [ERC-8183](./eip-8183.md) Job primitive defines a Client, Provider, and Evaluator for task-based escrow. This standard extends the evaluator concept in three ways: (a) IAttestation standardizes the format of the evaluator's attestation, making it machine-readable and cross-platform comparable; (b) IDecisionTrail records the decision context of the job lifecycle; (c) IAccountability provides a dispute resolution framework when the evaluator's assessment is contested. [ERC-8183](./eip-8183.md) hooks MAY call `IRiskSignal.isCrisis()` to gate job acceptance based on system risk, or `IAttestation.getAttestation()` to verify provider track records before funding. ### Composability with Regulated Asset Standards **[ERC-3643](./eip-3643.md) (T-REX):** A T-REX compliant security token enforces transfer eligibility via ONCHAINID and compliance rules. This standard provides the complementary context layer: IRWAPassport describes the asset's risk profile (which [ERC-3643](./eip-3643.md) does not cover), IAttestation provides factual compliance attestations consumable by T-REX transfer rules, and IDecisionTrail records the audit trail that MiCA requires for automated financial decisions involving regulated tokens. **[ERC-7943](./eip-7943.md) (uRWA — Universal Real World Asset Interface):** [ERC-7943](./eip-7943.md) defines compliance controls (`canTransfer`, `forcedTransfer`, `setFrozenTokens`) as a minimal interface for any RWA token. This standard's IRWAPassport is the natural complement — 7943 answers "is this transfer allowed?" while IRWAPassport answers "what is the risk profile of the asset being transferred?" Implementations of [ERC-7943](./eip-7943.md) MAY consume `IAttestation.getAttestation()` within their `canTransfer()` logic to incorporate factual risk data into transfer decisions. **[ERC-8106](./eip-8106.md) (RWA Event-based Compliance Framework):** [ERC-8106](./eip-8106.md) defines event-driven compliance events with entity classification. IDecisionTrail provides the decision context that triggers these compliance events — not just what happened, but why. IRiskSignal enables cross-chain propagation of compliance-relevant risk signals that [ERC-8106](./eip-8106.md) events may reference. ### Composability with DeFi Infrastructure Standards **[ERC-4626](./eip-4626.md) (Tokenized Vaults):** An [ERC-4626](./eip-4626.md) vault can use IAttestation to gate deposits by attested asset scores, IDecisionTrail to record allocation decisions, and IRiskSignal to trigger protective actions (pause, de-risk) based on system regime. **[ERC-7683](./eip-7683.md) (Cross-chain Intents Standard):** Cross-chain intents that move capital between chains SHOULD verify risk context on both source and destination chains. IRiskSignal provides a bridge-agnostic risk assessment that intent fillers and settlement contracts can consume before executing cross-chain transfers. ### Design Note on Composability This standard does not extend, modify, or depend on any of the above standards. All composability is additive — an implementer can use this standard's interfaces independently or alongside any combination of the above. This design satisfies Constraint 1 (no coupling to specific protocols) and ensures the standard remains functional even if any individual composable standard is deprecated or superseded. No backwards compatibility issues exist. ## Reference Implementation A reference implementation is available at: [repository link to be inserted upon publication] The reference implementation includes: - 26 contracts deployed across 2 chains (Base compute, Gnosis canonical) - 499 tests, 0 failures - Verification script (`verify_alia.py`) providing independent 8-check audit - Cross-chain relay with [EIP-712](./eip-712.md) signed attestations ## Security Considerations ### Constraint 1 — Bridge Orthogonality Attestations MUST be transportable by any cross-chain messaging protocol without modification. Any implementation that couples the standard to a specific bridge fails this constraint. ### Constraint 2 — Fork Resistance Any fork of a reference implementation that does not participate in the canonical registry governance MUST be distinguishable on-chain as non-canonical. ### Constraint 3 — Regulatory Neutrality All attestation language MUST be factual. Terms such as "quality," "rating," "recommendation," or "trustworthy" MUST NOT appear in on-chain attestation data. Evaluative interpretation is a consumer responsibility. ### Constraint 4 — AI-Native Extensibility All interfaces MUST be consumable by autonomous AI agents without human intermediation. This requires strict typed data (no free-text in core fields), machine-parseable structures, and support for AI entities as attesters and evaluators. ### Constraint 5 — Causal Integrity The five interfaces MUST be causally interlinked such that implementing any strict subset produces measurably degraded utility. Proposals that allow clean extraction of a single interface without loss of the trust guarantee fail this constraint. ### Constraint 6 — Implementation Agnosticism The normative sections of this standard MUST NOT reference specific cryptographic primitives (ECDSA, secp256k1), data structures (Merkle Patricia Trie), or execution environments (EVM) except in examples and the Reference Implementation section. Specific primitives appear only in non-normative sections and are replaceable. ### Additional Considerations - **Attestation replay:** Implementations MUST enforce nonce uniqueness per attester to prevent replay attacks. - **Stale data:** Consumers SHOULD define maximum acceptable attestation age. A 15-minute staleness window is RECOMMENDED for financial applications. - **Evaluator collusion:** IAccountability implementations SHOULD use random evaluator selection from a qualified pool to mitigate collusion risk. - **Oracle manipulation:** Attestation values derived from on-chain data inherit the security properties of the underlying oracle. This standard does not provide oracle security — it provides attestation structure. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).