Why Audit Your Paymaster Before Your Smart Contract

A paymaster is a single contract that holds funds and decides which transactions to sponsor. Its logic is your primary financial risk vector.

• Single point of failure for your entire user base's gas.
• Business logic bugs can drain the sponsor wallet faster than any user-facing contract exploit.
• Unlike a DEX or lending protocol, failure here is silent and absolute.

Audit the paymaster's validation rules with the rigor of a core protocol. Treat user intents as untrusted inputs.

• Validate sponsor logic first: Does it correctly check userOp signatures, nonces, and calldata patterns?
• Enforce rate limits & budgets: Prevent infinite sponsorship loops or wallet draining via a single malicious userOp.
• Simulate edge cases like Pimlico, Biconomy, and Stackup do for their bundled transactions.

History shows the attack path: exploit the sponsor, not the target. This is a first-principles shift in threat modeling.

• Vulnerability pattern: Flawed validation allows an attacker to get their malicious transaction sponsored repeatedly.
• Cost asymmetry: Attacker spends $0 in gas to drain the sponsor's $1M+ ETH deposit.
• Real-world target: Projects like Safe{Wallet} and Uniswap that implement custom paymasters are prime targets.

Leading infrastructure providers bake in security-first patterns. Study their architecture as a blueprint.

• Modular validation: Separates signature verification, policy checks, and sponsorship logic.
• Gas overhead limits: Hard caps on how much any single userOp can cost the sponsor.
• Audit lineage: Their public audits (e.g., by Spearbit) set the standard for paymaster security reviews.

Measure paymaster risk by how quickly a bug can empty the vault. This is your new key security KPI.

• TTD < 1 block: Critical. Exploitable in a single Ethereum slot (~12 seconds).
• TTD < 1 hour: High. Allows some reaction time if monitoring is perfect.
• Monitoring is futile: By the time off-chain alerts fire, the funds are already irreversibly gone.

You wouldn't use an unaudited oracle. Your paymaster is your financial oracle. Deploying without an audit is gross negligence.

• Precedent from DeFi: Treat the paymaster with the same severity as a Chainlink oracle or MakerDAO vault.
• VC diligence: Top firms now require a paymaster audit as a core condition for infrastructure investments.
• The bottom line: A bug in your app's logic loses trust. A bug in your paymaster loses everything.

A malicious paymaster front-runs a user's gasless transaction, replacing the target contract with a drainer. The user signs a seemingly legitimate intent, but the paymaster executes a different payload.

• User signs for a Uniswap swap, but funds are sent to attacker's wallet.
• The user's signature is valid; the dApp UI looks normal.
• The smart contract is never touched; the exploit is in the meta-transaction layer.

A paymaster operator censors or reorders transactions unless users pay a premium. This turns a service into a centralized toll booth, violating core Web3 principles.

• Blocks transactions to Tornado Cash or specific DeFi protocols.
• Inserts predatory MEV bundles before user trades on CowSwap or UniswapX.
• Can extract >30% of transaction value by controlling inclusion and ordering.

A flawed paymaster logic allows a user to submit a transaction with intentionally bloated gas consumption, draining the paymaster's subsidy fund in a single call.

• User calls a complex, recursive function the paymaster agreed to sponsor.
• Gas costs explode to millions of units, exhausting the fund.
• All subsequent legitimate users are blocked; the service is bankrupt.

The paymaster uses a price oracle (e.g., Chainlink) to determine if a user can pay with ERC-20 tokens. Manipulating this oracle mints free transaction credits.

• Flash loan to skew a DEX pool price that the oracle reads.
• Paymaster incorrectly values user's $100 of tokens as $10,000.
• User sponsors $10k worth of gas for others, bankrupting the service.

A paymaster on Chain A incorrectly validates that a signature is only valid for a specific chain ID, allowing replay attacks on Chains B, C, and D via bridges like LayerZero or Across.

• User's signed intent for a mint on Arbitrum is replayed to mint on Optimism.
• Single signature triggers multiple sponsored transactions across the ecosystem.
• Exposes the paymaster to liability on every connected chain.

The most straightforward failure. The paymaster's upgradeable proxy admin keys are compromised, allowing an attacker to redirect all sponsored gas fees to their own wallet.

• Attacker upgrades logic to a contract that steals funds.
• All future transaction fees are siphoned; no immediate break in service.
• Results in a slow, silent rug pull from the subsidy pool and users.

ERC-4337's EntryPoint contract is the single point of failure for all UserOperations. A compromised paymaster can authorize malicious transactions for any account using it.\n- Affects all wallets in its domain, not just your contract.\n- Bypasses individual contract-level security audits.\n- Centralizes risk in a component often treated as plumbing.

A paymaster's validatePaymasterUserOp function holds the keys to the treasury. Logic bugs here turn gas sponsorship into a free mint or drain.\n- Infinite Mint Vectors: Flawed validation can approve ops to mint unlimited tokens from sponsored contracts.\n- Storage Griefing: Attackers can force paymaster to pay for bloating its own storage, bricking it.\n- Context: Dapps like Biconomy and Stackup manage billions of gasless transactions on this trust.

Most paymasters rely on price oracles (e.g., Chainlink) for token conversions. Manipulating this data is easier than finding a contract bug.\n- Cheaper Attack: Flash loan to skew a DEX pool is simpler than formal verification.\n- Systemic Impact: Compromises all transactions using that token pricing logic.\n- Real Example: Similar to the bZx flash loan attacks that targeted oracle price, not contract code.

A paymaster hack is a protocol-level event. It destroys user trust in your entire ecosystem, not just one feature.\n- Irreversible Damage: Users lose funds with zero interaction with your core product.\n- Narrative Control: Headlines read "[Your Protocol]' Infrastructure Hacked", not "Third-Party Module Bug".\n- Precedent: The Poly Network bridge hack was a cross-chain infrastructure failure, not a Dapp bug.

Paymasters must manage state between validation and execution phases. Race conditions here can create uncorrectable financial leaks.\n- Time-of-Check vs Time-of-Execution: Like classic web2 security flaws, but with immutable financial consequences.\n- Bundler Frontrunning: A malicious bundler can exploit delayed state updates.\n- Mitigation Complexity: Requires understanding of EIP-4337 mempool dynamics and bundler incentives.

Using upgradeable paymaster proxies (e.g., OpenZeppelin) for flexibility introduces admin key risks and storage collision vulnerabilities.\n- Admin Key Compromise: Single EOA upgrade authority becomes a $B+ honeypot.\n- Storage Layout Mismatches: Improper upgrades can corrupt user allowance or balance mappings.\n- Solution Context: Requires rigorous use of UUPS patterns and timelocks, adding audit scope.