Managed paymaster services cover the common cases: sponsor these users, up to this budget. But some products need rules that a dashboard cannot express. Sponsorship only for holders of a membership NFT. Free transactions as part of a paid subscription. Gas paid from a user's in-app balance. Rules that depend on on-chain state in your own contracts. That is when a custom paymaster contract makes sense.
Examples of Custom Paymaster Logic
- Token-gated sponsorship: users holding a specific NFT or token balance transact for free.
- Subscription-based gas: users with an active subscription in your backend get sponsored transactions, others pay.
- Contract-scoped sponsorship: only calls to your own contracts and functions are covered, enforced on-chain.
- Time-based policies: free gas during an onboarding period or campaign window.
- Hybrid models: sponsorship up to a limit, after which users pay in tokens through a token paymaster flow.
Want users to transact without holding gas? See gasless transactions for every method, from paymaster sponsorship and EIP-7702 to relayers and permit signatures.
Designing Within ERC-4337's Rules
A paymaster cannot do anything it likes during validation. ERC-4337 defines validation rules, enforced by bundlers, that restrict which storage a paymaster may read and which opcodes it may use. The reason is protection against operations that pass validation and then fail, wasting the bundler's gas. A paymaster that breaks these rules is simply rejected, or needs to stake in the EntryPoint to get more freedom.
In practice this means splitting the logic: complex decisions are taken off-chain in your backend, which signs an approval, while the paymaster checks the signature and a few simple on-chain conditions. This keeps it compatible with public bundlers and cheap to run.
What We Deliver
- The paymaster contract, tested against the EntryPoint and real bundlers on a testnet.
- The backend signing service with your business rules, rate limits and logging.
- Deposit and stake management in the EntryPoint, with monitoring and automatic refills.
- Admin functions behind a multisig, and a security review before mainnet.
Frequently Asked Questions about Custom Paymasters
When is a custom paymaster better than a managed service?
When your rules depend on your own contracts or backend in ways a service cannot express, when per-transaction service fees add up at your volume, or when you do not want your app to depend on a single provider.
Does a custom paymaster work with any smart account?
Yes, as long as the smart account follows ERC-4337. The paymaster is independent of the account implementation.
Can we start with a managed service and switch later?
Yes, and that is often sensible. The user experience stays the same; only the paymaster address and the approval service change.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
Part of our paymaster development and account abstraction work.
Build Your Own Gas Rules
Tell us how you want gas to work in your product. We will design a paymaster that enforces exactly those rules and stays compatible with the ERC-4337 ecosystem.