How to Integrate “Sponsored Gas” for Frictionless User Onboarding

Integrating “sponsored gas” can really help streamline your user onboarding process, especially in crypto applications. It’s a way to eliminate the wallet funding barrier that often deters new users. Let’s dig into how to set this up and make the experience smoother for everyone.

What is Sponsored Gas?

In simple terms, sponsored gas means that a third party, like your platform, covers the gas fees when a user interacts with a smart contract. This means your users don’t need to worry about having enough cryptocurrency to pay for those fees upfront. Pretty handy, right?

Why Use Sponsored Gas?

Here are a few reasons why sponsored gas can be a game-changer:

• Lower Entry Barriers: New users can dive right in without stressing about funding their wallets.
• Enhanced User Experience: Users can focus on what matters--using your app, not worrying about gas fees.
• Increased Adoption: The easier you make it for new users, the more likely they are to sign up and stick around.

How to Implement Sponsored Gas

Getting sponsored gas up and running doesn’t have to be rocket science. Here’s a straightforward process to follow:

1. Choose Your Smart Contract Setup:
   • Decide which transactions will have sponsored gas. You might want to start with critical actions like creating an account or making a first transaction.
2. Set Up a Relayer:
   • A relayer is a service that processes transactions on behalf of users, covering gas costs. You can set one up or use an existing service like Gas Station Network (GSN).
3. User Interface Adjustments:
   • Make sure your app clearly communicates that users don’t need to worry about gas fees. A simple message can go a long way!
4. Testing:
   • Before going live, test your implementation thoroughly. Ensure that transactions go through smoothly and that users understand the process.
5. Launch and Monitor:
   • Once everything’s set, launch your feature! Keep an eye on user feedback and be ready to make improvements as needed.

Example Code Snippet

To get you started, here’s a quick code snippet showing how you might handle a transaction using a relayer:

async function sendTransactionWithRelayer(userAddress, transactionData) {
    const relayer = new Relayer(apiKey);
    const tx = await relayer.sendTransaction(userAddress, transactionData);
    return tx;
}

Conclusion

Integrating sponsored gas can significantly enhance your user onboarding experience. By removing the hassle of gas fees, you’re paving the way for more people to join your platform. So, take the plunge, implement it, and watch your user base grow!

For more detailed information on this topic, feel free to check out the Ethereum documentation and explore further. Happy coding!

Your conversion hits a wall right off the bat. Users click “Swap” and then get hit with a request for ETH they don’t have, or they’re being asked to approve three different calls. Engineering scrambles to put together a faucet, support tickets start piling up, and procurement is wondering why infrastructure costs are rising while activation comes to a standstill. All the while, the product team is just looking for a way to make “one-tap, no-ETH onboarding” work that Finance can easily keep track of.

Since May 7, 2025, the Ethereum mainnet has rolled out EIP‑7702 thanks to the Pectra upgrade. This cool feature allows Externally Owned Accounts (EOAs) to temporarily act like smart accounts for batching and sponsorship. On top of that, ERC‑4337 paymasters have become the norm across Base and Optimism chains and even beyond. Layer 2 networks like zkSync and Starknet are also introducing native paymaster flows. Now, you don’t have to choose between a great user experience and control--you can actually have both if you set things up the right way. (blog.ethereum.org)

• Missed deadlines: A bunch of issues like 4337 mempool quirks, EntryPoint version drift, or a way-too-lax paymaster can really slow down the mainnet launch by weeks. Plus, now with ERC-7562 rules in play, bundlers have to follow these guidelines; if they don’t, your UserOps won’t go through. Take a closer look at the details over here.
• Fraud and user loss: After the whole Pectra situation, those “one-sign” 7702 delegations have led to some serious phishing losses--a real headache when wallets end up authorizing rogue delegates. And if the revocation process is mishandled, it just makes things worse. Check out more on this here.
• Vendor lock-in: If you're using private paymaster APIs without ERC-7677, switching providers or chains will mean lots of rewriting. It’s a hassle you definitely want to avoid. More info is available here.
• OPEX surprises: So, token-gas paymasters like Circle are charging end users a 10% gas markup (though that’s being waived until June 30, 2025--mark your calendars!). It’s a nice touch for user experience, but finance teams will need a solid cost envelope and receipts to keep everything in check. Dive into the details here.

Who This is For (and the Keywords You Care About)

