ERC-8241: Protocol Control Disclosure

ERCs
1

Discussion thread for ERC-8241 Protocol Control Disclosure

ERC-8241 defines a canonical machine-readable interface for structural protocol disclosure while intentionally separating verification, interpretation, and governance analysis into external systems.

eip: 8241

title: Protocol Control Disclosure

description: A canonical machine-readable interface for structural protocol disclosure covering protocol metadata, disclosure commitments, declared components, operational topology references, and retrieval semantics.

author: Chege Cjay ( @chegecjay-rgb )

discussions-to: https://ethereum-magicians.org/t/erc-8241-protocol-control-disclosure/28343

status: Draft

type: Standards Track

category: ERC

created: 2026-04-25

requires: ERC-165

Abstract

This ERC defines a minimal, canonical, machine-readable interface for structural protocol disclosure.

The ERC standardizes disclosure structure and metadata retrieval semantics while intentionally excluding verification logic, governance interpretation, operational judgment, economic safety analysis, and verifier policy.

ERC-8241 defines a declaration layer rather than a verification framework.

The mandatory core standardizes only structural disclosure primitives including:

  • protocol metadata

  • disclosure commitments

  • declared components

  • disclosure retrieval semantics

  • interface discoverability

  • machine-readable disclosure references

Verification systems, risk engines, scoring frameworks, governance analyzers, and transparency interpretation layers are intentionally externalized.

Motivation

Ethereum protocols increasingly rely on complex governance systems, execution surfaces, upgrade paths, operator roles, and interconnected infrastructure.

However, protocol disclosures currently lack:

  • standardized retrieval semantics

  • canonical machine-readable structure

  • interoperable disclosure interfaces

  • ecosystem-wide discoverability

  • consistent declaration formats

As a result:

  • wallets

  • auditors

  • governance systems

  • transparency tooling

  • monitoring infrastructure

  • analytics platforms

must rely on fragmented, inconsistent, or unverifiable disclosure methods.

ERC-8241 introduces a canonical disclosure surface that enables protocols to expose standardized structural declarations without imposing any particular governance philosophy, safety framework, or verification regime.

Specification

Core Scope

ERC-8241 standardizes:

  • disclosure structure

  • metadata retrieval

  • structural declarations

  • machine-readable disclosure references

  • ERC-165 discoverability

ERC-8241 does NOT standardize:

  • governance legitimacy

  • operational correctness

  • execution validity

  • verifier policy

  • economic safety

  • transparency scoring

  • risk interpretation

  • protocol trustworthiness

Canonical Layer Separation

The architecture is intentionally separated into independent layers:

Layer Responsibility
ERC-8241 Structural declaration
Proof of Operation (PoO) Execution disclosure
Ethereum Transparency Layer (ETL) Verification and interpretation

ERC-8241

ERC-8241 defines how protocols expose structural declarations and machine-readable metadata.

Proof of Operation (PoO)

PoO systems expose observable execution disclosures and operational event surfaces.

Ethereum Transparency Layer (ETL)

ETL systems consume ERC-8241 disclosures and execution evidence in order to perform:

  • verification

  • interpretation

  • risk analysis

  • governance analysis

  • policy enforcement

  • transparency scoring

Verification is intentionally externalized from ERC-8241.

Compliance

A contract is ERC-8241 compliant if it:

  1. Implements the core interface

  2. Supports ERC-165 discoverability

  3. Exposes required retrieval semantics

Compliance does NOT depend on:

  • verifier approval

  • governance models

  • extension support

  • ETL integration

  • risk scoring systems

  • external attestations

Extension Model

ERC-8241 supports OPTIONAL extension surfaces.

Extensions may expose additional metadata or ecosystem functionality without affecting compliance status.

Current extension categories include:

  • Discovery

  • Safety Interfaces

  • Audit Evidence

  • Profiles

Extensions are explicitly non-normative.

Rationale

The ERC intentionally separates:

  • disclosure

  • execution

  • verification

