Add new article: Olympia Development Series Part 0

[chris-mercer]

Context: This PR has been open since November 11, 2025 and remains unmerged due to unresolved concerns from a single reviewer, despite multiple rounds of revisions addressing all substantive feedback and prior approvals. The delay is now impacting consistency across the Olympia Development Series and the site’s established editorial workflow.

This PR adds a new longform article titled “Olympia Development Series — From Draft to Testnet (Part 0)” to the community website. The article introduces the start of the Olympia development series and outlines the transition from research and drafting into the implementation work and testnet preparation phase for the Olympia ECIP suite.

[netlify]

✅ Deploy Preview for ethereumclassic ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	9662b66
🔍 Latest deploy log	https://app.netlify.com/projects/ethereumclassic/deploys/6939c8cdbc36970007e371d1
😎 Deploy Preview	https://deploy-preview-1649--ethereumclassic.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[IstoraMandiri]

I do not think that "implementing" is the word you're looking for here.

Olympia Day — 11 / 11 / 2025 marks the moment Ethereum Classic begins implementing the Olympia upgrade suite.

Saying the above is strictly false IMO, as to begin implementation, this would mean that a design is settled, consensus is reached, and the code is ready to be written. Since Olympia is still in draft phase and it's implementation details are under discussion, it's not accurate to say that Etheruem Classic began to implement Olympia on 11th November.

Also, as mentioned previously, I am strongly against these kinds of "cart before the horse" promotions of Olympia, which claim that consensus is reached and a decision has been made to implement Olympia. Such claims, especially from trusted community channels, aren't helpful in maintaining a fair and balanced discussion and do not reflect the reality of the debate.

[IstoraMandiri]

Remove inaccurate use of the word "implementing"

[chris-mercer]

Acknowledged. Updates made. 👍🏻

[IstoraMandiri]

Sorry, but the recent updates to make minor tweaks to the wording do not address my concerns, and the article still doesn't accurately reflect the reality of the situation, while being presented as fact. It's fine to inform people about particular ECIPs, and it seems this blog post is really about introducing 1115, but it's presented as an announcement that, originally the ETC Core Devs (for some reason) and now "the community" has decided to implement Olympia.

This isn't true, and it's exactly what I urged you to avoid in the last call with regards to making announcements about Olympia that make it seem inevitable.

Readers rely on etc.org to fairly and accurately reflect reality on ETC related matters. This includes the true status and likelihood of Olympia, and we must not mislead people about it's inevitability. We don't want to make or imply promises and then be forced to backtrack. Doing so damages the reputation of this community channel.

I will highlight some key quotes to point out the issues, but they aren't limited to these, and I recommend a full re-write with the correct context of "we're still debating if Olympia will happen or not" to be made clear.

It’s fitting that this transition begins on 11/11 — a date that mirrors the number at the heart of Olympia’s foundation: ECIP-1111.

While 11th of November did indeed happen recently, and it does have the same dates as your ECIP, as far as I am aware, nothing actually happened on 11.11 - no decision was made - no debate occurred. It seems like this is just a date picked for marketing reasons and declared Olympia Day.

The ECIP process is important to keep neutral and uninfluenced by marketing or promises made on "official" channels, to ensure that the correct decision is made rather than one that is influenced or forced by such promises. As such, marketing for Draft ECIPs that may be rejected should be clearly described as such, and ideally be kept purely informative, to maintain neutrality and reflect reality.

As a side note, I don't think a Draft ECIP doesn't needs a "day". Maybe it's good day for a target block activation upon acceptance, but that comes later down the line.

After nearly a decade of debate and experimentation, Ethereum Classic enters a new phase of maturity.

This implies that we've been debating and experimenting Olympia for nearly 10 years and now the debate is now over, and on 11/11, the ETC Core Developers decided that it's going to happen. The reality is that the debate about 1559 / Olympia is ongoing, as per the community calls and feedback in your ECIP. There are still unaddressed concerns, and until the ECIP is moved to from Draft status, we can't say Ethereum Classic has entered any new phase.

As per ECIP-1000

Reference implementation -- The reference implementation must be completed before any ECIP is given "Final" status, but it need not be completed before the ECIP is "Accepted". It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for the Ethereum Classic protocol.

• WIP initial idea generation
• Draft idea maturation and addressing community concerns <- for Olympia, we are here
• Accepted "clear and complete description of the proposed enhancement"
• Final implementation is completed and will be adopted

The Olympia authors move from years of research into the first phase of implementation work

Whether you call it "implementation" use the synonymous word "development", Olympia is still in the draft phase and as far as I am aware, no coding, development or implementation (call it what you like), has started - nor did it start on 11/11. If I am mistaken please link me to the code commits, or project repository, to the reference implementation of Olympia, but in any case, the important thing is that we're still discussing the details, so an implementation can't be ready to be coded up yet.

Some minor other points. If you want to keep some promotional language, then I would be more comfortable with it if you use the disclaimer: opinion option, and clearly show that this is an opinion piece as to why Olympia is needed, but my key issue is that it's presented as a factual thing that the ETC Community or Devs or whatever, that Olympia is happening, and decided on 11/11. Also, you still use "implementaiton" unduly in the image and elsewhere in the article, as per my previous review.