• Head of Product, Consumer Fintech on Base/OP Stack: If you’re in this role, you’ll want to keep an eye on terms like “DAU‑to‑Activation,” “first onchain action,” “per‑DAU COGS,” “A/B activation,” “onramp conversion,” “chargeback exposure,” “batching approvals,” and “USDC‑only gas.”
• Director of Engineering, Wallets/Infra: For those in engineering, focus on keywords such as “EntryPoint v0.8/v0.9,” “ERC‑7677 paymasterService,” “ERC‑7562 compliance,” “paymaster stake/deposit,” “EIP‑7702 undelegation,” “passkeys (P‑256/WebAuthn),” “ERC‑7579 modular accounts,” and “pm_getPaymasterData / StubData.”
• Procurement / Risk: If you’re handling procurement or risk, these terms will be important for you: “SLA/SLO with bundler failover,” “cap table of staked entities,” “SAST/bytecode audit evidence,” “rate limits & allowlists,” “observable sponsorship policy,” and “data minimization (PII‑free).”

We offer a dual-path AA stack that strikes a great balance between user experience, control, and portability:

Gas Policy Blueprint (Business Logic First)

1. Decide Who’s Paying and How:
   • “Free Gas” for First Session: Set up a verifying paymaster that only allows specific methods and parameters, plus limits for each user.
   • “Token-Gas” for Power Users: Use an ERC-20 paymaster (like USDC) that handles real-time foreign exchanges and has daily limits. If you're looking for a simple solution, check out Circle Paymaster for USDC sponsorship across compatible chains. (docs.erc4337.io)
2. Define Sponsorship Triggers You Can Justify to Finance:
   • Onboarding events (like passing KYC or the first swap being $25 or less)
   • Recovery flows (where the paymaster helps out with adding or removing guardians)
   • Promotions (maybe offer three gasless actions each week)
3. Create an “Observability Contract”: Make sure you’re tracking per-UserOp costs, sponsors, policy IDs, and reconciliation tags into your data lake.

2) Architecture Decisions That Avoid Lock-in

• Default path: Go with ERC-4337 v0.8/0.9 along with ERC-7677 paymaster web services (pm_getPaymasterStubData/pm_getPaymasterData) for a user-friendly, wallet-discoverable sponsorship experience. It's a smooth integration with viem’s paymaster helpers to keep things standardized. Check it out here.
• 7702 path for atomic UX: Opt for EIP-7702 to retain users' familiar addresses while batching critical flows. Don't forget to set up a safe "undelegation" path and be mindful of wallet restrictions--like how MetaMask limits random delegates. More details can be found here.
• L2-native AA where it shines: On platforms like zkSync Era and Starknet, you can use native paymasters to slash overhead and make token-gas simpler. Dive into the specifics here.
• Modular accounts via ERC-7579: This is a great way to dodge those wallet-specific plugins. You can take your modules (validators/executors/hooks) and carry them over to different platforms like Safe, Kernel, or Biconomy. For more information, check this out here.

3) Security-First Paymaster Design (Passes Red-Team and Procurement)

• Make sure to follow ERC-7562: this means we need deterministic validation, bounded gas usage, and an isolated state. Don't forget to stake any entity that needs to pull in external reads. Plus, let's add some reputation-aware throttling to keep things smooth in the shared mempool. Check out the details here.
• Look into the “Verifying Paymaster” pattern. Here’s how it works: an off-chain policy service will sign UserOps, and then the on-chain paymaster will verify that signature and check deposit coverage. It’s wise to restrict bundlers and set up allowlists. You can use Coinbase’s reference VerifyingPaymaster as a solid starting point. More on that here.
• For 7702 guardrails, only trust those delegation targets that you know are reliable. Have a clear undelegation playbook ready, simulate potential effects, and keep an eye out for wallet UIs that might block arbitrary 7702 signing. If they do, make sure to have some fallbacks in place. Get more info here.
• And don’t forget about EntryPoint hygiene! Upgrade to v0.8 or v0.9 to benefit from native 7702 support and to decouple paymaster signatures. Also, it’s a good idea to fix those old “initCode” and postOp accounting issues that can trip you up. Check the update logs here.

4) Infra You Control, with Vendor Escape Hatches

