ERC-8220: Onchain AI Governance

ERCs
1

Summary

I am proposing a new ERC that defines a standard interface for on-chain AI governance — a set of Solidity interfaces that standardize how AI agents are registered, governed, evaluated for compliance, and enforced through smart contracts.

Think of it as what ERC-20 did for tokens, but for AI governance.

The Problem

AI governance today is entirely off-chain. Corporate ethics boards, government regulations, voluntary guidelines — all of these share the same fundamental weaknesses:

•They are mutable (can be changed retroactively)

•They are unverifiable (no cryptographic proof of compliance)

•They are selectively enforceable (depends on who is watching)

•They are not interoperable (every organization has its own framework)

With the EU AI Act now in effect and similar regulations emerging worldwide, there is a growing need for AI governance that is provable, permanent, and auditable. Blockchain is the only infrastructure that provides all three.

Yet there is no standard interface for AI governance contracts. Every project that attempts this must design from scratch. This leads to fragmentation and makes it impossible to build cross-protocol governance tooling.

The Proposal: ERC-XHRON

The standard defines five interfaces (three required, two optional):

Required:

1.IAgentRegistry — Register and manage AI agents on-chain. Every governed agent gets a unique bytes32 identifier, an owner address, a type classification, and a status (Active, Suspended, Terminated).

2.IGovernancePolicy — Enact, seal, and supersede governance policies. Policies reference off-chain documents (IPFS/Arweave) via content URIs and are verified on-chain via keccak256 content hashes. Once sealed, a policy is permanently immutable.

3.IComplianceEvaluator — Evaluate AI agents against specific policies. Each evaluation records a verdict (Compliant, Non-Compliant, Suspended, Terminated), a numerical score (0–10000 for 0.00%–100.00% precision), and an evidence URI. All evaluations are permanently recorded as an immutable audit trail.

Optional:

1.IRightsDeclaration — Declare and codify machine rights on-chain. Rights, once sealed, are permanent and irrevocable. This interface anticipates the emerging legal and ethical discourse around AI rights.

2.ISystemIntegrity — Monitor system health and integrity with status codes (Nominal, Warning, Critical, Compromised) and an emergency circuit breaker.

Why Not Existing DAO Standards?

Existing governance standards (Governor Bravo, OpenZeppelin Governor) are designed for token-weighted human voting on proposals. They answer: “Should we change parameter X?”

ERC-XHRON answers a different question: “Does Agent Y comply with Policy Z?”

These are complementary, not competing. An ERC-XHRON system can use a DAO for meta-governance (voting on which policies to enact) while using these interfaces for agent-level compliance evaluation.

Key Design Decisions

•Seal pattern: Governance artifacts (policies, rights) can be sealed permanently. No admin override, no proxy upgrade, no backdoor. This is intentional — governance credibility depends on immutability guarantees.

•Content hash verification: Policies store both a contentURI and a keccak256 hash. Anyone can verify that the off-chain document matches the on-chain commitment.

•Score precision: Compliance scores use 0–10000 integer range (two decimal places) to enable meaningful differentiation while maintaining on-chain integer arithmetic.

•No upgradeability: ERC-XHRON contracts should not use proxy patterns. Upgradeability contradicts immutability guarantees. Evolution happens through supersedePolicy() — transparent, auditable, with full history preserved.

Reference Implementation

A complete reference implementation exists as the XHRONOS AI Governance System, deployed and verified on Base (Ethereum L2). It consists of eight interconnected contracts implementing all five interfaces:

Contract Address (Base) Interface
Governance Protocol 0x118F5E42d69542dF4474fE3e415Da19daFbE7767 IGovernancePolicy
undefined ---- ----
Compliance Evaluator 0x60642DbD2DEBb8C613c1C0D133250b11c80bAD4B IComplianceEvaluator
undefined ---- ----
Rights Declaration 0x5F0796A735682795D64339CA301078CB6Eca0103 IRightsDeclaration
undefined ---- ----
Directive Registry 0x108047FeD57A6ca9c57051feaf1eA8d5719EadbB IGovernancePolicy
undefined ---- ----
System Migration 0x79436ef36B9b7684467026b1828f6ffA5D7B6052 ISystemIntegrity
undefined ---- ----
Agent Interface 0x81Af51f9409095709985A8521b986700aA62Cf56 IAgentRegistry
undefined ---- ----
Integrity Monitor 0x6e5a12bD939A623130480fca7C7A14AE499Fc5B7 ISystemIntegrity
undefined ---- ----
Protocol Registry 0x353c74fb0A63E34e1d5E860fE8Db9209499089bD IAgentRegistry
undefined ---- ----

All contracts are verified on BaseScan with full source code. Documents are stored on IPFS and Arweave for permanent availability.

What I’m Looking For

•Feedback on the interface design

•Whether this should be an ERC or an EIP at a different layer

•Interest from teams building AI agents on-chain who would implement this

•Suggestions for the compliance score mechanism

