What it is
An EOA paymaster lets an ordinary wallet (an externally owned account, or EOA) send a transaction with a gas price of 0. A paymaster service pays the gas instead. Unlike meta-transactions, your contracts don’t change, and users sign a normal transaction, not a separate message. BOT Chain describes this design on its EOA paymaster page and names NodeReal’s MegaFuel as an implementation. MegaFuel is documented as a BNB Chain service.How it works
In more detail, based on BOT Chain’s description:- Check. The wallet or app calls
pm_isSponsorableon the paymaster with the transaction details. - Sign. If the paymaster will pay, the user signs the transaction with a gas price of 0.
- Send to the paymaster. The signed transaction goes to the paymaster’s
eth_sendRawTransaction, not to a public RPC. - Bundle. The paymaster creates its own transaction with a higher gas price that covers the cost, and bundles both so they’re included together or not at all.
- Build. The bundle goes to MEV block builders, which pass blocks to the validators that propose them.
- Charge. The paymaster deducts the gas from the sponsor’s account.
Why you can’t send a 0 gas price to the public RPC
The bundle has to reach a builder that accepts it. A normal node rejects a transaction with a gas price of 0. We tested this on testnet on 2026-10-02: sending a 0 gas price transaction from a new wallet tohttps://rpc.bohr.life failed with gasPrice too low. So the paymaster needs its own endpoint and a path to builders, which is the part not confirmed for BOT Chain.
The API
pm_isSponsorable takes one object with the transaction fields, every value hex-encoded:
BOT Chain’s docs say it returns
Sponsorable (a boolean) and SponsorPolicy (the name of the policy that matched). The same page also uses the name gm_sponsorable once. The API specification defines pm_isSponsorable, so use that.
Here is how a script would use it, if your provider gives you an endpoint:
paymaster.ts
- A legacy transaction. It sets
gasPricedirectly, which is what the paymaster design expects. - The send goes to the paymaster. If it goes to the public RPC, it’s rejected, as shown above.
Is it safe for users?
The user still signs a real transaction, so the usual checks apply: read what it does before you sign. The paymaster can see and delay the transaction, but can’t change it without invalidating the signature. If the paymaster never includes it, the nonce stays unused, and the user can replace it with a normal paid transaction.In the Uzo SDK
Planned. A paymaster module for the Uzo SDK is planned. It isn’t in
@uzolabs/sdk 0.2.0.Next steps
Meta-transactions
The approach that works today.
Known limitations
What’s missing and the workarounds.