How to Get an ERC (Ethereum Standard) Proposal Accepted

STAGNANT ERCS

inactive for 6+ months

ERCS I AUTHORED

ERC-3643, ERC-6960, ERC-7410. Plus ERC-8203, a draft I co-author.

There are 165 ERCs sitting in stagnant territory right now. Inactive for more than six months. Not rejected. Not abandoned. Just... stuck.

Most of them aren't bad ideas. The proposals failed because of how they were executed, not what they proposed.

I co-authored ERC-3643 (T-REX, now Final) and ERC-7410 (allowance update mechanism, Draft), and I am the first listed author among six for ERC-6960 (Dual-Layer token, Draft). Here's what I learned about the process.

Anatomy

the 20%: what goes in the document

Abstractone paragraph

Where scope gets promised. ERC-8126 promised a "quantum-resistant layer" here and never defined it.

Motivationprose

The concrete pain point. Reviewers have to recognize the problem from their own work.

Specificationinterface

Function signatures and events. Missing them tells reviewers you haven't implemented it.

Rationaleprose

The tradeoff you took and the one you rejected. Where answered objections go to live.

Test casescode

A spec with no test cases reads as a spec nobody has run.

Reference implementationcode

Not formally required. Practically essential, and editors ask for it anyway.

The parts of the document this article keeps coming back to. All of them together are the 20%. The other 80% starts the moment the document goes up.

The 5-Stage Process (With Real Timelines)

The official EIP-1 workflow reads cleanly on paper. Reality is messier.

EIP-1 Lifecycle

Idea to Final as it actually moves: who talks to whom at each stage. Most proposals never leave Review.

Scenario

Timeline

Key Factor

Best case (high consensus, clear scope)

2-3 months

Strong community support

Typical case (multiple feedback rounds)

6-12 months

Iterative spec revisions

Difficult case (controversial design space)

12-24 months or never

Political alignment needed

What Makes Standards Succeed: ERC-8004

FORUM POSTS

on ERC-8004 (Trustless Agents)

ERC-8004 (Trustless Agents) is a useful case study. It generated 118 posts on Ethereum Magicians. That's not viral by social media standards, but for an ERC thread it's exceptional.

What worked:

Success Factor

What It Means

Why It Works

Specific scope

Solves one thing. Defines an interface, not a runtime.

Readers know exactly what they're evaluating.

Real implementation feedback

Working code existed before the spec.

Spec reflects reality, not theory.

Credible, active author

Replied to every comment within days.

Reviewers trust authors who take feedback seriously.

Problem statement first

Motivation explained a concrete pain point.

Reviewers recognize the problem from their own work.

What Kills Standards: ERC-8126

ERC-8126: 13 posts (failure)

Kitchen-sink scope. Buzzword abstract. Author went silent for three weeks after two replies.

ERC-8004: 118 posts (success)

Specific scope. Working code. Active author. Problem-first motivation. Community engaged naturally.

ERC-8126 (AI Agent Verification) got 13 posts. That's close to the minimum before a thread dies from neglect.

The abstract included "quantum-resistant layer." The proposal tried to address agent authentication, verification, cross-chain interoperability, and privacy in a single interface definition. The author posted once, answered two questions, then went silent for three weeks.

Red flags that kill ERCs:

Red Flag

Why It Kills

Buzzword-heavy titles without interface definitions

Editors wait for you to fill it in. Reviewers won't engage with a concept.

Kitchen-sink scope

Each additional problem multiplies objections. Ship 4 focused ERCs instead of 1 ambitious one.

Zero engagement after posting

Fastest way to get ghosted. The forum has memory.

Vague specs

No function signatures, no events, no test cases. Tells reviewers you haven't implemented it.

Solo authorship on complex proposals

Multi-domain proposals benefit from co-authors who catch domain-specific blind spots.

Here's the same lesson in code. Both compile. Only one is a reviewable ERC.

Focused vs Kitchen-Sink

IAllowanceAdjust.sol (focused, ships)

// One interface, one problem: adjust an existing allowance
// without forcing a full re-approve. That is the whole scope.
interface IAllowanceAdjust {
    function increaseAllowance(address spender, uint256 addedValue) external returns (bool);
    function decreaseAllowance(address spender, uint256 subtractedValue) external returns (bool);
    function allowanceOf(address owner, address spender) external view returns (uint256);
}

IAgentEverything.sol (kitchen-sink, stalls)

// One interface trying to be an entire platform. Reviewers
// cannot evaluate this. Editors wait for you to define it.
// The thread dies at 13 posts.
interface IAgentEverything {
    function authenticate(bytes calldata proof) external returns (bool);
    function verifyAcrossChains(uint256 chainId, bytes calldata data) external returns (bool);
    function settlePayment(address to, uint256 amount, bytes calldata terms) external;
    function registerIdentity(address agent, bytes calldata credential) external;
    function rotateQuantumKey(bytes calldata newKey) external; // the "quantum-resistant layer"
    function resolveDispute(bytes32 txId, bytes calldata evidence) external returns (bytes32);
    // ...and six more the abstract promised
}

