From Cantina’s perspective, 2025 is a historic year for Ethereum security: two upgrades and one shared security effort define that story for us.
Pectra was the next major upgrade after Dencun. It bundled 11 Ethereum Improvement Proposals focused on performance, validator and user experience, and long term work on account abstraction and data availability. Fusaka, which saw mainnet activation on December 3, 2025, builds on that environment with PeerDAS, Blob Parameter Only forks, and execution and networking improvements for L1.
An upgrade of Pectra’s scope touches every major client implementation and the core specifications. From our vantage point at Cantina, that warranted a security program that matched the surface area. In collaboration with Ethereum Foundation’s protocol contributors and client organizations, we designed and ran a $2 million Pectra Security Competition on Cantina, a client layer security review spanning twelve repositories across all major execution and consensus clients plus the protocol specs.
This piece looks back at what Pectra introduced, how it connects to Fusaka’s direction, why it matters for institutions and core infrastructure, and what we learned about running cross client security programs at Ethereum scale.
Fusaka: scaling the environment Pectra prepared
In the Ethereum Foundation’s Fusaka mainnet blog, Fusaka is presented as the upgrade that follows Pectra and moves the scaling roadmap forward. The focus is on blob throughput and L1 performance.
Key elements include:
- PeerDAS, specified in EIP‑7594, which lets nodes verify blob data availability through sampling instead of downloading full blobs.
- Blob Parameter Only forks, which increase blob targets and maximums through minimal configuration changes, stepping from earlier limits toward higher values such as 10 and 15, then 14 and 21 blobs per block.
- Execution and networking updates, including ModExp pricing changes, a transaction gas cap, a default gas limit of 60M, and additions such as the secp256r1 precompile and the CLZ opcode.
Pectra prepared this ground:
- EIP‑7742 adjusted blob capacity and made blob parameters more flexible.
- EIP‑7623 raised calldata cost to keep total block size within safe bounds as blob usage grows.
- EIPs 6110, 7002, and 7549 modernized validator flows and attestations, aligning staking interactions with how operators run infrastructure.
- EIPs 2537 and 2935 improved cryptographic capabilities and historical state handling, which supports future work on stateless execution and Verkle trees.
The Pectra competition did not review Fusaka specific changes. It did subject the same execution clients, consensus clients, and specification paths to a coordinated round of client layer security work before this next scaling step.
What Pectra changed in practice
Pectra is a coordinated upgrade across accounts, validators, data handling, and cryptography. Each EIP has its own scope. Together, they reshape how Ethereum behaves in production and how ready it is for higher throughput.
Accounts and smart contract efficiency
EIP‑7702 introduces a transaction type that lets externally owned accounts temporarily act as smart accounts by loading code into the account for a single transaction. This unlocks:
- Transaction batching, so users can compress multiple actions into one transaction.
- Gas sponsorship, including fee payment with tokens such as stablecoins.
- Sub key permissions, so an account can delegate specific, limited rights to another key.
For users and developers, this is a concrete step toward account abstraction without requiring a full migration away from EOAs.
It is also one of the most security sensitive changes in Pectra. Delegation flows can be misused if users sign transactions that assign execution rights to contracts they do not understand. Protocols built around tx.origin can see assumptions fail once EOAs delegate execution to contract code. Because delegation does not pass through a constructor, initialization mistakes and race conditions are easier to introduce.
Mitigations sit across both wallets and protocols:
- Wallets need clear interfaces around delegation, execution rights, and the code that will run on behalf of an account.
- Protocols need to move away from tx.origin based checks and toward more robust authentication patterns.
- Developers need explicit initialization checks that restrict who can set storage and that reject unexpected writes.
Alongside EIP‑7702, Pectra refines data handling. EIP‑7742 increases blob capacity and makes blob parameters more flexible, which matters for rollups. EIP‑7623 adjusts calldata costs to keep total block size within a safe profile as blob data grows.
Validator operations and network efficiency
Pectra also updates validator economics and operations.
EIP‑7251 raises the maximum effective balance per validator from 32 ETH to 2,048 ETH. Previously, operators staking at scale had to run large fleets of 32 ETH validators. That distributed stake but increased operational complexity and consensus overhead.
With higher limits, operators can consolidate stake into fewer validators with larger balances. That can:
- Simplify key management and monitoring.
- Reduce hardware and maintenance cost.
- Ease pressure on the consensus layer.
The trade off is that large validators become more attractive targets and carry more weight during faults. Operators that choose higher balances need strong operational security and resilience. The intent is more efficiency without closing the door on validator diversity. How that balance lands in practice depends on choices by client teams, staking protocols, and institutional operators.
Supporting EIPs include:
- EIP‑6110, which supplies validator deposits from the execution layer, reducing activation delays and aligning stake flows more closely with block production.
- EIP‑7002, which lets execution layer contracts trigger validator exits and partial withdrawals, enabling more responsive staking products.
- EIP‑7549, which moves the committee index outside the signed attestation message, improving validation performance.
These changes modernize the validator lifecycle and keep the consensus protocol efficient as stake and usage grow.
Data, cryptography, and cross layer coordination
Several Pectra EIPs target long term protocol health.
- EIP‑2537 adds precompiles for operations on the BLS12‑381 curve, which is central to signature aggregation and zero knowledge proofs. Without a precompile, these operations are too expensive in the EVM at scale. The precompile makes verification of BLS signatures and proofs more practical with predictable gas costs.
- EIP‑2935 improves how recent block hashes are served by storing them in a system contract. This reduces node load and supports future work on stateless execution.
- EIP‑7685 introduces a general purpose mechanism for execution layer contracts to send structured requests to the consensus layer. It is a foundational piece for protocols that need reliable cross layer coordination. Requests are processed asynchronously, and gas costs and implementation controls are used to avoid flooding and manipulation.
These changes are less visible than account or validator updates, but they matter for maintainability and for future upgrades that lean on improved cryptography and more efficient networking.
From Cantina’s perspective: raising the bar for institutional grade security
Ethereum is already treated as core infrastructure by builders, exchanges, institutions, and public organizations. Pectra reflects that reality in both its design and the way it was prepared for mainnet.
From Cantina’s perspective:
- On the design side, Pectra organizes related EIPs into a coherent upgrade rather than isolated changes, with clear rationale and expected impact for each piece.
- On the process side, Pectra is a clear example of a major upgrade paired with an open, structured client layer security effort. That is what many institutional stakeholders expect when they evaluate changes to systems they already depend on.
The expectation we see across organizations is simple: when protocol changes are this significant, there should be visible, technically rigorous security work around the clients that implement them. Pectra met that expectation.
Inside the Pectra competition: how we approached it at Cantina
The Pectra Security Competition was a joint effort between Ethereum Foundation protocol contributors, client organizations, and Cantina. Our role was to turn a broad upgrade surface into concrete scopes and a process that researchers could work within.
Mapping Pectra into scopes
Together with coordinators from the EF Protocol team and client maintainers, we decomposed Pectra into twelve scopes:
- Five execution clients: Geth, Erigon, Reth, Nethermind, Besu.
- Six consensus clients: Lighthouse, Teku, Prysm, Lodestar, Nimbus, Grandine.
- One core specification repository: the Ethereum protocol specs, including execution, consensus, EIP logic, and low level system details.
Each scope became its own competition instance on Cantina Code with:
- Clear goals tied to Pectra specific behavior.
- Defined timelines, so client organizations could plan around their own release schedules.
- Shared evaluation criteria, aligned with how protocol contributors viewed severity and impact for this upgrade.
Researchers could dive deep into a single client or move across implementations and the specs to compare behavior. This cross view was important for protocol work, where divergences between implementations and specifications can matter as much as standalone bugs.
Working as one distributed team
During the competition, EF Protocol coordinators, client engineers, and Cantina’s security organization worked as a unified group.
In practice, that meant:
- Shared communication channels between researchers, EF coordinators, and client maintainers.
- Agreement in advance on how to interpret severity and impact for Pectra specific behavior, including areas like EIP‑7702 delegation, EIP‑7251 validator accounting, and blob handling.
- Direct responses from client engineers and EF contributors when researchers raised questions about edge cases or apparent inconsistencies.
Cantina Code served as the common environment:
- Researchers used it to submit reports, run discussions, and track status.
- EF Protocol contributors and client organizations used it to triage, clarify intended behavior, and link issues to code changes.
Repositories continued to evolve while the competition ran. The shared environment helped keep signal high even under active development.
Submissions were judged on:
- Technical depth.
- Relevance to Pectra specific logic and behavior.
- Value to the Ethereum ecosystem, including cases where an issue prompted clarification or alignment between specs and implementations.
In some cases, results led to refinements in client code or specifications. In others, they confirmed that critical paths behaved as intended under adversarial testing. Every participating client and the specs repository received targeted feedback tied directly to the upgrade they were preparing to ship.
What we learned running a multi client competition at this scale
Running the Pectra competition gave Cantina several concrete lessons that we now apply to other large programs.
Upgrades of this scale benefit from cross client structure.
Reviewing a single client in isolation can catch important issues, but many of the most interesting questions sit at the boundaries between specifications, execution clients, and consensus clients. Scoping work so that researchers can compare behaviors and assumptions across implementations increases the value of their findings.
Shared severity models matter.
With many teams involved, it is easy for different groups to view severity and impact differently. Aligning on how to classify Pectra specific behavior before reports arrived reduced friction and helped keep attention on issues that affected the upgrade.
Researchers work best with live access to maintainers.
Direct answers from client engineers and protocol contributors kept researchers focused on real edge cases rather than misunderstandings. It also reduced duplicate work by clarifying intent early.
A dedicated environment helps when code is still moving.
Client repositories continued to receive updates during the competition. A single place where reports, questions, and status lived made it easier for EF coordinators and client teams to keep track of what had been explored at which commit ranges.
These are practical requirements for any future multi client security effort at protocol scale.
What Pectra sets up for Fusaka and beyond
From a technical perspective, Pectra:
- Adjusted blob handling, calldata pricing, and resource accounting so Ethereum can safely support higher blob throughput, setting the stage for PeerDAS and Blob Parameter Only forks.
- Updated validator limits and staking flows through EIPs such as 7251, 6110, 7002, and 7549, making large scale staking operations easier to manage while keeping consensus efficient.
- Introduced new cryptographic and data handling primitives, including the BLS12‑381 precompile and recent block hash storage, that future upgrades can use for aggregation, stateless execution, and cross layer coordination.
From a process perspective, the competition showed that:
- Multi client, multi repository security programs can run at Ethereum scale when scopes are well defined and core teams are engaged.
- External researchers can add meaningful value across execution clients, consensus clients, and specs when they operate inside a structured environment with appropriate documentation and communication.
Fusaka now moves the scaling roadmap forward with PeerDAS, Blob Parameter Only forks, gas limit and pricing updates, and new precompiles and opcodes. It does so on top of client implementations that recently went through a focused round of Pectra specific security work.
For institutions and ecosystem organizations that rely on Ethereum, the main takeaway is that upgrades of this magnitude are now paired with visible, open client layer security programs.
Closing
For Cantina, 2025 stands out as a historic year for Ethereum security. Pectra advanced account design, validator operations, data handling, and cryptographic capabilities, and it prepared the protocol for the scaling work that Fusaka is beginning to deliver.
Just as importantly, the Pectra upgrade was accompanied by a dedicated client layer security program. Together with Ethereum Foundation Protocol teams, client organizations, and the broader research community, we ran a coordinated competition that matched the scope and importance of the upgrade.
Cantina will keep working with organizations that want to approach their own milestones with similar structure and depth. If you are planning a major upgrade, cross client rollout, or protocol launch and need a security program designed for that scale, contact our organization and we will help you scope, test, and strengthen your model.