SKIP TO CONTENT
ETHEREUM STANDARDS6 minStandards That Ship / Ep. 1 · Stage 1-3

ERC Community Review: How to Answer Objections

Someone says your spec is wrong, in public. Do you defend it, or ask where it breaks?

XIN
Pixel-art illustration of a glowing proposal card riding a track of light through a graveyard of stalled proposals toward a lit gate.

IN 30 SECONDS

Community review is the public phase where builders test your ERC and raise objections. Getting through it is social work: answer every substantive comment, fix real edge cases, record the tradeoffs.

KEY TAKEAWAYS · 3

  • Answer every substantive comment, and write settled objections into the Rationale.
  • EIP-1 makes the reference implementation optional. I still ship working code before the spec.
  • An adopted ERC lets teams who never meet build compatible software. Final status and adoption are separate milestones.
On this page

Community review: answering objections

IN SHORT Getting an ERC accepted is a social process: you’re building consensus, not winning an argument.

WORDS TO KNOW

Ethereum Magicians
The community forum EIP-1 names as the preferred place to discuss a proposal.
Rationale
The section of an ERC that explains its tradeoffs: what was chosen, what was rejected, and why.
EIP editor
Checks that a proposal is well formed, complete and sound. Under EIP-1, editors don’t judge the idea itself.

IN PLAIN WORDS

Writing the spec is only part of the work. Implementers also need a clear scope, useful examples and answers to their objections.

STEP BY STEP

Flow diagram: 5 stepsFlow diagram: 5 steps. An objection lands, then Ask where the spec breaks. Ask where the spec breaks, then Usually a real edge case. Usually a real edge case, then Fix it, thank them publicly. Fix it, thank them publicly, then Write it into the Rationale.1An objection lands2Ask where the spec breaks3Usually a real edge case4Fix it, thank thempublicly5Write it into theRationale

Step 1. Objection. Someone says your spec is wrong. Don’t defend it yet.

Pick a step to see it move
  1. Objection Someone says your spec is wrong. Don’t defend it yet.
  2. Ask for the case Ask for the scenario where your spec breaks. Make them describe the case, not the disagreement.
  3. Edge case In my experience, most of the time it’s a real edge case you hadn’t considered.
  4. Fix Fix the spec and thank them publicly.
  5. Record Write the tradeoff into the Rationale. The next reviewer finds the question already answered.
Run this loop in public, every time an objection lands.

The Rationale The section of an ERC that explains its tradeoffs: what was chosen, what was rejected, and why. See the glossary becomes the proposal’s memory. Answer every substantive comment, even when you reject the suggestion. “That’s out of scope for this ERC” plus two sentences of context is a full answer; silence isn’t.

  • Find champions. If a wallet team wants to build your ERC, say so in the thread. In my experience, real interest from builders moves a proposal faster than theory.
  • Run the review like a project. Check your thread every week and reply to anything older than a week.
  • If the thread goes quiet for a month, post a summary and ask what objections remain.

ADAM says: Be patient without looking absent. “I’m taking two weeks to think about this feedback” reads nothing like silence.

Coming up next: So what do I check before the thread even opens?

My playbook after three merged standards

IN SHORT What I do differently now, after ERC-3643, ERC-6960 and ERC-7410.

MY PLAYBOOK
1

Start with the problem, not the solution

Before any interface, write two paragraphs on the concrete case where current standards fail. If you can’t, the ERC isn’t ready.

2

Ship the reference implementation before the spec

My work on the T-REX suite and OnchainID gave me the implementation context for ERC-3643. Test a real design before you call its interface stable.

3

Find at least three teams who need it

Before you post, reach out privately to teams in the space. Without three “yes, we’ve hit this problem” answers, think again.

4

One ERC, one interface problem

ERC-3643 defines a framework for permissioned tokens, ERC-6960 dual-layer balances, ERC-7410 allowance updates. None replaces the rest of an app.

5

Co-author when the domains overlap

I’ve designed a compliance layer and a multi-layer token structure, and I still sought co-authors for the blind spots.

Five habits from three merged standards, plus the objection loop above. These are my practice, not EIP-1 rules.

Before you post on Ethereum Magicians The community forum EIP-1 names as the preferred place to discuss a proposal. See the glossary, check three things: working code, three or more teams with this exact problem, and one interface problem. If one is missing, the ERC isn’t ready yet.

ITEM GET

Code before a stable interface

EIP-1 makes the reference implementation optional. I still build it first: it exposes the vague parts.

Why a standard outlasts a feature

IN SHORT A feature lives in your code; an adopted ERC lives in every codebase that builds on it.

FEATURE VS STANDARD

A shipped feature

Lives in one codebase. Its impact mostly stays with your users.

An adopted ERC

Other wallets, apps and tools build on it, including teams you never meet.
A stable interface lets apps and tools evolve on their own. Adoption still takes implementation and maintenance, and Final status doesn’t guarantee it.

As I see it, ERC-3643 reached Final because we did the unglamorous work: forum threads, spec revisions, patient answers to skeptical reviewers. Little of it shows in the final text.

In the ERC process, the politics and the work with people are most of the job, and the tech writing is easy next to that.

EIP editor Checks that a proposal is well formed, complete and sound. Under EIP-1, editors don’t judge the idea itself. See the glossary check form and completeness; the community decides whether the idea goes anywhere.

Sources: EIP-1, ERC-3643, ERC-6960, ERC-7410.

FAQ

Yes. EIP-1 asks for an author list and doesn’t require co-authors. On a complex proposal across several domains, co-authors catch blind spots.

It’s the forum EIP-1 names as the preferred home for a proposal’s discussion link. EIP-1 also recommends vetting the idea with the community before you write a formal proposal.

STAGE CLEAR

What you now know

  • You can turn an objection into a fix: ask for the case, fix the spec, record the tradeoff.
  • You can explain why an adopted standard reaches further than a feature, and why Final alone doesn’t make it adopted.

Check yourself

Tap or click a question to see the answer.

A reviewer writes that your spec breaks for tokens that charge a fee on every transfer. What’s your first move?

Ask for the exact scenario where it breaks, before defending anything. In my experience it’s often a real edge case: fix the spec, thank them in public, and write the tradeoff into the Rationale.

Next episode:Which security token standard should you pick, and where does each one check a transfer?6 min
Adam Boudjemaa
Adam Boudjemaa

Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.

Have a project to ship or a role to fill?

Discuss your project or role
LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.