• Bundlers: Think multi-region and multi-vendor setups, plus OP Stack for conditional RPC support. Keep an eye on health probes using inclusion rates, time-to-inclusion, and throttling signals. Check it out here.
• Paymasters: You can run your own paymasters or team up with ERC‑7677-compliant providers like Base Paymaster and Coinbase CDP Paymaster, all managed behind policy proxies. Plus, you can switch sponsorship on and off for different campaigns. Get the details here.
• Libraries: Make the most of permissionless.js and viem for those typed AA flows and super quick paymaster swaps. You can dive into it on GitHub.

5) Implementation Playbook (with Exact Calls)

Here’s your handy implementation playbook. We’ll go through the exact calls you need to make sure you're all set to roll.

Step-by-step Breakdown:

1. Identify Your Goals
   • Make sure you know what you want to achieve. What’s your end game? Set clear objectives.
2. Gather Your Tools
   • You’ll need all the right tools. Make sure you have everything ready:
     • Software
     • Hardware
     • Support resources
3. Make the Calls
   • Here’s where it gets specific. Below are the exact calls you should be making:

Example Calls

curl -X POST "https://api.example.com/v1/resource" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"key1":"value1", "key2":"value2"}'

• Get Resource:

curl -X GET "https://api.example.com/v1/resource" \
-H "Authorization: Bearer YOUR_TOKEN"

• Delete Resource:

curl -X DELETE "https://api.example.com/v1/resource/{id}" \
-H "Authorization: Bearer YOUR_TOKEN"

1. Monitor Your Progress
   • Keep an eye on how things are going. You want to adjust your approach if needed. Use tools like analytics or dashboards to track everything.
2. Iterate and Improve
   • Don’t forget to come back and make improvements based on what you learn. This isn’t a one-and-done deal; it’s an ongoing process.

Remember, having a solid playbook is half the battle. Stay flexible and adaptable, and you’ll do great!

A) ERC‑4337 + ERC‑7677 (Base, OP chains, Ethereum)

• The wallet checks out its capabilities and then reaches out to the paymaster service:
  • fetch stub data for an estimate → finalize the paymaster data → sign it → send UserOperation.
• Here’s a minimal example in TypeScript (using viem + permissionless.js):

import { createSmartAccountClient } from 'permissionless';
import { createPaymasterClient } from 'viem/account-abstraction';
import { http } from 'viem';

// 1) Create a paymaster client that speaks ERC‑7677
const paymaster = createPaymasterClient({
  transport: http(process.env.PAYMASTER_URL!) // ERC‑7677 endpoint (pm_getPaymasterData/StubData)
});

// 2) Smart account client (bundler URL can be vendor or self‑hosted)
const client = createSmartAccountClient({
  account, // your 4337 account instance
  chain,   // e.g., base
  bundlerTransport: http(process.env.BUNDLER_URL!),
  paymaster
});

// 3) Build + send a sponsored UserOp
const hash = await client.sendUserOperation({
  uo: { target, data, value: 0n, /* ... */ },
  paymaster: { policyId: 'onboarding-v1' } // provider-specific context
});

• The Base “paymasterService” feature (ERC‑7677) and gasless guides are now spotlighted in the Base documentation. You can easily configure sponsorship limits and credits through CDP. Check it out here: (docs.base.org)

B) EIP‑7702 “Smart EOA” Path (Batching + Sponsorship Without New Address)

• Stick with your current signer address, and if necessary, you can delegate to a reliable smart account setup. Just a heads up, some wallets might limit who you can delegate to.
• Check out Alchemy’s 7702 guidance for all the details on delegation and undelegation processes, plus info on any wallet limitations you might encounter:

Key Operational Note

If you want to undelegate, just sign an authorization that delegates to address(0) and send a direct L1/L2 transaction. Keep in mind that bundlers won’t relay undelegations. You can find more info here: (alchemy.com).

C) zkSync Era native paymaster (token‑gas with EraVM)

• The SDK lets you use paymasterParams in your transaction's custom data, whether you’re going with “ApprovalBased” or “General” flows. Plus, Era offers a testnet paymaster to help you get started quickly. (docs.zksync.io)

const tx = {
  to: RECEIVER,
  value: 1n,
  customData: {
    paymasterParams: getPaymasterParams(PAYMASTER_ADDR, {
      type: 'ApprovalBased',
      token: USDC_ADDR,
      minimalAllowance: 1n,
      innerInput: new Uint8Array(),
    }),
  },
};
await wallet.signAndSend(tx);

D) Starknet Paymaster (Native AA, SNIP‑29/9 Compat)

