If you run a SaaS product and someone has asked whether Ethereum's recent protocol work changes anything for your billing stack, the honest answer is that two upgrades matter and only one of them touches your product directly. The rest is infrastructure economics that reaches you indirectly, through vendors you already buy from.
\n\nHere is what actually shipped, with dates and numbers taken from the specifications, and what a SaaS operations team should and should not conclude from it.
\n\nThe two upgrades that shipped, and exactly when
\n\nPectra: May 7, 2025
\n\nPectra activated on Ethereum mainnet on May 7, 2025, at epoch 364032. It bundled the Prague execution-layer and Electra consensus-layer changes into one fork and carried the largest set of EIPs of any Ethereum upgrade to that point. Per ethereum.org's Pectra page, three changes have practical downstream effects:
\n\n- \n
- EIP-7702 lets an externally owned account (EOA) extend itself with smart contract code, enabling transaction bundling, gasless transacting, and custom recovery schemes. \n
- EIP-7251 raised the maximum effective validator balance from 32 ETH to 2048 ETH, letting stakers earn on every ETH above the 32 ETH minimum and consolidate many validators into one. This shipped with Pectra on May 7, 2025, not as a separate later fork. It is a staking-operations change, not an application-layer one, and it does not affect your product. \n
- EIP-7691 raised the target blob count per block from 3 to 6 and the maximum from 6 to 9. \n
Fusaka: December 3, 2025
\n\nFusaka activated at epoch 411392 on December 3, 2025, at 21:49:11 UTC (slot 13,164,544), per the Ethereum Foundation's mainnet announcement. It carried 14 primary EIPs under the EIP-7607 meta-specification. The centerpiece is EIP-7594 (PeerDAS), a networking protocol that lets nodes verify blob data availability by sampling erasure-coded fragments instead of downloading every blob in full.
\n\nTwo Blob Parameter Only (BPO) forks followed, configuration-only changes that raise capacity without altering protocol logic. BPO1 on December 9, 2025 lifted the blob target to 10 and the maximum to 15. BPO2 on January 7, 2026 lifted them again to a target of 14 and a maximum of 21.
\n\nEIP-7702 is the only change that reaches your product surface
\n\nBefore Pectra, a SaaS product that wanted crypto-native payments faced a structural problem. A customer's ordinary wallet address could hold funds but could not execute logic. Anything resembling batching, fee sponsorship, or session-scoped permissions required deploying a separate smart contract account and migrating the user into it, an onboarding step that leaked users at every stage.
\n\nEIP-7702 removes that migration. An EOA can point at contract code and behave like a smart account without abandoning its address or its history. Three capabilities follow that map cleanly onto SaaS operations:
\n\n- \n
- Fee sponsorship. Your application can pay network fees on a customer's behalf, so a user is not blocked at checkout because they hold your product's payment token but no native gas token. \n
- Batching. Approve-then-spend flows that previously required two separate confirmations collapse into one atomic transaction, removing abandonment points in a funnel you already measure. \n
- Recovery and delegated permissions. Custom recovery schemes and scoped authorizations become possible on ordinary accounts, which matters for team-seat products where account loss is a support-ticket category rather than an edge case. \n
The vendor side moved quickly. Circle's write-up on the change describes EOAs temporarily assuming smart contract account behavior, submitting UserOperations and paying fees in USDC through Circle Paymaster with, in Circle's words, no smart wallet deployment required and no changes needed to Circle Paymaster itself. Circle lists the business benefits as faster onboarding, removal of token-swap steps taken purely to cover fees, and reach to users without access to native gas tokens.
\n\nNote what that source does not contain: no fee schedule, no pricing tiers, no cost-per-transaction figures. Any comparison table circulating with those numbers attached is not coming from the vendor's own documentation, and you should treat it accordingly.
\n\nFusaka's data layer changes your unit economics indirectly
\n\nPeerDAS and the BPO forks add no features to your application. What they do is expand how much rollup data Ethereum absorbs per block. Between Pectra and BPO2, the per-block blob target moved from 3 to 14 and the maximum from 6 to 21, roughly a fourfold increase in the data budget that Layer 2 networks compete for.
\n\nBecause rollups post compressed transaction data into blobs, and blob pricing responds to congestion, more supply against similar demand pushes settlement costs down. That mechanism is well documented. The magnitude is not. Post-upgrade fee-reduction percentages circulating in market commentary vary widely by source and measurement window, and none of them are protocol guarantees. If per-transaction cost is load-bearing in your pricing model, measure it on the specific L2 you deploy to, across your own traffic pattern, rather than importing a headline number from a market roundup.
\n\nWhat these upgrades did not fix
\n\nThis is where most SaaS-facing coverage overreaches. Neither upgrade delivers any of the following:
\n\n- \n
- Native recurring billing. There is still no protocol-level subscription pull. Recurring charges remain an application-layer construction built on allowances or session keys, carrying the same revocation and dunning problems as before. \n
- Cross-chain uniformity. An EIP-7702 delegation is set per chain. A product live on several L2s manages several authorization states. \n
- A smaller security surface. Delegating account code to a contract means the safety of that contract becomes the safety of the account. That is a genuine new risk class and it belongs in vendor due diligence, not a footnote. \n
- Anything about compliance. Revenue recognition, tax treatment, KYC obligations, and dispute handling are untouched by both forks. \n
How to evaluate this if you are buying rather than building
\n\nMost SaaS teams will never write against these EIPs directly. You will consume them through a payments or wallet-infrastructure vendor, which makes the useful questions procurement questions. Does the vendor support EIP-7702 delegation on every chain you sell in, or only the flagship one? Who audits the delegate contract your customers' accounts point to, and is that audit published? Is fee sponsorship a metered line item, and what happens to your margin if network costs spike during a congestion event? Can you export a transaction ledger your finance team reconciles without custom tooling?
\n\nThe protocol work is real and the dates are verifiable. The gap between \"Ethereum can now do this\" and \"this reduces our churn or our cost of revenue\" is still filled entirely by vendor selection and your own measurement.
", "keywords": ["EIP-7702", "Ethereum Pectra upgrade", "Fusaka upgrade", "SaaS crypto payments", "gasless USDC transactions"], "tags": ["Ethereum", "SaaS Payments", "Blockchain Infrastructure"], "sources": ["https://ethereum.org/en/roadmap/pectra/", "https://blog.ethereum.org/2025/11/06/fusaka-mainnet-announcement", "https://www.circle.com/blog/how-the-pectra-upgrade-is-unlocking-gasless-usdc-transactions-with-eip-7702"]}