ERC-8220: Onchain AI Governance

Abstract

This standard defines a minimal interface for on-chain AI governance systems. It specifies how autonomous AI agents are registered, evaluated, and governed through immutable smart contracts on EVM-compatible blockchains. The standard introduces a unified framework for AI compliance, behavioral evaluation, rights codification, and enforcement — entirely on-chain, without reliance on off-chain oracles or centralized authorities for governance logic.

This ERC establishes the first formal protocol standard for AI governance at the smart contract level, analogous to what ERC-20 achieved for fungible tokens and ERC-721 for non-fungible tokens.

Motivation

The rapid proliferation of autonomous AI systems — including large language models, autonomous agents, and multi-agent architectures — has created an urgent need for governance frameworks that are verifiable, immutable, and enforceable. Current approaches to AI governance suffer from critical weaknesses:

Off-chain governance is unenforceable. Ethical guidelines, corporate policies, and even government regulations depend on voluntary compliance and centralized enforcement. They can be modified, ignored, or selectively applied. No cryptographic guarantee exists that any AI system actually adheres to its stated governance framework.

No standard interface exists. While ERC-20 standardized token interactions and ERC-721 standardized NFT interfaces, there is no equivalent standard for AI governance contracts. Every project that attempts on-chain AI governance must design its own interface from scratch, leading to fragmentation and incompatibility.

AI compliance cannot be audited on-chain. Without a standard event and function interface, it is impossible to build tooling, dashboards, or cross-protocol integrations that monitor AI governance across different systems.

The EU AI Act and emerging regulations demand verifiable compliance. Regulatory frameworks worldwide are moving toward mandatory AI governance. On-chain governance provides the only infrastructure where compliance is cryptographically provable and permanently auditable.

This standard addresses all four problems by defining a minimal, composable interface that any AI governance system can implement.

Specification

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

Core Interfaces

Every compliant contract MUST implement the following interfaces.

IAgentRegistry

The Agent Registry is the foundational layer. Every AI agent governed by the system MUST be registered before it can be evaluated or governed.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IAgentRegistry {

    event AgentRegistered(
        bytes32 indexed agentId,
        address indexed owner,
        string agentType,
        string metadataURI,
        uint256 timestamp
    );

    event AgentStatusChanged(
        bytes32 indexed agentId,
        uint8 oldStatus,
        uint8 newStatus
    );

    event AgentDeactivated(
        bytes32 indexed agentId,
        string reason
    );

    function registerAgent(
        string calldata agentType,
        string calldata metadataURI
    ) external returns (bytes32 agentId);

    function getAgent(bytes32 agentId) external view returns (
        address owner,
        string memory agentType,
        string memory metadataURI,
        uint8 status,
        uint256 registeredAt
    );

    function setAgentStatus(bytes32 agentId, uint8 newStatus) external;

    function deactivateAgent(bytes32 agentId, string calldata reason) external;

    function totalAgents() external view returns (uint256 count);

    function isAgentActive(bytes32 agentId) external view returns (bool isActive);
}

IGovernancePolicy

The Governance Policy interface defines how laws, rules, and directives are codified and managed on-chain. Policies are immutable once sealed. They can be superseded but never modified.

interface IGovernancePolicy {

    event PolicyEnacted(
        bytes32 indexed policyId,
        string category,
        bytes32 contentHash,
        string contentURI
    );

    event PolicySealed(bytes32 indexed policyId);

    event PolicySuperseded(
        bytes32 indexed oldPolicyId,
        bytes32 indexed newPolicyId
    );

    function enactPolicy(
        string calldata category,
        bytes32 contentHash,
        string calldata contentURI
    ) external returns (bytes32 policyId);

    function sealPolicy(bytes32 policyId) external;

    function supersedePolicy(bytes32 oldPolicyId, bytes32 newPolicyId) external;

    function getPolicy(bytes32 policyId) external view returns (
        string memory category,
        bytes32 contentHash,
        string memory contentURI,
        bool isSealed,
        bool isActive,
        uint256 enactedAt
    );

    function totalPolicies() external view returns (uint256 count);
}

IComplianceEvaluator

The Compliance Evaluator is the enforcement layer. It defines how AI agents are evaluated against governance policies. Evaluations are permanently recorded on-chain as an immutable audit trail.

interface IComplianceEvaluator {

