Glamsterdam activated on Ethereum Sepolia on October 6, 2026, but that does not make every smart-wallet operation acceptable to every bundler. Alchemy’s current documentation describes specific Sepolia limits for estimation, bundles and verification gas. If your UserOperation is rejected, identify which field and service limit you hit before increasing a fee or treating the larger testnet block as proof it must fit.
The activation and the service restriction are separate facts
The Foundation’s later testnet announcement confirms the October 6 Sepolia activation. Its old Hoodi timetable has since been superseded; that correction must not be ignored when reading the page. For the narrower problem here, the useful fact is that a test environment can already run new rules while wallet infrastructure still has its own compatibility boundaries.
The primary evidence for this particular boundary is the Alchemy bundler FAQ, checked on October 27. Its Sepolia section lists a 16,000,000-gas estimation cap and separate bundle and verification limits. These are documented service constraints in that environment, not a universal maximum for every provider or a statement that mainnet activated Glamsterdam.
First name the quantity that failed
| What your evidence says | Question to ask next | Wrong inference |
|---|---|---|
| Block capacity was increased in a testnet | What limit applies to this individual request and route? | Every UserOperation must now fit |
| Estimation request exceeds a provider cap | Which gas field, value and endpoint caused the refusal? | The transaction ran on-chain and failed |
| Verification component exceeds its supported bound | Which account-validation stage is being estimated? | A higher price per gas necessarily fixes it |
| A real execution receipt reports failure | What actually executed and what result was recorded? | This is merely an unsubmitted estimation error |
| Another endpoint gives a different answer | Are chain, state, request and component versions comparable? | The cheaper answer is automatically correct |
In Alchemy’s bundler overview, the service is infrastructure for handling ERC-4337 user operations. That is why a smart-account request and an ordinary transaction submitted directly by an externally controlled account need not travel through identical machinery. Record the path your application actually uses instead of diagnosing it from the wallet’s visible balance alone.
Separate gas quantity from price per unit. A request above a supported quantity cannot be explained merely as “ETH is expensive.” Conversely, a price-related rejection does not establish that an operation exceeds an estimation cap. Ask the application to identify the rejected field and error stage; blindly changing both values makes the next result harder to interpret.
A compact evidence packet beats an arbitrary larger limit
- Name Ethereum Sepolia explicitly and record the provider and client or SDK version used.
- Identify the method and whether the failure happened during estimation, submission, validation or actual execution.
- Keep the relevant gas-field names, values and error message together; redact credentials before sharing logs.
- Compare the particular limit with the provider’s current documentation rather than the headline block capacity.
- Escalate with that evidence before retrying a changed request, especially if it is unclear whether an earlier attempt was already submitted.
For example, a fictional tester might report only “after Glamsterdam, send fails.” A useful replacement is “this Sepolia estimation request is rejected by this provider at this field, before a submission result is returned.” That does not solve the request by itself, but it gives the developer a testable boundary. No signed payload, production funds or wallet recovery material is needed to describe it.
Repricing also requires application testing
The Foundation’s repricing guidance explains why fixed gas assumptions and cached estimates deserve review. Some historical operations need different limits, while others require deeper contract investigation. Do not convert that guidance into a universal multiplier or a promise that raising the gas limit fixes every application.
The next relevant update for an affected integration is its provider’s revised Sepolia support, coupled with testing of the actual account and route. A future mainnet schedule is a different question. No mainnet date, live gas quote, completed test or provider support deadline is asserted here.
For an ordinary swap request, first verify the supported network and asset and understand the service’s transfer flow. This provider-specific testnet issue is not evidence that KOT.CASH uses that bundler, accepts testnet funds or has a production outage. Diagnose the environment you actually selected before drawing conclusions about an unrelated payment.
FAQ
Does an Alchemy bundler RPC rejection prove my Sepolia transfer executed?
No: identify whether the rejection happened during estimation, submission or later execution. A rejected estimate is not the same evidence as an on-chain receipt.
Does the Alchemy bundler API support every operation that fits a Sepolia block?
A network block’s capacity does not remove the documented service limits. Check the gas field and current provider support for your request.
Will paying more fix every Alchemy 4337 bundler gas error?
A quantity limit and a price-per-gas requirement are different constraints. Find the rejected field before changing the request or attempting another send.