ECIP-1130: Bastion EVM and Protocol Upgrades

[IstoraMandiri]

ECIP-1130 is a draft meta ECIP defining the Bastion hard fork, which brings a subset of Ethereum's Cancun, Prague and Osaka execution-layer EIPs to Ethereum Classic.

#576

https://ecips.ethereumclassic.org/ECIPs/ecip-1130

[chris-mercer]

Worth noting for anyone reviewing: all eight EIPs in 1130 are already specified in Olympia ECIP-1121 (published December 2025), alongside additional execution-layer EIPs bringing Glamsterdam EVM alignment and the modern eth/69+ networking layer that 1130 omits or defers.

The distinction is the fee market and treasury, which 1130 leaves out by design. That's the part that addresses what the network faces: the collapse of its discretionary funding source and the absence of a long-term security budget as block rewards decline. Olympia carries the full EVM set, the funding mechanism, and fee-market alignment between core development and the security user base (PoW miners); 1130 is a partial EVM subset without the funding and security-budget mechanism.

Everyone's welcome to submit ECIPs — it's an open process. Noting the overlap here so reviewers have the full picture: this EIP set is already specified and implementation is complete under the Olympia suite, targeting mainnet in 2027 and in final testing on Mordor across the reference clients — including Fukuii, the only ETC-native client, which carried much of the development burden.

You can follow the Olympia implementation in: https://github.com/orgs/ethereumclassic/discussions/530

[IstoraMandiri]

Worth noting for anyone reviewing: all eight EIPs in 1130 are already specified in Olympia ECIP-1121 (published December 2025), alongside ~7 additional execution-layer EIPs and the eth/69–70 networking layer that 1130 omits or defers.

Thanks @chris-mercer , you are right to point out that 1130 excludes some of the EIPs that 1121 includes.

However, it is not the case that 1121 includes all 8 of the EIPs that 1130 proposes. since 1121 does not include any mention of 7823 or 7939.

As for the dropped EIPs, they were were considered, but were intentionally rejected on the grounds that they aren't a good fit for ETC. The rationale for inclusion/rejection was discussed on call https://cc.ethereumclassic.org/calls/53 and the comparison table is copied here to enable discussion:

EIP	1130	1121
1153: Transient storage opcodes (TLOAD / TSTORE)	🟢	🟢
5656: MCOPY opcode	🟢	🟢
6780: SELFDESTRUCT only in same transaction	🟢	🟢
2537: Precompiles for BLS12-381 curve operations	🟢	🟢
7823: Set upper bounds for MODEXP inputs	🟢	🔴
7883: MODEXP gas cost increase	🟢	🟢
7939: CLZ opcode (count leading zeros)	🟢	🔴
7951: Precompile for secp256r1 (P256VERIFY)	🟢	🟢
7910: eth_config RPC method	🔴	🟢
7935: Default gas limit to 60M	🔴	🟢
2935: Historical block hashes in state	🔴	🟢
7623: Calldata cost increase	🔴	🟢
7825: Per-transaction gas limit cap (~16.7M)	🔴	🟢
7934: RLP block size limit at 10 MiB	🔴	🟢
7702: Set EOA account code	🔴	🟢

And, I'll just repeat my comment from #576 here for context:

---

I preempt that the claim might be made that this is a duplicate of 1121. However, this proposal differs in two significant ways:

• No Olympia related code, just pure EIPs
• A different set of EIPs from 1121

The EIP bundle choice was discussed on calls:

https://cc.ethereumclassic.org/calls/46/
https://cc.ethereumclassic.org/calls/47/

and notably

https://cc.ethereumclassic.org/calls/53/, where the rationale for why each EIP is included or dropped is listed under "EIP Shortlist Walkthrough with Diego"

There are advantages of not including Olympia related proposals in the next ETC Hard Fork.

• Safer - with less moving parts, the Hard Fork is less likely to go wrong. Activating a set of battle-tested EIPs on their own can be an "easy win".
• Uncontroversial - Bastion does not include any features that are objected to by the community. Bastion does not 'pork-barrel' by bundling mixed concerns.
• Faster - since we don't need to wait on the completion of more complicated governance or economic mechanisms, it is possible for Bastion to reach mainnet on a predictable timescale.

[realcodywburns]

I thought you were naming your fork 'McIntyre'

Update: I am raising the question because it was suggested by a community member and i think it would be a very nice gesture considering his contributions to the project.

[IstoraMandiri]

@realcodywburns

This discussion is supposed to be for technical commentary, and you have chosen poison our discussion by making an inflammatory first comment that has no baring on the contents of our ECIP. As you well know, this is a very raw topic for all of us.

I thought you were naming your fork 'McIntyre'

At no point did any Bastion author suggest or even consider this. The suggestion came from an off-hand remark from a third party community member who has no involvement with the Bastion proposal.

Bringing this up here is uncalled for, really inappropriate, and frankly disrespectful.