How to Get an Ethereum Standard Accepted

STAGNANT ERCS

inactive for 6+ months

ERCS CO-AUTHORED

ERC-3643, ERC-6960, ERC-7410

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 three ERCs: ERC-3643 (T-REX, now Final status), ERC-6960 (Dual-Layer token, Draft), and ERC-7410 (allowance update mechanism, Draft). Here's what I learned about the process that nobody puts in the documentation.

The 5-Stage Process (With Real Timelines)

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

Stage 1: Idea (Pre-Draft)

Post on Ethereum Magicians. Find 3+ developers with the same problem. If nobody responds in two weeks, that's your answer. Don't skip this step.

Stage 2: Draft

Open a PR against ethereum/EIPs. Strict template: preamble, abstract, motivation, specification, rationale, backwards compatibility, test cases, reference implementation. Editor queue: 2-4 weeks.

Stage 3: Review

Community digs in. Most ERCs stall here. Other devs ask hard questions, find edge cases, point out conflicts. No fixed timeline: 6 weeks to 14 months.

Stage 4: Last Call

14-day window for final objections. Most proposals reach Last Call and never leave. One objection, author goes quiet, clock resets indefinitely.

Stage 5: Final

The ERC is accepted as an Ethereum standard. Part of the canonical reference set that wallets, protocols, and auditors cite.

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)

Abstract included "quantum-resistant layer." Kitchen-sink scope. Author went silent for 3 weeks after 2 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.

The 80% Nobody Talks About

You're building consensus, not winning an argument. When someone raises an objection, your first instinct might be to defend your design. Resist it. Ask them to describe the scenario where your spec breaks. Most of the time, the scenario reveals a genuine edge case you hadn't considered. Fix the spec. Thank them publicly.

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 3 ERCs

This is what I do differently now, having shipped ERC-3643, co-authored ERC-6960, and worked through ERC-7410.

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

When someone disagrees, add a rationale section explaining the tradeoff. Future reviewers find the question already answered. This compresses the review cycle.

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. ERC-3643 is now referenced in regulatory frameworks across multiple jurisdictions. Cited in audits. Basis for compliance infrastructure at institutions I'll never talk to.

A shipped feature lives in one codebase. A shipped ERC lives in every codebase that imports it.

ERC-3643 is now referenced in regulatory frameworks across multiple jurisdictions. It's cited in audits. It's the basis for compliance infrastructure at institutions I'll never talk to directly. That happened because we put in the non-glamorous work: the forum threads, the spec revisions, the patient responses to skeptical reviewers.

The process rewards builders who are disciplined about scope, honest about implementation, and consistent about showing up.

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.

The technical writing is easy by comparison.