Hegotá is two coordinated upgrades

Like Dencun, Pectra, Fusaka and Glamsterdam before it, Hegotá combines two separately named protocol upgrades. Bogotá covers Ethereum's Execution Layer, where transactions and smart contracts execute. Heze covers the Consensus Layer responsible for validator coordination and finality.

The combined name says nothing by itself about which technical changes will ship. Ethereum developers select individual Ethereum Improvement Proposals for each side of the fork. An EIP being discussed in connection with Hegotá is therefore not the same thing as an EIP confirmed for deployment.

Glamsterdam continued moving work away from critical bottlenecks

Hegotá inherits a scaling problem that several previous forks have been attacking incrementally. Ethereum wants more Layer 1 capacity while simultaneously giving rollups more room to scale Layer 2 activity. Achieving that requires both higher limits and less work for nodes when validating and propagating the chain.

Glamsterdam continued that approach with changes around block construction and propagation. Ethereum's roadmap increasingly looks less like one enormous switch being flipped and more like a sequence of specialized bottlenecks being removed before capacity is raised again.

Ethereum state is the next uncomfortable constraint

Increasing the gas limit allows more computation into each block, but transactions consume more than CPU time. They can create or modify accounts, contracts and storage slots that nodes then have to retain.

That collection is Ethereum's state. Unlike historical data that some node configurations can move elsewhere or prune depending on their role, current state has to remain readily available to validate new activity. A faster chain that allows state to expand indefinitely can therefore exchange one scaling bottleneck for storage and database pressure.

Work discussed around the Hegotá cycle sits directly inside that trade-off between throughput and sustainable node requirements. Ethereum's longer-term roadmap includes multiple approaches intended to make state less burdensome without giving up independent verification.

Candidate EIPs are not Hegotá features yet

During this phase, Ethereum client teams evaluate proposals that could become part of Bogotá or Heze. Their status can change substantially: an EIP may be considered, promoted to candidate status, delayed to a later fork or removed entirely.

That distinction matters because protocol development meetings are not product launch events. A hard fork becomes progressively better defined through All Core Developers decisions, implementations across independent clients, development networks and eventually public testnets.

A technically attractive proposal can still miss Hegotá because its implementation is too complex, it depends on unfinished work elsewhere, or client teams cannot test it safely within the release window.

Faster fork cadence is now an engineering constraint of its own

Ethereum has been moving toward more regular protocol upgrades instead of packing an excessive number of changes into a single fork. That can shorten the gap between a mature EIP and mainnet deployment, but it also forces developers to freeze each fork's scope earlier.

A delayed feature consequently does not necessarily disappear for years. The less convenient side effect is a roadmap that resists neat specification sheets: proposals can migrate from one named fork to the next as engineering priorities and readiness change.

More throughput still means more work somewhere

Layer 1 performance cannot be judged only by transactions per second. Additional capacity has to remain compatible with block execution time, propagation, state access and a hardware envelope that still allows a sufficiently broad set of operators to run validating nodes.

That is why Ethereum combines protocol optimization, networking work, state research and Layer 2 scaling rather than treating one larger parameter as a complete solution. Increasing a numerical limit is easy; preserving verification properties after increasing it is the engineering problem.

Hegotá does not have a final specification yet

The next upgrade cycle has a name, its broader engineering pressures are identifiable and potential protocol changes are being evaluated. That is not enough to describe every proposal associated with it as confirmed.

The useful milestones will be a stabilized set of included EIPs, implementations across multiple Ethereum clients and successful deployment through development and public test networks. Those steps progressively turn Hegotá from a collection of candidates into a defined hard fork.

Its continuity with Glamsterdam is already visible. Ethereum is trying to raise capacity incrementally without making every throughput gain translate directly into higher node requirements. Hegotá will have to continue that work against one particularly stubborn resource: the accumulated state of a blockchain that has now been running for more than a decade.