• With the latest updates, starknet.js now showcases Paymaster flows that include fully “sponsored” transactions. Just make sure your accounts are SNIP‑9 compatible! Check it out here: (starknetjs.com)

import { PaymasterRpc } from 'starknet';
const paymaster = new PaymasterRpc({ default: true }); // or pass a specific service URL
await account.execute(calls, { paymaster });

E) USDC-only gas with Circle Paymaster (ERC-4337 v0.7/v0.8, 7702-compatible)

• No developer fees here! The end user just pays a 10% gas uplift when needed. It works with EOAs through 7702 and SCAs with 4337 across multiple chains like Arbitrum and Base. This setup is fantastic for that smooth “USDC-native” fintech experience. Check it out here: (developers.circle.com)

Best Emerging Practices (Q1-Q2 2026)

• Start using ERC‑7677 now so that wallets can easily find and connect to your paymaster. Plus, switching providers becomes a breeze! Check it out here.
• Implement ERC‑7562 locally: make sure to throttle or bounce any user operations that don’t meet the validation criteria. It’s also a good idea to publish stake and deposit dashboards for each paymaster--this will help keep those inclusion rates nice and high. More info can be found here.
• Stick with EntryPoint v0.8+; if you upgrade to v0.9, you’ll get the new paymasterSignature for parallel signing, improved error messages, and events for 7702. Don't forget to plan the retirement of the older v0.6/v0.7 versions internally. You can learn more here.
• Go for ERC‑7579 modular accounts to steer clear of any SDK-specific plugins. This way, you can reuse validators (think passkeys), hooks (session keys), and executors across different stacks. More details are available here.
• If you're working on the Base/OP Stack, make sure to leverage the conditional RPC/mempool features designed for 4337 bundlers. This will significantly reduce the pain from reorgs and help with inclusion variance. You can check out the specifics here.

Proof: GTM Metrics and Measuring ROI (What We Share with Product, Finance, and Procurement)

Let’s be real--your CFO isn’t going to be interested in “4337 vs 7702.” What really matters to them is things like CAC payback and COGS. So, here’s how we break it down and show the real impact:

• Activation lift: This measures the percentage of new wallets that pull off a first on-chain action within 24 hours.
  • Sponsored gas usually helps reduce the “fetch ETH” drop-off and rolls multiple approvals into one easy action. Base’s docs highlight that you can expect fees under a penny, and when you couple that with sponsorship, it really smooths out the biggest UX bump on day one. (docs.cdp.coinbase.com)
• Cost per activated user: You can figure this out by taking the total (sponsored gas spend + paymaster markup + infra) and dividing it by the number of activated users.
  • So, if your average sponsored action on Base costs around $0.003 and you sponsor three actions, your gas costs per user are under one cent. Even with a 10% uplift from the USDC paymaster, you’re still looking at costs in the cents range, not dollars. (docs.cdp.coinbase.com)
• Reliability SLOs: We keep track of metrics like the time to inclusion (p95), inclusion rates, and user operations that get rejected due to ERC-7562 violations. OP Labs’ BigQuery 4337 datasets, along with the ERC-4337 metrics guide, let us calculate daily paymaster volumes and inclusion stats by chain or app. We’ll set this up on a dashboard that your ops team can manage. (docs.erc4337.io)
• Fraud/safety: Here, we’re looking at the percentage of 7702 delegations that went to non-allowlisted targets, the mean time to recover undelegations, and the number of phishing-pattern requests that got flagged by our simulations per 1,000 sessions. Wallet and provider docs clearly outline the 7702 rules and undelegation processes, and our runbooks align with that. (alchemy.com)
• Procurement controls: These include expenditure caps per policy, rate limits, geo/state restrictions, and signed receipts that include policyId, paymaster, and userOpHash, all exported for Finance.

What We're Working On in 2-6 Weeks (Example Milestones)

Week 1

• We'll kick things off with our architecture choice doc. We're going with 4337 and ERC‑7677 as our primary focus, with 7702 as a fallback. Plus, we’ll be diving into policy design alongside Finance--think caps, allowlists, and receipts.
• Next up, we'll choose our providers for each chain. For instance, we’re looking at using the Base Paymaster alongside a self-hosted verifying paymaster. We'll also check out Pimlico/Alchemy for bundlers and Circle Paymaster for handling USDC flows. You can find more about this here.

Week 2-3