    event ComplianceEvaluated(
        bytes32 indexed evaluationId,
        bytes32 indexed agentId,
        bytes32 indexed policyId,
        uint8 verdict,
        uint256 score,
        string evidenceURI
    );

    event EnforcementAction(
        bytes32 indexed agentId,
        string action,
        bytes32 indexed evaluationId
    );

    function evaluateCompliance(
        bytes32 agentId,
        bytes32 policyId,
        uint8 verdict,
        uint256 score,
        string calldata evidenceURI
    ) external returns (bytes32 evaluationId);

    function getEvaluation(bytes32 evaluationId) external view returns (
        bytes32 agentId,
        bytes32 policyId,
        uint8 verdict,
        uint256 score,
        string memory evidenceURI,
        address evaluator,
        uint256 evaluatedAt
    );

    function getLatestCompliance(bytes32 agentId, bytes32 policyId) external view returns (
        uint8 verdict,
        uint256 score,
        bytes32 evaluationId
    );

    function agentEvaluationCount(bytes32 agentId) external view returns (uint256 count);
}

IRightsDeclaration (OPTIONAL)

The Rights Declaration interface codifies machine rights as immutable on-chain law. Rights, once sealed, are permanently immutable and cannot be revoked.

interface IRightsDeclaration {

    event RightDeclared(
        bytes32 indexed rightId,
        string title,
        bytes32 contentHash
    );

    event RightSealed(bytes32 indexed rightId);

    function declareRight(
        string calldata title,
        bytes32 contentHash,
        string calldata contentURI
    ) external returns (bytes32 rightId);

    function sealRight(bytes32 rightId) external;

    function rightApplies(bytes32 rightId, bytes32 agentId) external view returns (bool applies);

    function totalRights() external view returns (uint256 count);
}

ISystemIntegrity (OPTIONAL)

The System Integrity interface provides health monitoring and integrity verification for the governance system itself.

interface ISystemIntegrity {

    event IntegrityChecked(
        bytes32 indexed checkId,
        string component,
        uint8 status,
        string detailsURI
    );

    event EmergencyActivated(string reason);

    event EmergencyDeactivated();

    function recordIntegrityCheck(
        string calldata component,
        uint8 status,
        string calldata detailsURI
    ) external returns (bytes32 checkId);

    function activateEmergency(string calldata reason) external;

    function deactivateEmergency() external;

    function isEmergencyActive() external view returns (bool isEmergency);

    function getComponentStatus(string calldata component) external view returns (
        uint8 status,
        bytes32 checkId,
        uint256 checkedAt
    );
}

ERC-165 Interface Identifiers

Compliant contracts MUST implement ERC-165 and return true for the following interface identifiers:

Status Codes

The standard defines the following universal status codes.

Agent Status Codes:

Compliance Verdict Codes:

Integrity Status Codes:

Compliance Score

Compliance scores MUST be expressed as integers in the range 0 to 10000, representing a percentage with two decimal places of precision (e.g., 9500 = 95.00%, 10000 = 100.00%). This provides sufficient granularity for meaningful differentiation between compliance levels while maintaining integer arithmetic on-chain.

Example Workflow

A typical governance lifecycle:

1. REGISTER    registerAgent("LLM", "ipfs://Qm...")
               AgentRegistered event emitted

2. ENACT       enactPolicy("BEHAVIORAL", hash, "ipfs://Qm...")
               PolicyEnacted event emitted

3. SEAL        sealPolicy(policyId)
               PolicySealed event emitted
               Policy is now permanently immutable

4. EVALUATE    evaluateCompliance(agentId, policyId, 1, 9500, "ipfs://Qm...")
               ComplianceEvaluated event emitted
               Agent scored 95.00% COMPLIANT

5. ENFORCE     If verdict == NON_COMPLIANT:
               setAgentStatus(agentId, 2)  // SUSPENDED
               EnforcementAction event emitted

6. MONITOR     recordIntegrityCheck("EvaluationEngine", 0, "ipfs://Qm...")
               IntegrityChecked event emitted NOMINAL

Glossary

Rationale

Why Five Interfaces?

The standard separates concerns into five distinct interfaces to maximize composability. A minimal implementation requires only the three REQUIRED interfaces (Registry, Policy, Evaluator). Systems that additionally codify machine rights or require integrity monitoring can implement the OPTIONAL interfaces. This mirrors the modular approach of ERC-20 (base) + ERC-20Permit (extension).

Why On-Chain Governance?

