Skip to main content
This page explains how BOT Chain’s EOA paymaster design lets a normal wallet send a transaction without paying gas, and what you can and can’t rely on today.
No paymaster endpoint is confirmed for BOT Chain (chain 677) or its testnet. BOT Chain documents the design and API, but we found no public endpoint to use. To sponsor gas today, use meta-transactions. See Known limitations.

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:
  1. Check. The wallet or app calls pm_isSponsorable on the paymaster with the transaction details.
  2. Sign. If the paymaster will pay, the user signs the transaction with a gas price of 0.
  3. Send to the paymaster. The signed transaction goes to the paymaster’s eth_sendRawTransaction, not to a public RPC.
  4. 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.
  5. Build. The bundle goes to MEV block builders, which pass blocks to the validators that propose them.
  6. Charge. The paymaster deducts the gas from the sponsor’s account.
Sponsors set policies that decide what they pay for, for example which senders or recipients, which tokens, and how much.

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 to https://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
Two details matter:
  • A legacy transaction. It sets gasPrice directly, 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.
The gasless app template includes an optional paymaster adapter, off by default. It tries the paymaster first and falls back to the relayer paying. It hasn’t been tested against a real paymaster.

Next steps

Meta-transactions

The approach that works today.

Known limitations

What’s missing and the workarounds.
Last modified on October 3, 2026