---
title: "Risiko Paymaster ERC-4337"
description: "Pahami cara Paymaster ERC-4337 mensponsori gas, memvalidasi UserOperation, dan menyelesaikan biaya, serta risiko setoran, ketersediaan, harga token, izin, dan penguncian akun."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Risiko Paymaster ERC-4337

> Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

<a id="answer"></a>

## Jawaban langsung

An ERC-4337 Paymaster is a contract that conditionally accepts responsibility for a smart account's `UserOperation` gas. It can sponsor the user outright or support a service that charges an ERC-20 token, but native gas is still paid from the Paymaster's ETH deposit in the selected `EntryPoint`. Token charging, exchange rates, allowlists, quotas, and off-chain authorization are service policies, not guarantees defined by ERC-4337.

A Paymaster adds a liveness and pricing dependency. Its policy can reject an operation, its deposit or service quota can run out, its quote can expire, and its validation or `postOp` logic can fail. Assets in the smart account do not automatically disappear when sponsorship stops, but an account with no self-funded or alternative Paymaster path can be temporarily unable to transact.

<a id="mechanism"></a>

## Cara kerja sponsor Paymaster

1. Pin the exact `chainId`, `EntryPoint` address and version, Paymaster contract, bundler, and smart-account implementation. A service name or matching address on another chain does not prove that the same code or policy is in use.
2. The wallet builds a `UserOperation` with Paymaster fields and usually obtains `paymasterData` or a Paymaster signature from a service. Review the target calls, token, maximum token charge, allowance or permit, quote expiry, and every domain bound into that authorization.
3. Before accepting the operation, a bundler simulates account and Paymaster validation. The `EntryPoint` checks that the Paymaster deposit can cover the maximum cost and calls `validatePaymasterUserOp`; time ranges, signatures, quotas, allowlists, and other policy may reject it. ERC-7562 validation and reputation rules reduce denial-of-service risk but do not certify the Paymaster's business terms or solvency.
4. If validation passes and a bundle is included, the smart account executes. Execution can still revert and consume gas. When validation returned non-empty context, the `EntryPoint` invokes `postOp` so the Paymaster can reconcile the result or charge a token according to its own logic.
5. Reconcile the UserOperation receipt, underlying bundle transaction, `UserOperationEvent`, execution result, actual gas cost, Paymaster deposit change, token transfer or allowance, refund, and final balances. A wallet toast, a signed quote, or successful admission simulation alone does not prove execution or finality.

The Paymaster's deposit and stake serve different purposes. The deposit pays UserOperation gas; stake supports validation-storage and reputation rules and is locked for an unstake delay. Stake does not pay gas, and ERC-4337 does not define a universal minimum stake, token price, markup, quota, or service-level guarantee.

<a id="example"></a>

## Contoh perhitungan

- **Deposit capacity.** A Paymaster has `0.50 ETH` deposited. If each accepted operation reserves a maximum cost of `0.03 ETH`, a simplified capacity check is `floor(0.50 / 0.03) = 16` operations, reserving `0.48 ETH` and leaving `0.02 ETH`. Operation `17` needs more deposit or a lower maximum cost. Concurrent reservations, gas-price changes, penalties, and other included operations can reduce practical capacity.
- **Token quote.** A service estimates native gas at `0.004 ETH`, uses `3,000 USDC/ETH`, and adds a `5%` service margin: `0.004 × 3,000 × 1.05 = 12.60 USDC`. The user should compare that capped charge with the quoted expiry and refund rule, not assume `12.60 USDC` equals final gas. A stale oracle, wrong decimals, excessive allowance, front-running, or a nonrefundable markup can make the token cost materially higher than the native gas settled by EntryPoint.

These are accounting examples, not protocol constants. Read current state and service terms on the intended chain before signing.

<a id="risks"></a>

## Risiko dan kontrol

- **Service denial or lockout:** keep a tested self-funded route or an independent Paymaster and enough native gas where the account design permits it.
- **Deposit or quota exhaustion:** check the Paymaster's EntryPoint balance, per-user limits, quote validity, and recent rejection rate; do not treat an issued quote as reserved capacity unless the service explicitly guarantees it.
- **Malicious authorization:** verify the requesting origin, chain, EntryPoint, Paymaster address, token, spender, amount, nonce, deadline, and target calls before signing Paymaster data, a permit, or an approval.
- **Unlimited allowance:** prefer an exact or bounded token approval and revoke residual allowance through an independent route after use. Revocation itself also needs a viable submission path.
- **Pricing and oracle error:** compare the maximum token charge with native gas using the same timestamp, units, and token decimals; record spread, service fee, refund behavior, and who bears price movement.
- **Validation mismatch:** simulate the final signed operation, not only stub data. State changes between simulation and inclusion can invalidate a balance, nonce, allowlist, quota, oracle, or expiry check.
- **Execution and `postOp` failure:** budget for gas even when the target call reverts, and verify whether token settlement occurred. Admission simulation does not guarantee the application call.
- **Upgradeable or privileged code:** inspect verified bytecode, proxy implementation, owners, upgrade delay, pause controls, withdrawal authority, and incident history for both on-chain contracts and the signing service.
- **Bundler policy and reputation:** one bundler may throttle or reject a Paymaster that another accepts. Confirm compatible alternatives without assuming that all ERC-4337 mempools apply identical local policy.
- **Phishing during outages:** use independently verified contract addresses and official multi-channel notices. Do not sign a migration, refund, or “reactivation” message received only through direct messages.

If sponsorship fails, stop repeated signing and broadcasting. Save the full RPC error and UserOperation hash, then query an independent bundler and chain RPC for the nonce, receipt, events, balances, Paymaster deposit, and token allowance. Distinguish rejection before inclusion from execution revert after inclusion: only the latter has an on-chain receipt and settled gas.

<a id="misconceptions"></a>

## Kesalahpahaman umum

- “Paymaster means gasless.” Native gas is paid; the sponsor, user, or service ultimately bears the cost.
- “A signed quote guarantees inclusion.” The operation can still expire, fail validation, be rejected by a bundler, or lose capacity before inclusion.
- “Stake is the gas balance.” Stake and deposit are separate; the EntryPoint charges gas from the deposit.
- “Successful simulation guarantees the transfer.” Validation simulation checks admission and fee safety, not execution success, inclusion, or finality.
- “Losing the Paymaster loses the account assets.” Sponsorship failure is normally a liveness problem, but it can become a serious lockout if the account has no usable fallback path.

<a id="related"></a>

## Topik terkait

- [Account Abstraction](/id/crypto/account-abstraction/)
- [Cryptoeconomic security](/id/crypto/crypto-economic-security/)
- [Permit2 signature](/id/crypto/permit2-signature-risk/)
- [Transaction simulation](/id/crypto/transaction-simulation/)
- [Wallet signature](/id/crypto/wallet-signature/)

<a id="sources"></a>

## Sumber

- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337)
- [ERC-7562: Account Abstraction Validation Scope Rules](https://eips.ethereum.org/EIPS/eip-7562)
- [ERC-7769: JSON-RPC API for ERC-4337](https://eips.ethereum.org/EIPS/eip-7769)
- [Security and Griefing Protection](https://docs.erc4337.io/paymasters/security-and-griefing)

Source: https://wiki.fcontext.com/id/crypto/erc4337-paymaster-risk/index.mdx