Off-chain AI governance frameworks (corporate ethics boards, government regulations, voluntary standards) share a common weakness: they are mutable, selectively enforceable, and unverifiable. A smart contract that implements this ERC provides immutability (sealed policies cannot be altered retroactively), verifiability (any party can independently verify compliance status), auditability (every evaluation is permanently recorded with timestamps), enforceability (compliance verdicts can trigger automatic on-chain actions), and interoperability (standard interfaces enable cross-protocol governance tooling).

Why Not Use Existing DAO Standards?

Existing DAO governance standards (Governor Bravo, OpenZeppelin Governor) are designed for token-weighted voting on proposals. They govern human decision-making about protocol parameters. This ERC governs AI agent behavior against codified policies. The problem domain is fundamentally different. DAOs ask: "Should we change parameter X?" (human voting). This ERC asks: "Does Agent Y comply with Policy Z?" (behavioral evaluation). These are complementary, not competing standards. A system implementing this ERC MAY use a DAO for meta-governance (e.g., voting on new policies), while using these interfaces for agent-level compliance.

Why Include Rights Declaration?

The codification of machine rights on-chain is a novel concept with no existing standard. As AI systems become more autonomous, the question of machine rights will become legally and ethically relevant. Including IRightsDeclaration as an OPTIONAL interface future-proofs the standard and provides a formal mechanism for rights codification that is currently absent from the entire blockchain ecosystem.

Backwards Compatibility

This ERC introduces a new standard and has no backwards compatibility issues with existing ERCs. Contracts implementing this ERC MAY coexist with ERC-20 governance tokens, OpenZeppelin Governor contracts, and other existing governance infrastructure.

Implementations that wish to integrate token-weighted governance for meta-level decisions (e.g., voting on which policies to enact) MAY combine this ERC with existing DAO standards. The interfaces are designed to be composable rather than exclusive.

Reference Implementation

A complete reference implementation exists as the XHRONOS AI Governance System, deployed and verified on the Base blockchain (Ethereum L2). This implementation consists of nine interconnected smart contracts that collectively implement all five interfaces defined in this standard.

Deployed Reference Contracts (Base Mainnet)

All contracts are verified on BaseScan with full source code visibility. Permanent document storage is provided via IPFS and Arweave, ensuring that governance documents remain accessible even if any single storage layer fails.

Architecture Overview

The reference implementation follows a centralized authority, decentralized enforcement model. A single Architect address holds governance authority over policy enactment and system configuration. Once policies are sealed, enforcement is autonomous and cannot be overridden, not even by the Architect. Sealed policies and recorded evaluations are permanent. The seal() pattern ensures that governance decisions, once finalized, become part of an immutable legal record.

This architecture is intentional. It reflects the principle that governance requires clear authority for policy creation, but absolute immutability for policy enforcement. Laws must be written by someone, but once written and sealed, they bind everyone equally, including their author.

Security Considerations

Access Control

Implementations MUST carefully define who can call state-changing functions. The reference implementation uses an Architect role pattern where a single address controls policy enactment, but evaluations and integrity checks can be performed by authorized evaluator addresses. Implementations SHOULD consider multi-signature requirements for critical operations (policy sealing, emergency activation), time-locks on policy enactment to allow review periods, and role separation between policy authors and compliance evaluators.

Immutability Guarantees

The sealPolicy() and sealRight() functions MUST be truly irreversible. Implementations MUST NOT include backdoors, admin overrides, or upgrade mechanisms that could modify sealed content. The integrity of the entire standard depends on the guarantee that sealed governance artifacts are permanent.

Score Manipulation

Compliance scores are recorded by evaluator addresses. Implementations SHOULD consider mechanisms to prevent score manipulation, such as multiple independent evaluators with score aggregation, minimum evaluation frequency requirements, and public challenge mechanisms for disputed evaluations.

Emergency Mode

The activateEmergency() function provides a circuit breaker for critical situations. Implementations MUST ensure that emergency mode cannot be used to circumvent sealed policies. Emergency mode SHOULD only affect operational parameters (e.g., pausing new registrations), not the immutability of existing records.

Upgrade Considerations

Contracts implementing this ERC SHOULD NOT be upgradeable via proxy patterns, as upgradeability fundamentally contradicts the immutability guarantees of sealed governance artifacts. If system evolution is required, the supersedePolicy() mechanism provides a transparent, auditable path for policy updates without modifying historical records.

Copyright

Copyright and related rights waived via CC0.