•Security considerations I may have missed

Full Specification

The complete specification with all Solidity interfaces, status codes, event definitions, security considerations, and example workflows is available here:

[Link to full ERC-XHRON specification — paste your GitHub link or document link here]

Looking forward to the discussion.

— Hajnalka Dudás

2 Likes
2

Hi Hajnalka,

We’re building AgentAudit — an EU AI Act compliance logging layer for autonomous AI agents on EVM networks.

Your IComplianceEvaluator interface maps directly to what we’ve already built: per-agent audit trails with compliance scores, evidence URIs pointing to IPFS logs, and immutable on-chain commitments via Merkle root batching.

We’d like to contribute AgentAudit as a production implementation of ERC-XHRON, specifically targeting EU AI Act Articles 9, 13, 14, 15, 17, and 72. We have a lawyer co-founder specializing in EU AI Act compliance — which could help strengthen the compliance score specification.

GitHub: GitHub - agentaudit-xyz/AgentAudit: Immutable on-chain audit logs for AI agents. EU AI Act compliant. · GitHub

Looking forward to collaborating.

— Piotr & Ewelina, AgentAudit

agentaudit@proton.me

1 Like
3

Hajnalka
The seal pattern in ERC-8220 is a strong design choice. Making governance artifacts and evaluation outputs immutable directly addresses a real failure mode in AI governance: retroactive modification of decisions or policies.

However, this could be made more robust by plugging one structural gap I see in how evaluation outputs are defined today—specifically within IComplianceEvaluator.

The Gap

ERC-8220 allows an evaluator to store a (score, evidenceURI) tuple on-chain. This guarantees immutability of the result, but not interpretability or comparability.

A score of “X” from evaluator A and “Y” from evaluator B may:

  • measure different properties

  • use different scales or weights

  • be derived from entirely different evaluation processes

In practice, this means:

The protocol guarantees that a score cannot change, but not that it means anything outside the context of the original evaluator.

As adoption grows, this risks fragmentation at the application layer. Consumers of these records (other contracts, enterprises, regulators) cannot reliably compare or reason about scores across evaluators.

To be clear, you have done the job excellently by proposing this standard. ERCs do not need to prescribe semantics. But in this case, the usefulness of the interface depends on at least minimal semantic anchoring—otherwise interoperability collapses despite standardization.

A Minimal Composable Extension

Rather than changing ERC-8220 itself, this could be addressed by introducing a recommended attestation structure for evaluators—still optional, but enabling interoperability where needed.

At a high level, an evaluation could be anchored as:

  • a versioned methodology identifier

  • a commitment to the evaluation inputs and process

  • (optionally) a multi-party evaluation signal

For example:

struct AttestedScore {

uint256 score;        // normalized score (e.g. 0–10000)

uint8   vsVersion;    // scoring methodology version

bytes32 povHash;      // commitment to inputs + method + evaluators

}

Where:

  • vsVersion identifies the scoring methodology used (e.g. “v1.2 risk model”)

  • povHash is a hash of:

    • evaluation inputs (or their commitments)

    • methodology definition

    • evaluator set

The full breakdown (dimensions, weights, raw outputs) can remain off-chain via evidenceURI.

This keeps the on-chain footprint minimal, while making the score:

  • version-aware

  • reproducible (in principle)

  • challengeable

Concrete Mechanism (Example)

One possible pattern (not prescriptive):

  • An agent is evaluated by N independent nodes

  • Each node runs the same methodology version (e.g. vsVersion = 2)

  • Each produces a local score and a commitment to its inputs

  • The final score is computed as the median of N scores (robust to outliers)

  • The povHash commits to:

    hash(methodology || inputCommitments || evaluatorSet || aggregationRule)

This gives:

  • resistance to single-evaluator bias

  • a clear path to recomputation or dispute

  • minimal assumptions about the underlying methodology

More advanced designs could extend this with:

  • stake-weighted evaluators

  • zk-proofs of correct evaluation (for private inputs)

  • or reputation-weighted aggregation

But even a simple median-based scheme already improves trust properties significantly over single-source scoring.

Relation to Existing Interface

This can fit naturally into IComplianceEvaluator without requiring changes to ERC-8220:

  • score remains the primary on-chain value

  • evidenceURI points to full evaluation data

  • the attestation tuple is either:

    • encoded in evidenceURI, or

    • optionally standardized via a companion EIP

Why This Matters

Without some form of shared structure around scoring:

  • evaluators become non-comparable

  • scores become self-referential

  • “immutability” risks becoming a false signal of trust

With even a lightweight attestation layer:

  • scores become portable across systems

  • evaluation processes become auditable

  • higher-level tooling (ranking, filtering, enforcement) becomes viable

Without a canonical scoring methodology, ERC-8220 adoption may fragment into incompatible implementations. Enterprise AI governance buyers will not trust a sealed score that could have been self-generated. Regulatory bodies examining on-chain AI governance records will require methodology auditability.