• Dive into integrating viem/permissionless.js. Make sure to add those wallet capability checks, and connect up pm_getPaymasterStubData/Data. We're also rolling out the Policy Service to handle signed sponsorships along with the contract and method allowlists. Check out the details here: (eips.ethereum.org).
• Time to tackle the EntryPoint v0.8+ deployment checks. Keep an eye on stake and deposit sizing, and don’t forget to set up the ERC‑7562 simulation harness in CI. For more info, you can visit this link: (github.com).

Week 4

• We’re kicking off the zkSync/Starknet paymaster pilot focusing on a narrow flow, like tipping or swapping USDC, while keeping it smooth with native AA to cut down on overhead. Check out the details here.
• For high-value transactions, we’re rolling out a 7702 batch-only path. Plus, we’ll be adding an undelegation UI and some documentation to help you navigate it.

Week 5-6

• Time for the A/B experiment! We’ll be comparing gasless against the control for our top 2 flows. Our goals are to measure activation lift, p95 inclusion, and per-DAU COGS. Once we’ve got our findings, we'll hand off the dashboard and runbooks, which will cover reconciliation, alerts, and any abuse monitoring.

Practical snippets you can paste this sprint

Here are some handy code snippets you can easily drop into your project this sprint. They’ll save you time and effort, so you can focus on what really matters.

1. Fetching Data from an API

If you're looking to pull in data from an API, here’s a simple way to do it with fetch:

async function fetchData(url) {
  try {
    const response = await fetch(url);
    if (!response.ok) throw new Error('Network response was not ok');
    const data = await response.json();
    return data;
  } catch (error) {
    console.error('There has been a problem with your fetch operation:', error);
  }
}

Just replace url with your API endpoint, and you’re good to go!

2. Debouncing Input

To improve performance when dealing with input events, you can debounce your function calls like this:

function debounce(func, delay) {
  let timeout;
  return function(...args) {
    const context = this;
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(context, args), delay);
  };
}

This will make sure your function only runs after the user has stopped typing for the specified delay.

3. Simple Local Storage Utility

For quick access to local storage, check out this simple utility:

const storage = {
  setItem: (key, value) => localStorage.setItem(key, JSON.stringify(value)),
  getItem: (key) => {
    const item = localStorage.getItem(key);
    return item ? JSON.parse(item) : null;
  },
  removeItem: (key) => localStorage.removeItem(key),
};

Use it to store, retrieve, or remove items with ease!

4. CSS Flexbox Centering

Need to center a div both vertically and horizontally? Flexbox to the rescue!

.centered {
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100vh; /* Full height of the viewport */
}

Just add the centered class to your div, and it’s centered!

5. Basic Responsive Font Size

Want your text to scale with the viewport? Here’s a straightforward approach:

.responsive-text {
  font-size: calc(1rem + 1vw);
}

This makes sure your text adjusts nicely as the screen size changes.

Feel free to tweak these snippets to fit your needs, and good luck with your sprint!

1. ERC‑7677: First, grab the stub for estimation, and then wrap things up by finalizing the data.

// Estimation phase (stub)
const stub = await paymasterClient.getPaymasterStubData({
  sender, nonce, callData, maxFeePerGas, maxPriorityFeePerGas, /* ... */
  context: { policyId: 'onboarding-v1' } // provider-defined
});

// After gas calc, request final data
const final = await paymasterClient.getPaymasterData({
  sender, nonce, callData, /* ... */, context: { policyId: 'onboarding-v1' }
});

// Merge into UserOp and sign

Spec methods are pretty standardized, and viem takes care of wrapping both calls for you. You can check it out here: (eips.ethereum.org).

1. EntryPoint v0.9 Parallel Paymaster Signature (Cut UI Latency)

• With v0.9, we've introduced a special paymasterSignature field. This means users won't have to hang around waiting for the provider to sign before the wallet confirmation pops up. It's all about reducing drop-offs, especially on those slower networks. Check it out on GitHub!

3) 7702 Undelegation Runbook (Paste into Your Wiki)

• First things first, fund the account with some native gas.
• Next up, sign the EIP‑7702 authorization that delegates to address(0) using currentNonce + 1.
• Finally, go ahead and submit an empty transaction along with the authorization (just a heads up, bundlers won’t relay undelegations). You can check this out for more info: alchemy.com.

1. zkSync “ApprovalBased” Paymaster (USDC token-gas)

• Go ahead and use EraVM-compiled contracts; the testnet comes with a handy built-in paymaster to help speed up your pilots. Check it out here: (docs.zksync.io)