Thank you.

[chris-mercer]

Thanks! Forgot about the image. Acknowledged. Updates made. 👍🏻

[IstoraMandiri]

Your recent update did change the image, but didn't address the other issues raised.

Please let me know if you have specific objections or would like to discuss my points, otherwise I cannot approve this until we've reached some kind of understanding on how to handle this series of posts going forward.

[IstoraMandiri]

Disabled auto-merge to prevent any accidents on potential controversial merges.

The latest commit (d293840) incorporates all requested adjustments and resolves the concerns raised regarding ECIP-1000 compliance and implied consensus.

This update:

• Removes any phrasing that could be interpreted as protocol-level implementation or a network decision.
• Clarifies that current Olympia work is reference-client development permissible in the Draft stage under ECIP-1000.
• Adds explicit procedural context reflecting the Draft status, community review requirements, and conditional nature of any activation.
• Revises remaining instances of “implementation” language into neutral descriptions of prototype and testnet-level work.
• Ensures all forward-looking statements are framed conditionally and aligned with the ECIP-1000 lifecycle.

The article now accurately reflects the ECIP process and maintains full procedural neutrality.

[IstoraMandiri]

See #1652 (comment)

Let's discuss there about a 1559-debate preamble we can agree on.

This article also does not use the opinion disclaimer as requested.

[chris-mercer]

Thanks for the continued feedback. I want to respond to the latest concerns on this PR, especially around framing, the proposed debate preamble, and the request to use the “opinion” disclaimer.

Because this is the opening installment of a technical, educational series, any framing needs to follow the long-standing editorial norms used on ETC.org. For the past decade, technical articles describing Draft ECIPs have not required special preambles, disclaimers, or meta-context tailored to individual proposals. Adding such requirements selectively for a single series would be a departure from that precedent.

---

1. This article was submitted on 11/11/2025 as the opening of a defined series

Part 0 was written and submitted on 11/11/2025 as the introductory entry in a structured Olympia Development Series. It has already:

• undergone multiple rounds of edits,
• removed language that could imply consensus or activation, and
• been reframed to reflect the transition from Draft to potential testnet work.

Introducing new, proposal-specific requirements now would undermine internal consistency across the series. If new site-wide editorial rules are ever adopted, they should be documented and applied prospectively, not retroactively.

---

2. The article no longer suggests activation or inevitability

Earlier concerns about “implementing” language have already been addressed. The article now:

• describes reference-client development appropriate for the Draft stage,
• reframes 11/11 as a symbolic marker rather than a governance decision, and
• presents Olympia as a set of Draft ECIPs under discussion.

The message is simply:

“These ECIPs are in Draft, and this is the work beginning around them,”
not:
“These ECIPs have been accepted or scheduled.”

---

3. ECIP-1000 procedural context is clearly stated

The article includes a dedicated “ECIP Procedural Clarity” section that:

• identifies ECIPs 1111–1115 as Draft,
• explains that early implementation work is permissible reference-client development,
• outlines the ECIP lifecycle, and
• clarifies that no activation or acceptance is implied.

This exceeds the typical level of procedural framing found in Draft-stage articles on ETC.org.

---

4. On the “opinion” disclaimer and proposed preamble

This piece contains:

• factual history,
• descriptive technical explanation, and
• conditional, forward-looking context.

Labeling the entire article as “opinion” misrepresents substantial objective content.
Likewise, inserting a debate preamble that artificially equalizes proposals of different maturity would be inaccurate—educational content should reflect maturity naturally, not via editorial overlay.

If the maintainer group wants to establish new site-wide guidelines for ECIP-related framing, I’m happy to participate in that discussion. But such rules should be consistent, documented, and uniformly applied—not introduced retroactively for one series.

---

5. Path forward

I’m happy to:

• keep the strengthened procedural clarity section,
• maintain language that avoids implying consensus or activation, and
• continue structuring the Olympia Development Series according to the same neutral, technical standards ETC.org has used for the past decade.

What I’m not comfortable with is:

• applying new, proposal-specific requirements only to this series, or
• reclassifying primarily educational, procedural content as “opinion.”

As revised, this article accurately reflects ECIP-1000, Draft ECIP status, and the nature of the reference-client work now beginning.

[IstoraMandiri]

Please move discussion to #1652 to maintain a single thread on this same topic.

[chris-mercer]

as olympia client work is wrapping up. it makes sense to get these articles published before the next wave of development articles hits the public website. @ethereumclassic/website this one has been sitting for 4+ months.

Observing and documenting a pattern of soft block from a contentious participant.

[IstoraMandiri]

Pending #1658

so we can add

disclaimer: debate
disclaimerLink: [the link when its merged]

[IstoraMandiri]

Now that the debate article is merged, please feel free to update the debate disclaimer URL

https://ethereumclassic.org/blog/2025-12-16-the-etc-fee-market-debate

And we I think we can get this through, if it's still up to date.