Ronin's Karst upgrade introduces a cap of approximately 16.8 million gas for one transaction; it is not a fee of 16.8 million RON or a promise of cheaper transfers. The October 8 official recap reports that Karst launched the previous day. For a rejected large request, inspect the transaction's gas limit and action before simply increasing the price or retrying.
What changed for a large transaction
Ronin's Karst announcement identifies large batches, heavy multicalls and unusually large deployments as possible affected operations. It states that Ethereum deposit transactions are exempt. That is a defined exception, not a reason to assume any transaction you call a deposit has no cap.
The upstream EIP-7825 specification sets the per-transaction boundary at 16,777,216 gas and distinguishes it from the block gas limit. It also checks a transaction's declared gas limit, rather than waiting to see whether execution actually uses the maximum. The specification explains the mechanism; this article has not independently tested Ronin's deployed client or its exact error text.
Separate the amount sent, the execution limit and the price
| Value in a wallet or application | What it describes | What not to infer |
|---|---|---|
| Token amount | The asset quantity the intended action transfers | That it equals the execution fee |
| Transaction gas limit | The request's allowed execution budget in gas units | That raising it always makes the request valid |
| Gas price or fee quote | A pricing parameter or estimated monetary charge | That a higher price removes a protocol cap |
| Block gas limit | A budget applying to a whole block | That every individual transaction may use it all |
For an illustrative application request declaring 20 million gas, paying a higher price does not turn that oversized declaration into a request below a 16.8 million boundary. The application needs to examine why it supplied that budget. This example is not a benchmark, recommended setting or estimate of what an ordinary swap consumes.
The opposite shortcut is also unreliable. Manually forcing a lower gas limit does not prove the intended action can finish within it. A valid declaration and successful execution are separate checks. Have the application estimate the actual operation against the current network conditions instead of copying a number from a different transaction.
Questions that distinguish a cap problem from another failure
- Identify the network and the action you intended: a simple send, a batch, contract deployment or another operation.
- Keep the original error and the transaction reference if one exists. A rejected preparation request may not have become an on-chain transaction.
- Inspect the gas limit the application supplied, distinguishing it from the token amount and displayed monetary fee.
- Ask the application team whether the specific request fits the current per-transaction rules and whether its estimator supports Karst.
- For a large batch, ask for a supported redesign. Do not split a sequence yourself without understanding dependencies and whether the actions must succeed together.
A useful support request includes the action, network and failing stage: preparation, submission or execution. That gives the team a starting point without assuming every failure is caused by Karst. A request below a gas cap can still fail for reasons unrelated to that boundary, so keep the actual error rather than replacing it with a guess.
No-action guidance and operator duties describe different roles
The official announcement says ordinary users need take no action for the network upgrade, while builders and node operators have client and compatibility work. A holder should not read those operator instructions as a requirement to enter a recovery phrase in a new wallet. If your application behaves differently, ask its maintainer about that application and request.
Nor does a network launch announcement prove a particular custodial service has reopened every deposit or withdrawal route. The present article focuses on a transaction-size rule; a service-maintenance question needs the service's own current status. This review did not submit a transaction, operate a node or verify a customer's account.
A later swap still has its own asset and network instructions
Before a normal swap order, review the actual supported assets and exchange process. The fact that a wallet displays RON or accepts a network configuration does not establish KOT.CASH support for that route. Do not send an unsupported representation just to test whether a gas-related error has gone away.
Compare the current official instructions with the specific application version involved. Keep the rounded 16.8 million figure as a gas-unit boundary in the Ronin announcement, not a universal cost estimate, guaranteed limit for every exceptional transaction class or a prescription for wallet settings.
FAQ
Does the Karst cap set Ronin gas fees at a fixed amount?
The cap is expressed in execution units, not a fixed token payment. Keep the transaction's gas budget separate from its pricing parameters and displayed fee estimate.
Does raising Ronin gas solve a request above the transaction cap?
A higher price cannot make an oversized gas-limit declaration fit below a protocol boundary. The application needs to examine the actual request and how it is constructed.
Will a Ronin chain explorer show a request rejected before submission?
An error during preparation may not have produced an on-chain transaction. Preserve the original stage and error, then ask the application whether a transaction reference was created.