Risk Controls We Bake In (So Security Says “Yes”)

• Strict Allowlists: We’re all about contract + selector + argument limits and having rate limits for each user/session. No blanket sponsorship here!
• Staked Entities with Reputation Budgets: To keep things secure, we’re banning shared mutable state in validation unless it’s staked, as per ERC‑7562.
• Phishing-Aware 7702: We only delegate to audited implementations. Plus, we simulate the effects and provide easy-to-read summaries--oh, and you can undelegate with just one click!
• Evidence for Procurement: We ensure everything checks out with entry point version numbers, paymaster code hashes, audits, bundler SLOs, and signed sponsorship receipts.

Where We Fit into Your Roadmap (And How We're Holding Ourselves Accountable)

• Looking to speed things up for mainnet? We’ve got you covered with our “MVP sponsored gas.” You can expect this to align with Finance’s reconciliation and pass Risk’s checks within about 4-8 weeks, depending on the chain coverage and wallet mix.
• Want to avoid vendor lock-in? We deliver modules that are in line with ERC‑7677 and ERC‑7579, letting you switch providers without the hassle of rewriting your app. Check it out here: (eips.ethereum.org).

Services You’ll Likely Need (and How We Can Help)

• Strategy and Architecture: Let’s figure out the best paths for your users! We can map their journeys to the right AA paths (4337/7702/native) and chains. Check out our custom blockchain integration services and cross‑chain solutions development.
  • Blockchain integration
  • Cross‑chain solutions development
• Delivery: We’re here to help you set up paymasters, bundlers, and optimize wallet UX with our tried-and-true templates in Foundry/TypeScript and Cairo/EraVM. Dive into our web3 development services and custom blockchain development services.
  • Web3 development services
  • Blockchain development services
• Security: We take your security seriously! We threat-model the 7702 delegation risks, audit verifying/token paymasters, and establish detection rules for ERC‑7562 violations. Keep your project safe with our security audit services.
  • Security audit services
• Product Enablement: We deliver dashboards and go-to-market (GTM) experiments that help you see activation lifts and daily active user (DAU) gas costs. If you’re part of a protocol team, we also assist with fundraising efforts to scale user subsidies in a responsible way.
  • Fundraising

Appendix: What changed recently (why now)

• Pectra activated on May 7, 2025: EIP‑7702 is officially up and running! This means we’ve got batching, sponsorship, and recovery flows happening without the need for new addresses. Check out all the details here.
• EntryPoint v0.8: This version brings in native 7702 support along with those handy ERC‑712‑style signatures. And guess what? v0.9 is on the way, featuring a speedier paymaster signature flow and better observability. You can see more on this here.
• Standardization wave: We’ve seen some solid progress with the stabilization of AA integrations thanks to ERC‑7677 (paymaster API), ERC‑7562 (validation rules/reputation), and ERC‑7579 (modular accounts). This wave has really helped to cut down on vendor risk! Dive into the specifics here.
• Providers matured: We now have the Base/CDP Paymaster with credits, the Circle Paymaster for USDC, native paymasters from zkSync and Starknet, plus some cool OP Stack enhancements for bundlers. For a deeper look, check out the info here.

The decision framework (pick your stack in 60 seconds)

• If you're aiming for USDC-only gas and want the widest wallet reach right now, go for ERC‑4337 v0.8/0.9 with ERC‑7677, plus a USDC paymaster (you can choose either Circle or set up your own token paymaster). Don’t forget to include the 7702 fallback for those atomic flows. You can check it out here.
• Looking to avoid any infra vendors and keep things atomic? Opt for the 7702 “smart EOA” with a vetted delegate. You can sponsor selectively using 4337 when token gas is needed. More info available here.
• Want to keep it light on a single L2 with the least per-action overhead? Then, consider using zkSync or Starknet native AA paymasters. Dive into the details here.

Personalized CTA

Hey there, if you're the Head of Product at a fintech gearing up to launch on Base in Q2 2026 and you're looking for “day‑0 activation without ETH,” why not book our 45‑minute Gasless Readiness Review? In this session, we’ll simulate your top five flows on Base, work out your per‑DAU COGS, define an ERC‑7677 policy that Finance can get behind, and come up with a one-sprint implementation plan just for you.

Ready to dive in? Start here with our [web3 development services] or chat directly with our AA architects through our [blockchain development services] page.

• Web3 development services
• Blockchain development services