Ethereum Classic's history begins with the original Ethereum network, not a newly copied ledger created long after it. The decisive separation came in July 2016, when participants disagreed over changing the state affected by the DAO incident. The chain that retained the unaltered outcome became Ethereum Classic. That continuity is central to its identity, but it does not make ETC a receipt for ETH held today. The two networks subsequently developed different rules, communities, software requirements and native balances.

The community research FAQ describes ETC as a permissionless smart-contract blockchain secured by proof of work. Its persistence on that consensus model is a deliberate design position rather than a delayed participation in Ethereum's proof-of-stake transition. The distinction has practical consequences: ETC mining is not Ethereum validator staking, and a service offering yield on deposited ETC is not thereby exposing a native ETC proof-of-stake reward. The FAQ is a community explanation, not an independent measurement of decentralization or a guarantee against censorship.

The August 2016 Declaration of Independence argues that a neutral ledger must not selectively reverse outcomes to rescue a favored group. It also permits protocol improvements and bug fixes, so its position is more specific than opposition to all software change. The document frames neutrality, fungibility and voluntary participation as reasons to preserve the original chain. Those are the authors' normative commitments. They do not prove that contract code is flawless, that all users welcome every outcome, or that every later participant agrees with the declaration.

The community's Decentralism essay extends that argument beyond counting miners. It discusses clients, developers, exchanges, nodes and ownership as separate concentrations that can affect a network. This is a useful explanation of why funding disputes become identity disputes in ETC: dependence on a single sponsor can matter even when no sponsor directly produces blocks. The essay itself is marked opinionated and not representative of every stakeholder. Its aspiration to resist capture should therefore be read alongside observable maintenance and infrastructure dependencies.

ECIP-1099 specifies the Etchash change introduced with Thanos. It doubled the epoch length used in mining's dataset growth, allowing existing hardware to remain useful for longer under the changed schedule. The proposal connects that engineering choice to participation in the mining market. It is not a transition to staking and does not remove electricity or hardware costs. Its historical projections about particular memory sizes should not be turned into present purchasing advice: equipment economics and the network's competitive conditions change independently of the specification.

ECIP-1017 defines reward eras of five million blocks and a twenty-percent reduction at each subsequent era. Its rationale explicitly links predictable issuance to speculative willingness to support a young network, while acknowledging that monetary policy alone does not create value. That is unusually direct evidence of an investor thesis: scarcity could help attract capital and mining, which could support useful applications. The causal chain is an argument, not an observed law. A lower subsidy also makes the relationship between fees and future security funding increasingly important.

Coinbase's January 2019 incident report says it detected deep reorganizations beginning January 5 and paused interactions with ETC. Its updated account identified double spends while stating that Coinbase customer accounts had not been affected. The distinction matters: the report documents a serious consensus attack without establishing that every holder lost funds. Its later restoration of transfers with lengthy confirmation requirements shows another consequence of such attacks.

A chain can continue producing blocks while exchanges change how long they wait before treating deposits as dependable.

Bitquery's investigation of the July 31 to August 1, 2020 attack compared the displaced and accepted histories using data preserved from different clients. It traced double spending and the attacker's mining rather than relying only on a headline about hash power. The record illustrates why transaction inclusion and durable settlement are different on a proof-of-work chain. It also shows how client behavior can complicate incident analysis: preserved divergent data enabled the investigation, while operators still needed a client that followed the accepted chain.

The MESS specification proposed extra resistance to unusually deep reorganizations by giving locally observed history a stronger preference against a later competing chain. It was a client-side scoring convention outside the ordinary hard consensus rules. That distinction introduces a coordination question: implementations with different views or settings may not evaluate a suspicious history identically.

MESS should therefore be explained as a particular response to a security environment, not as mathematical elimination of majority attacks or as irreversible finality equivalent to a different consensus protocol.

ECBP-1110 later specified deactivating MESS by default at the Spiral block, while retaining an operator override. Its rationale cited the changed mining environment after Ethereum left proof of work and the costs of retaining subjective arbitration. This means an old article saying ETC simply has MESS protection can misdescribe the default configuration. The specification is also careful to identify Core-Geth as the implementation concerned.

A responsible operational assessment checks the actual client and settings rather than assigning every ETC node an identical defense from a historical announcement.

The developer FAQ identifies Solidity and familiar Ethereum development tools, but also distinguishes ETC's own deployed applications and chain ID 61. A contract address or asset dependency on Ethereum is not automatically present on ETC. Builders need to check the destination contracts, available infrastructure and supported execution rules. The FAQ's broad compatibility language is introductory guidance; it should not override a precise fork specification when a modern compiler emits an opcode that a particular ETC release has not activated.

Spiral's specification demonstrates this selective approach. It brought execution changes such as PUSH0 and initcode limits while omitting beacon-chain withdrawals and proof-of-stake-specific behavior. Maintaining useful EVM compatibility does not require importing Ethereum's entire consensus architecture. The separation also explains why adopting a feature takes explicit coordination: a source-language name may look unchanged while the underlying opcode has different meaning. Developers must target the network's deployed rule set, not infer parity merely because both ecosystems use Solidity.

