Solidity Panic 0x11: Arithmetic Overflow or Underflow Resolution
Solidity Panic 0x11 (selector 0x4e487b71) indicates an arithmetic overflow or underflow occurred during smart contract execution. Since Solidity 0.8.0, compiler-generated integer checks automatically revert transactions when an arithmetic operation results in a value outside the allowable bounds of the integer type (e.g. subtracting from 0 on a uint256). Inspect the contract variables, audit mathematical operations, or wrap deliberate wraparounds in explicit unchecked blocks. Always validate input variables to ensure operands stay strictly within safe numerical boundaries.
# Root Cause & Technical Architecture
Solidity 0.8.0 introduced native overflow and underflow protection without requiring SafeMath. When an arithmetic error occurs, the EVM issues an `assert()` failure returning the standard Panic selector `0x4e487b71` followed by uint256 code `0x11`. Common causes include attempting to subtract a larger number from a smaller unsigned integer (e.g., `balance - withdrawAmount` when balance is insufficient) or multiplying values that exceed $2^{256} - 1$.
# 4-Step Actionable Diagnostic Protocol
Step-by-Step ResolutionIdentify Subtract-From-Zero Underflows
Check calculations where a subtraction operator (-) is applied to uint256 variables. Ensure the subtrahend does not exceed the minuend.
Audit Multiplications for Intermediate Overflows
Multiplications like (amount * 1e18 * feeBasisPoints) can exceed 256 bits before division occurs. Re-order operations or use uint512/FullMath.
Trace Reverting Line Using Foundry cast or forge test
Run forge test -vvvv to inspect the execution trace and pinpoint the exact source code line triggering the Panic(0x11) assertion.
Use unchecked Blocks Intentionally for Bitwise Wraps
If modular arithmetic wrapping is mathematically intended (e.g. hash calculations or counters), wrap the specific operation in unchecked { ... }.
# Diagnostic Verification Code / Command
solidity// Solidity Panic(0x11) Anatomy & Safe Arithmetic Guard
// Panic signature: bytes4(keccak256("Panic(uint256)")) = 0x4e487b71
function safeWithdraw(uint256 currentBalance, uint256 withdrawAmount) public pure returns (uint256) {
// Underflow guard: prevents Panic(0x11) on currentBalance - withdrawAmount
require(currentBalance >= withdrawAmount, "Insufficient withdrawal balance");
return currentBalance - withdrawAmount;
}Launch ERC-4337 UserOp Decoder
Execute client-side cryptographic simulation and parameter checks safely in your browser via native WebCrypto without sending private keys or mnemonics over the wire.
Read Full Investigation & Recovery Workflow
Explore complete architectural diagrams, edge-case failure trees, and detailed post-mortem analysis in our verified deep guide.
# Related Diagnostic Codes in EVM & JSON-RPC
Related Hex StatusesJSON-RPC Error -32000: Insufficient Funds for Gas * Price + Value
Fix JSON-RPC error -32000 insufficient funds for gas * price + value. Resolve native token balance shortages, fee estimation surges, and gas caps.
JSON-RPC Error -32000: Replacement Transaction Underpriced Fix
Fix JSON-RPC error -32000 replacement transaction underpriced. Apply mandatory 10%+ maxPriorityFeePerGas bump on same nonce to replace stuck mempool txs.
JSON-RPC Error -32000: Nonce Too Low Stale Wallet State Fix
Fix JSON-RPC error -32000 nonce too low. Troubleshoot stale local wallet nonce caches, pending mempool transactions, and reset account state.
# Frequently Asked Questions
FAQ SchemaWhat is the full hex signature of a Solidity Panic error?
The signature is 0x4e487b71, representing Panic(uint256). Code 0x11 specifies an arithmetic overflow or underflow.
Why did my Solidity 0.7 code work without Panic 0x11?
Prior to Solidity 0.8.0, integers wrapped around silently without reverting unless developers manually used the SafeMath library.
Does Panic 0x11 consume all remaining gas?
Since Solidity 0.8.0, Panic errors use the REVERT opcode and refund unused gas, unlike legacy assert() calls that consumed all remaining gas.