ERC-4337 Error AA34: Paymaster Signature Error Validation Fix
ERC-4337 error AA34 "paymaster signature error" occurs when a verifying paymaster contract rejects the cryptographic sponsorship signature contained in paymasterAndData. This indicates that the hash verified by the on-chain paymaster does not match the hash signed by the backend sponsor service. Common causes include modifying UserOp gas limits after signing, chain ID discrepancies, or utilizing the wrong verifying signer key. Re-sign the exact final UserOp payload.
# Root Cause & Technical Architecture
Verifying paymasters calculate an internal cryptographic hash over the UserOperation fields (sender, nonce, initCode, callData, gas limits, chainId, and validUntil/validAfter timestamps). The paymaster contract recovers the signer from the signature appended to `paymasterAndData`. If the recovered signer does not match the paymaster contract's authorized signer address, `validatePaymasterUserOp` returns authorizer status `1`, causing EntryPoint to revert with `AA34 paymaster signature error`.
# 4-Step Actionable Diagnostic Protocol
Step-by-Step ResolutionVerify Sponsoring Signer Address Configuration
Query the paymaster contract on-chain to verify the registered verifyingSigner address matches the private key used by your backend sponsorship server.
Ensure No UserOp Fields Mutated After Sponsorship
Never alter callGasLimit, maxFeePerGas, or verificationGasLimit after collecting the paymaster signature, as any mutation alters the signed hash.
Check Paymaster Hash Construction Specification
Verify whether your paymaster contract expects EntryPoint v0.6 hashing (EIP-712 or keccak256 pack) or v0.7 separate paymaster fields.
Inspect 65-Byte ECDSA Signature Encoding
Confirm the signature is properly formatted as [r (32 bytes), s (32 bytes), v (1 byte)] without missing leading zeros in r or s.
# Diagnostic Verification Code / Command
solidity// VerifyingPaymaster Hash Reconstruction Logic
function getHash(UserOperation calldata userOp, uint48 validUntil, uint48 validAfter)
public view returns (bytes32) {
return keccak256(abi.encode(
userOp.sender,
userOp.nonce,
keccak256(userOp.initCode),
keccak256(userOp.callData),
userOp.callGasLimit,
userOp.verificationGasLimit,
userOp.preVerificationGas,
userOp.maxFeePerGas,
userOp.maxPriorityFeePerGas,
block.chainid,
address(this),
validUntil,
validAfter
));
}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 SchemaWhy does changing maxFeePerGas cause an AA34 error?
maxFeePerGas is one of the parameters included in the paymaster hash. If changed, the backend signature no longer matches the UserOp.
How do I debug which parameter caused the hash mismatch?
Log the exact ABI-encoded parameters from your backend signing service and compare them with the parameters received by the contract in a local Foundry trace.
Does AA34 mean the user signature was wrong?
No. User signature errors trigger AA24. AA34 strictly indicates that the paymaster sponsorship signature was rejected.