How to Set Up Gasless Transactions

Gas fees break onboarding. A user signs up, creates a wallet, tries to interact with your app — and hits a wall because they don't have ETH. They leave. Most of them don't come back.

For AI agents the problem is structural: autonomous systems executing transactions across multiple chains can't be expected to manually source native tokens on each one.

Gasless transactions fix both problems. Your application sponsors gas costs on behalf of users and agents, removing the friction entirely. This guide covers the full setup on Ethereum/EVM and Solana — from your first gas policy to production best practices.

How Gas Sponsorship Works

The mechanics differ by chain, but the core idea is the same: a third party (you, the developer) pays for the user's transaction costs.

On EVM chains, Openfort uses ERC-4337 Account Abstraction. The flow:

1. Validation — The EntryPoint deducts the required prefund from the paymaster's deposit and calls validatePaymasterUserOp(). The paymaster verifies an off-chain signature to confirm the operation qualifies for sponsorship.
2. Execution — The user's intended call is forwarded to their smart account and executed on-chain.
3. Post-execution — The EntryPoint calls postOp() for accounting: refunding unused gas, collecting ERC-20 payments, or emitting events.

On Solana, fee sponsorship is native to the protocol. Solana transactions have an explicit fee payer field — any account can cover fees for another. Openfort validates the transaction against your policy and signs it as the fee payer before returning it for execution.

Prerequisites

• An Openfort account with API keys
• Node.js 18+
• Basic familiarity with ERC-4337 (for EVM) or Solana transactions

Part 1: Gasless Transactions on EVM Chains

Step 1: Initialize the SDK

Use sk_test_ keys for testnet development. Switch to sk_live_ in production.

Step 2: Create a Gas Policy

A gas policy defines who pays and under what conditions. Three sponsor strategies are available:

Strategy	Description	Best For
pay_for_user	You fully sponsor gas	Gaming, onboarding, free tiers
charge_custom_tokens	User pays in ERC-20 at live rate	DeFi, stablecoin flows
fixed_rate	User pays a fixed token amount	Predictable pricing, in-game currencies

Create a full-sponsorship policy:

Step 3: Register Your Contract and Add Rules

Register the contract to sponsor, then scope the policy to specific functions:

Always include account_functions for new users — without it, their first transaction (account deployment) won't be sponsored, and they hit a gas wall immediately.

Step 4: Execute a Sponsored Transaction

Set optimistic: true for better UX in non-critical flows (returns immediately without waiting for confirmation).

Alternative: Pay Gas in ERC-20 Tokens

If you prefer users to pay gas in USDC rather than receiving free transactions:

Viem Integration

If you're using viem directly, the Openfort paymaster works via the standard createPaymasterClient:

Part 2: Gasless Transactions on Solana

Solana's approach to fee sponsorship is architecturally different from EVM. There's no paymaster contract or ERC-4337 — Solana transactions natively support a feePayer field. Openfort validates your policy, then signs the transaction as the fee payer.

How It Works

1. Your application builds a Solana transaction
2. You send it to Openfort's Solana RPC endpoint
3. Openfort checks the transaction against your sponsorship policy
4. Openfort signs as the fee payer and returns the signed transaction
5. The transaction is submitted to the network — the user pays zero SOL

Openfort's Solana paymaster endpoint:

Replace {cluster} with devnet or mainnet-beta. Include your publishable key in the Authorization header.

Create a Solana Sponsorship Policy

In the Openfort Dashboard, create a policy with the sponsorSolTransaction operation enabled. This policy type controls which Solana transactions receive fee sponsorship.

SDK Example

Using the Kora SDK with Openfort as the fee payer:

Available Solana Endpoints

Method	Description
signAndSendTransaction	Sign as fee payer and broadcast
signTransaction	Sign without broadcasting (for manual submission)
transferTransaction	Create a sponsored token transfer
estimateTransactionFee	Estimate fee in lamports or tokens
getSupportedTokens	List tokens accepted for fee payment

Part 3: Gas Sponsorship for Agent Wallets

Agent wallets — wallets controlled by AI agents, bots, or automated systems — work the same way as user wallets when it comes to gas policies. You apply the same pay_for_user, charge_custom_tokens, or fixed_rate strategies.

This matters for two reasons:

1. Agents shouldn't hold gas — a sponsored wallet removes the operational overhead of keeping agent wallets funded with native tokens on every chain they operate on.
2. Agents need predictable costs — charge_custom_tokens with a fixed_rate lets you predict exactly what each agent transaction costs, which is easier to account for than fluctuating native gas prices.

The setup is identical to user wallets. Create a gas policy, add policy rules scoped to the contracts your agent interacts with, and reference the policy when creating transaction intents. The agent wallet ID replaces the player ID:

Rate limiting is especially useful here — cap agent wallets to prevent runaway transaction loops from draining your gas budget.

Best Practices

Fund your policy before going to production. In testnet, use Openfort's test balance. In production, fund via Balance Credit — gas costs auto-deduct as transactions execute.

Always scope policy rules. An unscoped policy sponsors everything on your account. Lock it down to specific contracts, functions, and rate limits before launch:

Include account_functions for onboarding flows. The first transaction deploys the smart account. Without this rule, new users hit a gas wall on their very first interaction.

Test on testnets before mainnet. Validate that policy rules correctly scope sponsorship, rate limits work as expected, and the full signing flow completes. Polygon Amoy, Base Sepolia, and Sepolia are good choices.

Monitor gas spending. Track costs via the Openfort dashboard. Set alerts for unusual spend patterns. If a policy burns through budget faster than expected, tighten rate limits or narrow the function scope.

Handle policy exhaustion gracefully. If your policy balance hits zero, sponsored transactions fail. Build a fallback in your app — either a UI prompt to inform the user, or an automated top-up triggered by a balance webhook — so policy exhaustion doesn't silently break your product in production.

Next Steps

• Ethereum Paymaster Reference — full RPC endpoint docs for EVM chains
• Solana Paymaster Reference — Solana fee sponsorship endpoints and SDK examples
• Gas Sponsorship Configuration — detailed policy configuration via dashboard and API
• Embedded Wallets Explained — pair gasless transactions with embedded wallets for the best onboarding UX