ERC-4337 Operating Limits and Policy Funding

This page makes MegaFuel's current ERC-4337 service safeguards explicit. They
protect sponsors from an accidentally or intentionally oversized UserOperation;
they do not replace policy spending caps or an application's own risk controls.

Current service limits

The following values are the currently deployed service configuration as of
2026-09-20. A change to a service limit can be deployed independently of a
policy, so production integrations must handle a cap rejection rather than
assuming an unlimited value forever.

Control	BSC Mainnet	BSC Testnet	Meaning
`maxFeePerGas`	`1,000,000,000` wei (1 gwei)	`1,000,000,000` wei (1 gwei)	Maximum fee cap accepted for sponsorship
`maxPriorityFeePerGas`	Must be no greater than `maxFeePerGas`	Same	Consistent EIP-1559 fee pair required
Aggregate UserOperation gas	`2,000,000` gas	`2,000,000` gas	Ceiling across declared account and paymaster gas limits
Final paymaster authorization	600 seconds	Short-lived; obtain and submit immediately	Signed authorization expires and cannot be reused after a bound field changes
Internal `handleOps` batch	At most 8 compatible UserOperations	At most 8 compatible UserOperations	Bundler implementation limit, not a wallet submission quota

The Bundler drains ready work approximately every three seconds. It does not
wait to collect eight operations before submitting a compatible batch. An
unmined private-builder attempt is reconsidered after approximately 30 seconds;
the Bundler has a bounded UserOperation lifetime of up to 10 minutes.

There is no public availability, inclusion-latency, indexing-latency, or
per-client rate-limit SLA. Builder and network conditions can delay inclusion.
Wallets must use lifecycle polling and present a recoverable pending state rather
than treating an accepted userOpHash as a transaction confirmation.

Wallet behavior at a cap or timeout

Call eth_estimateUserOperationGas; do not invent final gas limits or send
final zero-valued gas fields.
Keep maxPriorityFeePerGas <= maxFeePerGas and stay at or below the active
fee cap.
If pm_getPaymasterData rejects a gas or fee value, lower the declared value
or redesign the application action. Do not repeatedly resubmit the same
rejected authorization.
Poll receipt and lifecycle status with backoff. A useful user-facing threshold
is 120 seconds, followed by background polling until a terminal lifecycle
state.
On rejected, expired, or dropped, rebuild from the current nonce and
request fresh paymaster data before signing again.

How policy funding works

Two balances serve different purposes:

Balance	What it funds	How a sponsor uses it
MegaFuel policy `remainingBalance`	Sponsor credit and policy accounting for an eligible UserOperation	Fund it using the approved sponsor policy-management flow
EntryPoint Paymaster deposit	On-chain BNB used by the MegaFuel Paymaster during settlement	Operated by MegaFuel; it is not a sponsor policy funding address

Do not transfer BNB to an EntryPoint or Paymaster contract to fund a sponsor
policy. That does not increase remainingBalance. Conversely, a policy's
off-chain credit does not expose the Paymaster's operational EntryPoint deposit
to a sponsor.

The administrative pm_depositToPolicy operation is restricted to authorized
operators. A wallet or dApp should use the approved sponsor funding workflow,
then verify the result with the policy-management API:

Query pm_getPolicyByUuid and confirm activated, enable4337, and a
positive remainingBalance.
Query pm_listDepositsByPolicyUuid using authorized sponsor/API access and
verify the expected policy credit exists.
Record sponsoredGasfee and remainingBalance before the Testnet action.
Submit one sponsored UserOperation and obtain an included receipt with
actualGasCost.
Query the policy every five seconds for up to 60 seconds. The expected delta
is +actualGasCost for sponsoredGasfee and -actualGasCost for
remainingBalance.

Treat a missing accounting delta after that window as an operational issue. Keep
the UserOperation hash, outer transaction hash, policy UUID, and the before/after
values for the support team; never send credentials or owner keys.

Policy selection and overlaps

ERC-4337 sponsorship supports public policies only. One intended operation should
match exactly one active public policy. There is no public API that previews the
selected policy and no public ordering/priority contract for overlapping rules.

Before enabling a new narrow policy for an action already covered by a broad
policy, narrow or deactivate the broad policy first. For an executeBatch, every
inner call must be eligible under the same one policy; multiple policies cannot
be combined to sponsor one UserOperation.

Production acceptance checklist

Policy is public, active, 4337-enabled, on the right chain, and funded.
The action matches one policy only, including every batch inner call.
The wallet honors the current gas and fee ceilings.
A Testnet run confirmed success, receipt actualGasCost, and policy
accounting deltas.
Alerts cover low policy remainingBalance, spending-cap exhaustion, and
failed/expired lifecycle outcomes.
The wallet stores userOpHash and can resume status polling after a
restart or an interrupted user session.