ERC-4337 Error AA32: Paymaster Expired or Not Due Resolution
ERC-4337 error AA32 "paymaster expired or not due" occurs when the validation time window encoded in a verifying paymaster signature is invalid relative to the current block timestamp. Verifying paymasters pack validUntil and validAfter timestamps into validationData. If the transaction is mined after validUntil or before validAfter, EntryPoint reverts. Extend the timestamp buffer to 10–15 minutes to account for bundler delays, and synchronize backend sponsorship servers with network block times.
# Root Cause & Technical Architecture
Verifying paymasters enforce time-bounded sponsorship by packing timestamp ranges into a 160-bit integer: `validationData = (authorizer << 160) | (validUntil << 48) | validAfter`. During validation, EntryPoint checks `block.timestamp <= validUntil` and `block.timestamp >= validAfter`. If the bundler holds the UserOp in its mempool longer than anticipated or if network block timestamps drift, the condition fails and EntryPoint throws `AA32 paymaster expired or not due`.
# 4-Step Actionable Diagnostic Protocol
Step-by-Step ResolutionInspect Packed validUntil and validAfter Timestamps
Unpack the 6-byte validUntil and 6-byte validAfter values from the paymaster validationData or paymasterAndData payload.
Widen Sponsoring Server Expiration Thresholds
Configure backend sponsorship signers to provide a validUntil window at least 15 to 30 minutes in the future to absorb congestion delays.
Check Local System Clock Drift on Signing Servers
Ensure your backend sponsorship microservice synchronizes its system clock via NTP. A clock skewed forward can generate signatures already expired on-chain.
Re-request Fresh Paymaster Signature Before Broadcast
If a user delays in their client UI before approving the transaction, re-fetch a fresh paymaster signature prior to submitting to the bundler.
# Diagnostic Verification Code / Command
typescript// Unpack ERC-4337 validationData timestamps
function parseValidationData(validationData: bigint) {
const authorizer = validationData >> 96n; // Top 160 bits (address)
const validUntil = Number((validationData >> 48n) & 0xffffffffffffn); // 48 bits
const validAfter = Number(validationData & 0xffffffffffffn); // 48 bits
const now = Math.floor(Date.now() / 1000);
const isExpired = validUntil !== 0 && now > validUntil;
const isNotDue = now < validAfter;
return { authorizer, validUntil, validAfter, isExpired, isNotDue };
}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 ERC-4337 & Safe
Related Hex StatusesERC-4337 Error AA10: Sender Already Constructed UserOp Fix
Fix ERC-4337 error AA10 sender already constructed. Resolve non-empty initCode sent for deployed smart accounts, bundler estimation, and counterfactuals.
ERC-4337 Error AA20: Account Not Deployed EntryPoint Revert
Fix ERC-4337 error AA20 account not deployed. Troubleshoot empty initCode for counterfactual smart accounts, factory calldata, and pre-deployment.
ERC-4337 Error AA24: Signature Error UserOp Validation Fix
Fix ERC-4337 error AA24 signature error. Resolve validateUserOp signature mismatch, userOpHash EIP-712 hashing errors, and signature aggregator faults.
# Frequently Asked Questions
FAQ SchemaWhat does validUntil = 0 mean in ERC-4337?
In ERC-4337, a validUntil value of 0 is a special sentinel value indicating that the signature never expires.
Why do paymasters set short expiration windows?
Short windows protect paymasters from gas price volatility, preventing users from holding onto signatures generated during low fee periods and broadcasting during spikes.
Can miners or validators manipulate block.timestamp to cause AA32?
EVM rules restrict block timestamps to strictly monotonic increases within ~15 seconds of real time, making intentional validator manipulation unlikely.