A reviewer can evaluate the first interface in one sitting. The second one, nobody can, so nobody does.

The 80% Nobody Talks About

You're building consensus, not winning an argument. When someone raises an objection, your first instinct is to defend your design. Resist it, and run this instead.

Objection Loop

Run this in public, every time. It's the whole difference between building consensus and winning an argument.

Respond to every substantive comment. Even if you're going to reject the suggestion, explain why. "That's out of scope for this ERC" with two sentences of context is a complete answer. Silence is not.

Find champions inside the ecosystem. If a wallet team is interested in implementing your ERC, that's worth mentioning in the thread. Real implementation interest moves proposals faster than any amount of theoretical discussion. It signals that the spec will be tested against actual code.

Be patient in a way that doesn't look like neglect. There's a difference between "I'm taking two weeks to think carefully about this feedback" and "the author has disappeared." The difference is one update comment saying you're processing the feedback.

Manage the review phase like a project. Set a weekly reminder to check your thread. Reply to anything more than a week old. When the thread goes quiet for a month, post a summary of where the spec stands and ask if there are remaining objections. Momentum is real and it dissipates fast.

My Playbook After Three Standards

This is what I do differently now, having shipped ERC-3643, first-authored ERC-6960 as one of six authors, and worked through ERC-7410.

MY PLAYBOOK

Start with a problem statement, not a solution

Before writing a single interface, write two paragraphs describing the concrete situation where existing standards fail. If you can't write those two paragraphs clearly, the ERC isn't ready.

Ship reference implementation before the spec

I wrote the T-REX implementation long before ERC-3643 was formalized. The spec came from the implementation. That order matters.

Identify 2-3 people who'd actually use this

Before posting on Ethereum Magicians, reach out privately to teams building in the relevant space. If you can't get three "yes, we've hit this problem" responses, reconsider.

One ERC, one interface problem

ERC-3643 solves compliance. ERC-6960 solves dual-layer NFT structure. ERC-7410 solves one allowance gap. None try to be complete systems.

Co-author when the domain overlaps

Even as someone who's designed both a compliance layer and a multi-layer token structure, I still sought co-authors for domain-specific blind spots.

Treat objections as spec reviews

Answer it in the thread, then write the tradeoff into the rationale section. That is what compresses the review cycle.

Six things I do differently now, learned across ERC-3643, ERC-6960 and ERC-7410. The decision tree below turns the same list into a go or no-go before you post.

Pre-Flight Check

Run this before you open the Ethereum Magicians thread. Land anywhere but 'Post it' and the ERC isn't ready yet.

Standards Are the Ultimate Builder Moat

A shipped feature

Lives in one codebase. Impact limited to your users.

A shipped ERC

Lives in every codebase that imports it. Impact you never have to be in the room for.

What A Final ERC Touches

You write the top band once. Every band under it then depends on you without ever talking to you.

ERC-3643 got there because we put in the non-glamorous work: the forum threads, the spec revisions, the patient responses to skeptical reviewers. None of it is in the document.

The process rewards builders who scope tightly and keep showing up long after the initial excitement burns off.

If you're sitting on a protocol-level insight that could improve how Ethereum handles a specific problem, the ERC process is worth it. Just go in knowing that the politics and the community work are most of the job.

Rather build on an existing standard than author your own? I put ERC-3643 head to head with ERC-1400 and CMTAT in the next episode.

The technical writing is easy by comparison.

FAQ

Anywhere from 2-3 months for high-consensus proposals to 12-24 months for controversial or complex ones. Most ERCs that reach Final do so within 12 months of their first serious review cycle.

Not formally required, but practically essential. EIPs that ship with reference implementations get more serious engagement and move faster through review. Editors will eventually ask for one anyway.

An EIP (Ethereum Improvement Proposal) is the general category. ERCs (Ethereum Request for Comments) are the subset of EIPs that define application-level standards, like token interfaces, contract schemas, and wallet interaction patterns. When you're defining a token standard or a smart contract interface, you're writing an ERC.

Yes. Many accepted ERCs have a single author. For complex proposals touching multiple domains, co-authors help distribute engagement and signal that the proposal has been stress-tested across different perspectives. For narrow, well-scoped proposals, solo authorship is fine.

Ethereum Magicians (ethereum-magicians.org) is the forum where ERC discussion happens before and during the formal EIP process. EIP editors expect to see a Magicians thread linked in your PR. It's where the real technical debate occurs. Skipping it and going straight to a PR usually results in editors sending you back to discuss first.