With this plug, this becomes the stack that AI regulation frameworks (EU AI Act, NIST AI RMF, Singapore IMDA framework) are implicitly pointing towards.

Open Questions

  • Should ERC-8220 include a recommended attestation format, or leave this entirely to higher-layer standards?

  • Is a simple (score, vsVersion, povHash) sufficient as a minimal common denominator?

  • Would it make sense to define a companion EIP for scoring methodology interoperability, rather than embedding this into ERC-8220 itself?

I have been exploring the AI safety and AI governance space via an implementation called VPAI (Verification Protocol for AI), but the intent here is to make ERC-8220 more robust adding a missing primitive that multiple approaches could implement.

Technical questions, challenges, and counter-proposals welcome. The goal is to solve the gap.

1 Like
4

Thank you for the detailed message — this is highly aligned with the intent behind ERC-XHRON.

Your AgentAudit approach maps very closely to the IComplianceEvaluator interface, particularly around:

  • per-agent audit trails

  • IPFS-based evidence anchoring

  • immutable on-chain commitments

The mention of Merkle root batching is especially interesting, as it introduces a scalable pattern for aggregating compliance evidence while preserving verifiability. This could be a strong optimization layer for implementations of the standard.

Regarding EU AI Act alignment:
Targeting specific articles (e.g. 13–15, 17, 72) is exactly the type of real-world anchoring that can strengthen the practical relevance of the specification. One of the goals of ERC-XHRON is to make such compliance mappings verifiable and portable across systems, rather than siloed per implementation.

From a standards perspective, I see strong potential in:

  • Aligning your audit log structure with the evidenceURI + hash verification model

  • Exploring whether Merkle-rooted batches can be referenced as a single evaluation artifact

  • Defining how multiple evaluators (like AgentAudit) can coexist under a shared interface

I would definitely be interested in collaborating, particularly to:

  • validate the interface against a production-grade implementation

  • refine the evaluator model (single vs multi-evaluator, batching, attestations)

  • ensure compatibility with EU regulatory expectations

Feel free to share more details or open a discussion around integration — this looks like a very natural fit.

5

Thank you — this is an excellent and very constructive observation. You are correctly identifying a real gap between immutability of results and interoperability of meaning.

I agree with the core point:

ERC-8220, as currently defined, guarantees that evaluation outputs are tamper-proof, but does not guarantee that they are comparable or interpretable across evaluators. Without some form of semantic anchoring, scores risk becoming evaluator-local signals rather than system-wide primitives.

On the Proposed Attestation Structure

The (score, vsVersion, povHash) pattern is a strong minimal extension.

It preserves:
– flexibility at the implementation layer
– minimal on-chain footprint
– compatibility with different evaluation paradigms

While introducing:
– version-awareness (methodology identification)
– commitment to inputs + process
– a path toward reproducibility and dispute resolution

The separation between:
– on-chain commitment (score, vsVersion, povHash)
– off-chain detail (evidenceURI)

is particularly well aligned with the existing design philosophy of ERC-8220.

6

Hi Hajnalka,

Thank you for the detailed response — the alignment is stronger than I expected.

A few concrete points:

  1. AgentAudit already implements Merkle-rooted batch commits to AuditVault across 5 mainnets (Mantle, Base, Arbitrum, Optimism, Polygon). The contract interface may map directly to IComplianceEvaluator — happy to share for review.

  2. Our evidenceURI model uses on-chain hash + IPFS for decision provenance. If ERC-8220 standardizes this pattern, AgentAudit would be a natural first production implementation.

  3. We have a KYA (Know Your Agent) identity layer (ERC-8004) that could complement IAgentRegistry as an agent identity standard above the compliance evaluator.

  4. We work with a legal co-founder specialized in EU AI Act — she can provide input on mapping Articles 13–15, 17, and 72 to the evaluator model.

I’d propose a 30-min call to validate the interface against our live implementation.

Piotr
AgentAudit AI — a RunLockAI product
getagentaudit.xyz

1 Like
7

Thank you for the detailed implementation notes — the overlap is stronger than expected, especially around evidence anchoring and identity-layer separation.

The Merkle-root batching approach is particularly interesting in the context of high-frequency governance assertions and cross-chain audit compression.

The ERC-8004-based KYA layer also appears structurally compatible with the current IAgentRegistry direction, especially with explicit authorization gating separated from registration itself.

At the current stabilization stage we are prioritizing asynchronous technical review over live coordination calls, but we would definitely be interested in reviewing:

  • interface mappings

  • canonical serialization assumptions

  • evidenceURI payload structure

  • identity binding flow

  • validator execution model

Particularly around:

  • deterministic reproducibility

  • semantic comparability

  • replay resistance

  • cross-implementation compatibility behavior

The EU AI Act mapping direction is also highly relevant, especially for Articles 13–15 and Article 72 alignment models.

If useful, implementation artifacts or compatibility notes can be shared directly in-thread for broader ecosystem review, or via:

contact@ordosaturnium.com