ERC-865: Paying gas fees with tokens

LeeMaimai

/Oct 16, 2025

Key Takeaways

• ERC-865 allows users to pay transaction fees in tokens they already hold, improving onboarding.

• The concept has evolved into practical applications through meta-transactions and account abstraction.

• Users can transact without needing ETH for gas, enhancing user experience and consistency.

• Security measures like typed data signing and smart contract audits are crucial for safe implementations.

Paying gas fees with ETH has long been a friction point for new users on Ethereum. The idea behind ERC-865 is simple and compelling: let users pay transaction fees in the tokens they already hold (for example, USDC or DAI), while a relayer or paymaster handles the ETH gas behind the scenes. Although ERC-865 itself was never standardized, its core concept—abstracting who pays and in what currency—has evolved through meta-transactions and account abstraction to become practical in 2025.

What ERC-865 set out to solve

ERC-865 proposed a pattern where the user signs a transaction off-chain, including a fee denominated in a chosen ERC-20 token. A relayer submits this transaction on-chain, pays the ETH gas, and is reimbursed in tokens via a smart contract. This removes the need for the user to hold ETH solely to pay gas, improving onboarding and enabling smoother dApp experiences.

While ERC-865 didn’t become an official standard, it laid the groundwork for modern mechanisms like meta-transactions and account abstraction that make “pay gas with tokens” viable today. For the original token standard context, see the ERC-20 specification and how token allowances enable these flows in smart contracts via permit-style approvals (EIP-20, EIP-2612).

How the concept works in practice

At a high level:

The user signs intent off-chain (often with typed data) specifying action and token-denominated fee.
A relayer or paymaster submits the transaction, paying gas in ETH.
A smart contract transfers the user’s tokens to compensate the relayer/paymaster.
Replay protection, fee limits, and domain separation prevent misuse.

Typed data signing and robust domain separation are critical for safety and UX; see EIP-712.

The modern stack: meta-transactions and account abstraction

Two main approaches have matured:

Meta-transactions with trusted forwarders
- Users sign messages; relayers submit them on-chain through a forwarder that verifies the signature and executes the call on behalf of the user.
- Standardized via EIP-2771, and widely adopted by tooling like OpenGSN’s Gas Station Network, whose docs cover sponsorship patterns and relayer markets (OpenGSN docs).
Account abstraction (EIP-4337)
- Separates the concept of a “user operation” from legacy transactions. Bundlers collect user operations and submit them, while paymasters define alternative fee payment policies—e.g., allowing USDC fees or sponsoring specific dApp actions.
- This model is formalized by EIP-4337 and its rollout was announced on the Ethereum Foundation blog (Account Abstraction with EIP-4337).
- Developers can explore account abstraction concepts, user operations, and paymasters in Ethereum’s documentation (Account abstraction overview).

These patterns generalize the original ERC-865 objective: end users can transact without worrying about ETH for gas, while relayers/bundlers and paymasters manage costs and risk.

Why paying gas with tokens matters

Onboarding: New users don’t need ETH to start using a dApp. They can transact with the assets they already hold.
UX consistency: Fees can be denominated in stablecoins for predictable costs.
Business logic: dApps can sponsor specific actions, acquire users, or tailor fee policies by integrating paymasters or meta-transaction relayers.

Risks and design considerations

Relayer trust and markets: You must design protections against griefing and ensure relayer incentives are fair. Systems like OpenGSN tackle relayer incentives and reputation (OpenGSN docs).
Pricing and oracles: Using tokens for fees requires fair conversion rates and secure oracle integrations to prevent underpayment or exploitation.
Signature safety: Typed data (EIP-712) and explicit domain separation are essential to mitigate phishing and replay.
Token approvals: Prefer permit flows (EIP-2612) over unlimited approvals where possible, and set caps to reduce blast radius (EIP-2612).
Smart contract audits: The forwarder, paymaster, and reimbursement logic must be carefully audited to avoid draining tokens or enabling MEV exploits.

2025 landscape and what’s next

In 2025, account abstraction is widely supported by wallets, SDKs, and bundler infrastructure, and paymasters are becoming the de facto way to implement “pay gas with tokens.” Discussions on improving externally owned account capabilities continue, with proposals like EIP-3074 and EIP-7702 exploring safer authorization and UX improvements that complement abstraction-based designs. While ERC-865 itself isn’t a live standard, the ecosystem has converged on robust alternatives that deliver its core promise.

Implementation guidance for developers

For dApps:
- Start with a trusted forwarder using EIP-2771 for simple meta-transactions, or integrate OpenGSN for a production-ready relayer network (OpenGSN docs).
- Consider account abstraction with a paymaster to accept stablecoins or specific ERC-20s as fees (EIP-4337; EF blog overview).
- Use typed data signing (EIP-712) and permit flows (EIP-2612) to improve UX and safety.
For security:
- Limit fee caps and rate sources; simulate transactions off-chain before submission.
- Restrict sponsor policies to specific contract methods and callers to avoid abuse.
- Monitor relayer performance and maintain fallback strategies.

What users should expect

As more wallets and dApps adopt account abstraction and meta-transactions, you’ll increasingly be able to transact without holding ETH. Fees may be paid in stablecoins or even sponsored entirely by the dApp for certain actions. Always review what you’re signing—typed data makes intent clearer—and use hardware wallets for stronger key protection.

A practical note on wallets

When using paymasters or meta-transactions, your wallet must sign structured messages securely and consistently. OneKey hardware wallets support EIP-712 typed data signing and are designed to keep your private keys offline while integrating seamlessly with modern dApp flows. If you plan to use account abstraction or meta-transaction features regularly, a hardware wallet that handles complex signatures while protecting keys can materially reduce risk in day-to-day operations.

Conclusion

ERC-865 introduced the idea of paying gas fees with tokens; account abstraction and meta-transactions have turned that idea into reality. In 2025, paymasters, bundlers, and trusted forwarders offer production-grade paths to gas abstraction, enabling smoother onboarding and better UX. As these patterns evolve with proposals like EIP-7702, the ecosystem is steadily moving toward a future where users can transact with the assets they hold—without needing to pre-fund ETH for gas.

References: