ERC-8240: Trust Infrastructure for Agents and Assets

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 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 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) carry no metadata about the underlying asset.

This standard addresses all five gaps with interfaces that are composable with existing standards (ERC-8004, ERC-3643, ERC-4626) 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."

/// @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 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.

/// @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.

/// @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.

/// @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.

/// @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)

Compliant contracts MUST implement ERC-165 and return true for the interface identifiers of all supported interfaces.

// 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 (Trustless Agents): An ERC-8004 agent identity can be the subject of an IAttestation. The ERC-8004 Reputation Registry provides free-text feedback; IAttestation provides structured, signed, machine-readable factual statements. The two are complementary — ERC-8004 answers "who is this agent?", this standard answers "what has this agent done, who is accountable, and what is the risk context?"

ERC-8183 (Agentic Commerce): The ERC-8183 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 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 (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 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 (uRWA — Universal Real World Asset Interface): ERC-7943 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 MAY consume IAttestation.getAttestation() within their canTransfer() logic to incorporate factual risk data into transfer decisions.

ERC-8106 (RWA Event-based Compliance Framework): ERC-8106 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 events may reference.

Composability with DeFi Infrastructure Standards

ERC-4626 (Tokenized Vaults): An ERC-4626 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 (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 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.