ECIP-1000 describes proposals as versioned design documents with authors responsible for gathering input and recording dissent. Editors organize that process; publication is not equivalent to an automatic on-chain vote or a compulsory network update. This is particularly relevant when competing websites describe an upgrade differently. A named specification can be a draft, an implementation can be experimental, and activation can still require coordination among independent operators.

The public history helps readers distinguish those stages instead of treating a marketing announcement as a completed consensus change.

ECIP-1121 collects execution-alignment work while explicitly excluding fee-market governance and blob data-availability mechanics. At review, it remained a draft with both testnet and mainnet blocks unspecified. Its relationship table also contained older descriptions of neighboring proposals, making the individual current specifications more reliable for their detailed scope. The substantive distinction remains clear: agreeing that some Ethereum execution improvements are useful does not, by itself, mean agreeing to redirect fees into a treasury or to adopt Ethereum's settlement architecture.

The 2021 Ethereum Classic Classic manifesto opposed ECIP-1098's proposed protocol treasury. Its authors acknowledged the need to maintain clients but argued that privileged beneficiaries could entrench themselves and expose holders to governance risks. They suggested voluntary alternatives and warned against confusing visible advocacy with consensus. This is evidence of an organized opposition argument, not an impartial adjudication of every accusation or a survey of all holders.

It also shows that the 2026 funding controversy has a specific predecessor rather than appearing suddenly without historical context.

Cody Burns and Chris Mercer's current ECIP-1111 draft takes a different approach: introduce a base-fee mechanism and credit that fee to a configured address instead of burning it. The authors present network usage as a funding source without reducing the block subsidy or miner tips. That is the proposal's case, not a statement of activated ETC behavior. The destination and fee floor would be protocol choices, and readers must distinguish that funding argument from proof that sufficient revenue, legitimate governance or broad acceptance will follow.

ECIP-1112's Sovereignty Vault draft separates a destination fixed in chain configuration from upgradeable contract logic at that address. It requires inspectable deployment details before activation and treats governance of spending as a separate matter. The distinction prevents a misleading shorthand: a permanent address does not mean every rule controlling its money is permanently frozen. Evaluating the proposed arrangement requires knowing the implementation, administrator and publication requirements as well as the consensus rule that would credit fees to it.

Istora Mandiri and Diego López León's ECIP-1120 offers another draft, retaining a base-fee-style user experience while distributing the fees to miners through a smoothing mechanism. Its stated aim is preserving mining incentives without adding treasury governance. Several parameters remain provisional and require testing. This is a concrete competing design rather than a claim that opponents reject every modern fee interface. It also remains a proposal: neither its illustrative gas limits nor its distribution schedule should be presented as the live network's current parameters.

Classix's September 9, 2026 introduction identifies Istora Mandiri and Diego López León as its founders and describes taking over maintenance responsibilities as the ETC Cooperative winds down. It reports disruption to the older public RPC service and offers replacement infrastructure. These are the new organization's own operational statements, not independent certification of every allegation about the handover.

They do establish a practical research priority: users and builders should verify their configured endpoints rather than assume a historically familiar organization still operates them.

Project Triforce describes a cluster using different clients, providers and regions, with metrics intended to expose disagreement instead of hiding it behind one endpoint. The September update marked its dashboard beta live, while other parts of the page retained earlier planning language. Its architectural rationale is useful without treating every promised deployment property as independently verified.

Multiple software implementations and reproducible operations can reduce certain dependencies, but a hosted gateway remains an operated service whose availability is separate from the underlying chain's existence.

Core-Geth's August 14, 2026 Argos release backports deferred peer-message decoding and related validation changes, removes unresponsive bootnodes and explicitly reports no ETC or Mordor consensus changes. The release therefore documents substantive maintenance without proving that a new protocol fork occurred. Its separate MintMe configuration change must not be attributed to Ethereum Classic simply because it appears in the same software release. This is a useful example of why a shared client repository needs network-specific reading rather than a count of releases or commits.

The September 29 Classix roadmap marks public RPC and monitoring work delivered, while keeping public Nix configurations, parts of client integration and other infrastructure work unfinished. It places hoped-for Olympia withdrawal and Bastion activation in 2027, subject to further process. These status distinctions supersede looser language in older promotional pages. The roadmap is an accountable list of the team's claims and intentions, not a release certificate for every feature or evidence that opponents have already withdrawn a proposal.

Bastion, ECIP-1130, proposes selected newer opcodes and cryptographic precompiles while explicitly omitting treasury changes, proof-of-stake features and blob mechanics. It was still a draft with activation blocks unset at this review. The narrow package clarifies an important community distinction: preserving the ledger's political commitments need not mean abandoning development tools. Whether the proposal becomes an upgrade depends on implementation, testing and acceptance.

Its existence is evidence of ongoing engineering direction, not grounds for advertising those instructions as already available to deployed contracts.

The Classix manifesto presents voluntary funding, reproducible public infrastructure and eventual protocol stability as complementary goals. Its supporters want ETC to become less dependent on any single organization, including the one making that promise. The immediate task of replacing services shows why that goal cannot be assumed accomplished. Readers can assess the thesis through public maintenance records, reproducible deployments and independent contributors, while keeping its larger hope for enduring neutral applications distinct from a prediction that ETC's market price will rise.