This separation:

  • prevents verifier centralization

  • avoids governance lock-in

  • enables competing transparency ecosystems

  • preserves protocol neutrality

  • allows independent ETL implementations

  • minimizes normative surface area

The ERC therefore remains lightweight, composable, and broadly interoperable across Ethereum infrastructure.

Repository

Canonical repository:

https://github.com/chegecjay-rgb/protocol-control-disclosure

Canonical specification surfaces:

  • ERC-8241.md

  • COMPLIANCE.md

  • core/

  • extensions/

  • docs/

Canonical documentation includes:

  • architecture.md

  • extensions.md

  • etl-integration.md

  • migration-history.md

2

I’ve published the reference repository for the draft here:

The canonical draft is at the repo root as protocol-control-disclosure/erc-draft_protocol_control_disclosure_core.md at main · chegecjay-rgb/protocol-control-disclosure · GitHub

The repository also includes the Solidity reference implementation, supporting architecture/spec notes, and active Foundry test suites for the current narrowed core + integration surface.

3

Quick update: the ERC PR is now live and all automated checks are passing.

PR: https://github.com/ethereum/ERCs/pull/1706

At this point the submission is waiting on reviewer/code-owner review in the normal ERC process.

4

I wrote a follow-up post on why I think the Aave rsETH incident is a useful real-world example of the problem this ERC is trying to solve.

The point is not to blame Aave, Kelp, LayerZero, or any specific team. The deeper issue is that DeFi still lacks a common machine-readable way to inspect the control and dependency surface behind assets, protocols, bridges, custodians, oracles, and privileged upgrade paths.

That becomes more important as wallets, risk engines, explorers, auditors, and AI agents make more automated decisions.

That is also why I think the core standard should stay narrow: raw protocol control facts only — metadata, scope commitments, components, nodes, powers, edges, lookup rules, and freshness semantics.

Summaries, profiles, claims, diagnostics, and audit evidence can still be valuable, but they should remain optional and secondary.

Post here:
https://paragraph.com/@0x0afe5e054249b19ae29075540d9e6951c66e49b7/why-the-aave-rseth-incident-shows-we-need-protocol-control-disclosure-now-1

5

I wrote a brief follow-up on why I think ERC-8241 is worth taking seriously now:

https://paragraph.com/@0x0afe5e054249b19ae29075540d9e6951c66e49b7/making-the-case-for-erc-8241-protocol-control-disclosure?referrer=0x0AFe5E054249b19aE29075540D9E6951C66E49B7

Would appreciate feedback on whether the current draft is disciplined enough on that point.

6

Repository architecture and specification structure for ERC-8241 have been significantly refined to better separate normative disclosure semantics from verification infrastructure.

The repository now clearly distinguishes:

  • ERC-8241 → structural disclosure layer

  • Proof of Operation (PoO) → execution disclosure layer

  • Ethereum Transparency Layer (ETL) → verification and interpretation layer

Recent updates include:

  • canonicalization of the ERC-8241 core surface

  • formal compliance definition

  • clarification that extensions are OPTIONAL

  • separation of ETL verification concerns from ERC semantics

  • archival of historical research and experimental material

  • normalization of repository architecture for standards-track maturity

The repository now presents a cleaner standards-oriented structure centered around:

  • ERC-8241.md

  • COMPLIANCE.md

  • core/

  • extensions/

  • canonical documentation under docs/

Historical and experimental materials were preserved under research/legacy/ and research/drafts/ to maintain transparency and architectural continuity without affecting normative interpretation.

Canonical repository:

https://github.com/chegecjay-rgb/protocol-control-disclosure

Canonical documentation:

  • /docs/architecture.md

  • /docs/extensions.md

  • /docs/etl-integration.md

  • /COMPLIANCE.md

The goal of this restructuring was to transition ERC-8241 from an exploratory research repository toward a clearer standards-track architecture suitable for broader ecosystem implementation and review.