MegaFuel ERC-4337 Paymaster

MegaFuel ERC-4337 Paymaster

MegaFuel lets an application sponsor gas for an ERC-4337 UserOperation on BNB Smart Chain. A wallet submits a UserOperation from a smart contract account; a MegaFuel policy decides whether that operation is eligible; MegaFuel signs the paymaster authorization and pays the BNB gas through the EntryPoint.

The wallet user does not need to hold BNB for a sponsored operation. The sponsor's MegaFuel policy is charged the actual gas cost after the operation is executed.

What MegaFuel provides

  • A verifying paymaster for EntryPoint v0.6, v0.7, and v0.8.
  • ERC-7677-compatible paymaster RPC methods: pm_getPaymasterStubData and pm_getPaymasterData.
  • A sponsor-gated Bundler for estimating, submitting, and tracking MegaFuel sponsored UserOperations.
  • Policy enforcement before a final paymaster signature is issued: activation window, 4337 opt-in, balance and spending limits, sender/target/ method rules, and token-receiver rules.
  • Per-policy accounting based on the EntryPoint's actual UserOperation gas cost.
  • Durable Bundler state and receipt lookup for accepted UserOperations.

MegaFuel's Bundler may batch compatible UserOperations internally. This is an implementation detail: a wallet still submits one UserOperation per eth_sendUserOperation call and receives one UserOperation hash.

Availability

EnvironmentChain IDPaymaster RPCBundler RPC
BSC Mainnet56 (0x38)https://bsc-megafuel.nodereal.io/4337/paymasterhttps://bsc-megafuel.nodereal.io/4337/bundler
BSC Testnet97 (0x61)https://bsc-megafuel-testnet.nodereal.io/4337/paymasterhttps://bsc-megafuel-testnet.nodereal.io/4337/bundler

Use eth_supportedEntryPoints on the Bundler endpoint as the live source of truth before sending UserOperations.

Supported EntryPoints

VersionEntryPointUserOperation wire format
v0.80x4337084D9E255Ff0702461CF8895CE9E3b5Ff108Packed v0.7/v0.8 JSON fields
v0.70x0000000071727De22E5E9d8BAf0edAc6f37da032Packed v0.7/v0.8 JSON fields
v0.60x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789Classic unpacked initCode / paymasterAndData fields

v0.6 and v0.7/v0.8 have different UserOperation encodings and account-signature conventions. Always compute and sign the UserOperation hash using the selected EntryPoint and your smart-account implementation. Do not reuse a v0.7/v0.8 payload for v0.6.

How sponsorship works

Wallet / dApp                     MegaFuel                          BSC
─────────────                     ────────                          ───
build UserOperation
      │
      ├─ pm_getPaymasterStubData ─► placeholder paymaster data
      │
      ├─ eth_estimateUserOperationGas ─────────────────────────────► estimate
      │
      ├─ pm_getPaymasterData ─────► policy check + final signature
      │                              reserve policy budget
      │
      ├─ eth_sendUserOperation ───► MegaFuel Bundler
      │                              submit handleOps
      │                                                        ─────► EntryPoint
      │                                                               validates account + paymaster
      │                                                               executes account call
      └─ eth_getUserOperationReceipt ◄────────────────────────────── receipt
                                         policy charged actual gas cost

The final paymaster authorization is short-lived and binds the UserOperation's relevant fields, including gas-related fields. Request it only after gas estimation and submit it promptly.

Policy behavior for 4337

A UserOperation is eligible only when one public MegaFuel policy:

  1. is active, in its configured time window, on the correct chain, and has enable4337: true;
  2. has enough available sponsorship balance and has not exceeded its policy or per-account limits;
  3. matches the smart account sender and the inner account call against the policy's whitelist rules; and
  4. stays within the service-side safety limits for UserOperation gas and gas price.

For a SimpleAccount call, MegaFuel evaluates the call inside execute(...) or executeBatch(...)—not the outer handleOps transaction. For example, if the account transfers a token, whitelist the smart account as the sender and the token contract as the target; do not whitelist the EntryPoint as the target merely because it submits handleOps.

An executeBatch operation is sponsored only if every inner call is eligible under the same policy. This keeps a single UserOperation's charge unambiguous.

Current compatibility boundaries

  • Smart contract accounts only. The sender must be an ERC-4337 smart account. Direct EOA transactions are handled by MegaFuel's EOA Paymaster flow, which remains the mainstream MegaFuel product flow. ERC-4337 is an additional smart-account sponsorship flow.
  • Supported account call ABI. The current policy decoder supports standard SimpleAccount execute(address,uint256,bytes) and executeBatch(...). Partners using another ABI should provide a testnet account and sample callData for compatibility validation before production use.
  • Public policies only. The ERC-4337 API does not yet select a private policy. The policy-management API rejects enable4337: true for a private policy. Do not rely on a private-policy header or owner identity to sponsor a UserOperation.
  • MegaFuel-sponsored operations only. The MegaFuel Bundler accepts UserOperations whose paymaster is a MegaFuel paymaster. It is not a general Bundler for third-party paymasters or self-funded operations.
  • BSC only. This feature is available on BSC Mainnet and BSC Testnet, not opBNB.

Next steps

  1. Read Onboard to ERC-4337 Gas Sponsorship.
  2. Implement the wallet flow.
  3. Use the RPC reference and troubleshooting guide while testing.

Did this page help you?