What are gasless transactions on Ethereum?

The origin story.#

1. 2017 Austin Griffith's Burner Wallet demonstrates gasless onboarding via custodial relayers — the UX appeal of 'user doesn't need ETH' is established.
2. Nov 2018 Yoav Weiss, Dror Tirosh, and Alex Forshtat (Tabookey) publish ERC-1613 (Gas Station Network v1) — the first standardised meta-transaction proposal. ↗
3. Aug 2020 ERC-2771 (Secure Protocol for Native Meta Transactions) finalised by an 11-author group including the Tabookey team and Fabian Vogelsteller. ↗
4. 2020–22 OpenGSN v2, OpenZeppelin Defender Relayer, Gelato Network, and Biconomy SDK build the vendor relayer market on top of ERC-2771. Meta transactions go production.
5. Sept 2021 Vitalik Buterin proposes ERC-4337 with the Tabookey core team — explicitly framed as 'account abstraction without Ethereum protocol changes' in his Medium post title. ↗
6. Mar 2023 ERC-4337 EntryPoint v0.6 deploys to Ethereum mainnet after audits by OpenZeppelin and Certora. Pimlico, Stackup, Alchemy, and Biconomy launch bundler services.
7. 2023 LUKSO mainnet launches with LSP25 + LSP15 baked into the account stack — gasless execution becomes substrate-level on the account contract from day one. ↗
8. Nov 2024 At Devcon SEA, ERC-4337 co-author Yoav Weiss outlines a roadmap toward a 'modular native AA approach for L1 and L2' — the spec's own lead acknowledging the layered model's limits. ↗
9. Dec 2024 EIP-7851 proposed by Liyi Guo and Nicolas Consigny — adds an ECDSA-disabled delegation prefix and SETSELFDELEGATE opcode to let wallet code burn the residual EOA authority. Still Draft as of mid-2026. ↗
10. May 2025 Pectra hard fork lands EIP-7702: EOAs gain protocol-level ability to delegate execution to contract code. EntryPoint v0.8 deploys alongside with native 7702 support. ERC-7579 and ERC-6900 modular-account standards remain Draft; consolidation continues. ↗

How Gasless Transactions actually works.#

What's broken about Gasless Transactions.#

1. 01

   The bundler centralisation problem.#

   ERC-4337 UserOperations route through an alt-mempool that's much narrower than Ethereum's L1 mempool. In production, UserOp flow is concentrated around a small set of bundler operators; censorship, reordering, and MEV-extraction risk concentrate with that infrastructure. ERC-4337's own lead maintainer Yoav Weiss has flagged centralisation as a known concern in public talks. Consumer cost: every gasless UX in your app depends on whichever bundlers your wallet vendor talks to staying up, uncensored, and not throttling your flow during a usage spike.

   −

   ERC-4337 handleOps(UserOperation[], beneficiary)

   alt mempool ·bundler-concentrated ·censorship surface

   becomes

   +

   LSP25 account.executeRelayCall(sig, nonce, validity, payload)

   normal L1 mempool ·no parallel infra ·relayer can't escalate

   workarounds tried

   • multiple bundler RPCs with failover
   • shared mempool projects (Skandha, Silius)
   • self-hosted bundler (high SRE cost)

   read the deep-dive →

2. 02

   The paymaster trust + funding overhead.#

   Sponsoring gas on ERC-4337 means operating a paymaster contract (its own ETH deposit at EntryPoint, its own validatePaymasterUserOp, its own postOp accounting, its own DoS surface) — or renting one from Pimlico, Stackup, ZeroDev, Biconomy, Alchemy. Either path has ongoing OPEX and abuse-prevention runtime cost. Consumer cost: a product team shipping a gasless mobile app picks up per-transaction vendor fees plus monthly quotas plus per-paymaster integration code plus a gas-tank that needs ongoing top-ups plus a fraud-prevention layer to stop users from burning the paymaster's deposit on inflated gas estimates.

   −

   ERC-4337 Paymaster.validatePaymasterUserOp + postOp

   separate contract ·own deposit ·two-step trust ·vendor fees

   becomes

   +

   LSP25 account.executeRelayCall(...)

   one function on the account ·no paymaster contract ·relayer is infra

   workarounds tried

   • vendor SaaS paymasters (per-tx fees + SLA)
   • permissioned paymasters with allowlists
   • user-pays-in-stablecoin via ERC-20 paymasters
3. 03

   Validator-module fragmentation.#

   ERC-4337 deliberately left validateUserOp to each smart-account implementation. The result in 2026: ZeroDev Kernel, Safe, Biconomy Nexus, Coinbase Smart Wallet, and Alchemy LightAccount each ship their own validator shape. ERC-7579 and ERC-6900 are converging on modular-account standards — both are still Draft as of mid-2026. Permission auditing happens per-vendor; session-key SDKs are non-portable across wallets; and 'an AA wallet' does not share a permission vocabulary with another 'AA wallet'. Consumer cost: every consumer app integrates against each wallet's SDK separately; cross-wallet sessions don't exist; security review costs scale linearly with the number of wallets you support.

   −

   ERC-4337 validateUserOp() — per-account validator

   non-standard ·wallet-specific ·session-key SDK per vendor

   becomes

   +

   LSP6 Key Manager (standardised permission bitfield)

   AllowedCalls ·AllowedStandards ·AllowedERC725YDataKeys ·uniform across the LSP ecosystem

   workarounds tried

   • ERC-7579 modular accounts (Draft)
   • ERC-6900 modular accounts (Draft)
   • per-vendor session-key SDKs

   read the deep-dive →

4. 04

   Hybrid 7702 account semantics — the residual key problem.#

   EIP-7702 (Pectra, May 2025) lets an EOA delegate execution to contract code, which unlocks ERC-4337 features (batching, gas sponsorship, session keys) without redeploying. But the original secp256k1 key never goes away. An attacker who compromises the EOA's private key can sign another 7702 authorisation, replace the delegation, and reset whatever recovery configuration the user had set. EIP-7851 (proposed Dec 2024 by Liyi Guo and Nicolas Consigny) extends 7702 with an ECDSA-disabled delegation prefix and a SETSELFDELEGATE opcode to let wallet code burn the residual ECDSA authority — but as of mid-2026 it remains a Draft. The 7702 spec itself also flags storage-collision risk when switching delegate implementations. Consumer cost: a 'smart wallet' UX built on 7702 still has an EOA key under the hood that, if stolen, bypasses every recovery and permission layer above it. That's not a UX you can hand to a non-technical user with a straight face.

   −

   EIP-7702 AuthorizationList + delegated EOA

   residual ECDSA key ·storage collisions ·no authoritative recovery

   becomes

   +

   LSP0 + LSP6 Universal Profile (contract from genesis)

   no residual key ·authoritative recovery ·Key Manager replaceable

   workarounds tried

   • EIP-7851 (Draft, Dec 2024) — ECDSA revocation
   • fresh contract account (ERC-4337 standalone, loses address history)
   • hardware-wallet-rooted EOA
5. 05

   Per-protocol contract opt-in — the ERC-2771 tax.#

   The ERC-2771 trusted-forwarder pattern (used by OpenGSN, OpenZeppelin Defender, Gelato Relay, Biconomy SDK) requires every recipient contract in the protected call graph to inherit ERC2771Context and replace every msg.sender reference with _msgSender(). Older OpenZeppelin contracts, third-party libraries, and custom modifiers that don't propagate the convention will silently see the forwarder address as the sender — which breaks permission logic in ways audit tools don't reliably catch. Consumer cost: integrating gasless via 2771 means auditing every contract in the call graph, paying for a security review of every msg.sender reference, and committing to the trusted-forwarder list as a long-lived governance surface. Most product teams shipping consumer apps don't have the bandwidth.

   −

   ERC-2771 _msgSender() + per-contract opt-in

   audit every contract ·library rewrite required ·trusted-forwarder governance

   becomes

   +

   LSP0 + LSP25 msg.sender == account, natively

   zero contract changes ·no convention to enforce ·account is the entry point

   workarounds tried

   • OpenZeppelin ERC2771Context base class
   • Custom static-analysis rules for msg.sender
   • Migrate to ERC-4337 (different tax)
6. 06

   Wallet and SDK fragmentation — the 8-vendor consumer-app problem.#

   There is no single 'ship a gasless consumer app on Ethereum' path. In 2026 a product team picks between: Pimlico (bundler + paymaster + AA SDK), ZeroDev Kernel (modular-account SDK), Coinbase Smart Wallet (closed-vertical), Safe (treasury heritage, AA via modules), Alchemy Account Kit (bundled with their RPC), and Biconomy Nexus (cross-chain unified gas tank). OpenGSN, OpenZeppelin Defender Relayer, and Gelato Relay sit alongside on the 2771 / generic-relayer side. Each ships its own SDK shape, pricing model, SLA, and chain coverage. Consumer cost: vendor lock-in is the default outcome; the alternative is an N-vendor abstraction layer the product team has to maintain. Compare this to integrating Stripe — there's basically one shape. Gasless on Ethereum is the opposite.

   −

   Ethereum AA stack 6+ vendor SDKs, each different

   vendor lock-in ·per-wallet integration ·per-vendor abuse rules

   becomes

   +

   LSP15 Transaction Relay Service API standard

   one spec ·swappable implementations ·reference impl open-source

   workarounds tried

   • abstraction layers (Privy, Dynamic, thirdweb)
   • single-vendor commitment + migration risk
   • wait for ERC-7579 / 6900 to consolidate

Why LUKSO breaks through the bottleneck.#

• LSP25 Execute Relay Call The relay function on the Universal Profile itself. A controller signs a payload with a nonce; a relayer submits the call via executeRelayCall on the account and pays gas. No bundler, no EntryPoint, no paymaster contract — and LSP6 permissions still gate what the signing controller may authorise, so the relayer cannot escalate authority by virtue of paying gas. →
• LSP15 Transaction Relay Service API Standardises the off-chain relayer interface a dapp talks to. The interface is the spec; the implementation is interchangeable. The reference implementation lives at lukso-network/tools-mock-relayer for self-hosting. The 'pick one of six vendor SDKs' tax becomes 'implement against one spec, swap implementations freely'. →
• LSP6 Key Manager The standardised permission vocabulary — AllowedCalls, AllowedStandards, AllowedERC725YDataKeys, value caps, instant revocation. The piece ERC-4337 and EIP-7702 each leave to wallet implementations to invent. Cross-wallet sessions become possible because every wallet reads the same on-chain permission shape. →
• LSP0 ERC-725 Account A contract account from genesis — no EOA key under the hood, no residual ECDSA authority for an attacker to override recovery with. msg.sender at downstream targets is the account, natively, because the account IS the call entry point. No EntryPoint singleton; no trusted forwarder list to govern. →
• LSP20 Call Verification Inline call verification at the account contract layer. The equivalent of validateUserOp, but on the normal call path rather than through an EntryPoint hop. The trace shape stays direct: controller → account → target. →
• LSP1 Universal Receiver One hook for every asset type and every transfer. The receiver-awareness piece ERC-2771 / 4337 / 7702 don't touch at all — accounts can react to incoming value through a single typed entry point, with a Universal Receiver Delegate for dispatch. →

Gasless Transactions vs LSP25+LSP15+LSP6+LSP0 in one table.#

full matrix → gasless transactions vs lsp25+lsp15+lsp6+lsp0 →

When to use which.#

FAQ.#

• 01

  What are gasless transactions? #

  Gasless transactions are blockchain transactions where the user signs an intent off-chain and a third party (a relayer or bundler) submits it on-chain and pays the gas. The user never has to hold the chain's native token to interact with a dapp. 'Gasless' is a UX framing — gas is still paid; it's just paid by someone other than the signer (a sponsoring app, a paymaster, a relayer service, or a custodian).

• 02

  What is a meta transaction? #

  A meta transaction is the on-chain primitive that makes gasless flows work: a user signs an intent payload with EIP-712 typed data; a relayer submits the payload to a forwarder, bundler, or account contract; the destination contract recovers the original signer from the calldata or signature. The first standardised meta-transaction proposal was ERC-1613 (Tabookey, November 2018), succeeded by ERC-2771 (August 2020) and then absorbed into ERC-4337's UserOperation model in September 2021. On LUKSO, LSP25 is the same idea — but the relay function lives on the account contract itself rather than on a separate forwarder.

• 03

  What's the difference between ERC-2771, ERC-4337, and EIP-7702? #

  ERC-2771 (2020) is a contract-level pattern: each recipient contract opts in to ERC2771Context, pins a trusted forwarder address, and extracts the original signer via _msgSender(). ERC-4337 (2021, mainnet Mar 2023) is a much larger architecture: contract accounts submit UserOperations through a parallel mempool, a bundler packs them, a singleton EntryPoint validates, and optional paymasters sponsor gas. EIP-7702 (Pectra, May 2025) is a protocol-level patch: it lets an existing EOA delegate execution to contract code in a single transaction without redeploying. The three are layered, not exclusive — production wallets in 2026 typically combine 7702 (to upgrade the EOA) with 4337 (for the bundler / paymaster infrastructure) and sometimes 2771 (for legacy contract integration).

• 04

  What is a bundler in ERC-4337? #

  A bundler is an off-chain actor that watches the ERC-4337 UserOperation mempool, validates UserOps (by simulating validateUserOp against the destination account and validatePaymasterUserOp against any paymaster), packs valid ones into a single transaction calling EntryPoint.handleOps(), and submits it on-chain. Bundlers earn fees per UserOp. The position is privileged — bundlers can censor, reorder, or extract MEV from the UserOps they see — and bundler centralisation has been flagged by ERC-4337's own maintainers as a known concern. Production bundlers in 2026 include Pimlico, Alchemy, Stackup, Biconomy, and Candide.

• 05

  What is a paymaster? #

  A paymaster is an optional ERC-4337 contract that sponsors gas for a UserOperation. The user signs a UserOp referencing a paymaster; the bundler asks the paymaster (via validatePaymasterUserOp) whether it's willing to cover the gas; the paymaster pays from its own ETH deposit at the EntryPoint; afterwards, postOp runs for any per-user accounting (e.g., charging the user in an ERC-20 token). Paymaster operation is a separate failure surface and an ongoing OPEX line — either you run one (SRE), or you rent one from Pimlico, Stackup, ZeroDev, Biconomy, or Alchemy (per-tx fees, monthly quotas, SLAs).

• 06

  Why hasn't gasless onboarding broken through to consumer apps? #

  Because shipping gasless on Ethereum picks up several structural costs simultaneously: bundler centralisation risk, paymaster funding and abuse-prevention OPEX, per-account validator fragmentation (every wallet ships its own session-key SDK), per-protocol opt-in costs for ERC-2771 paths, residual ECDSA key risk on EIP-7702 EOAs, and lock-in to one of six+ vendor stacks (Pimlico, ZeroDev, Coinbase, Safe, Alchemy, Biconomy). Any individual cost is manageable; together they make 'ship a Tinder, a Spotify, or a Reddit on-chain experience' a much bigger lift than 'integrate Stripe'. The bottleneck isn't any single standard — it's that Ethereum's protocol was built around EOAs and every layered gasless standard is working around that, in different ways, with different fragmentation.

• 07

  Does EIP-7702 fix gasless on Ethereum? #

  Partially. EIP-7702 (activated in the Pectra hard fork, May 2025) lets an existing EOA delegate execution to contract code in a single transaction, which means EOAs can now use ERC-4337's bundler and paymaster infrastructure without redeploying — closing the 'existing addresses can't become smart accounts' gap that the EIP-7702 Motivation section identified. EntryPoint v0.8 deployed alongside Pectra with native 7702 support. But the residual ECDSA key on a delegated EOA remains: an attacker who compromises the original private key can sign another 7702 authorisation to override recovery. EIP-7851 (proposed by Liyi Guo and Nicolas Consigny, December 2024) extends 7702 with an ECDSA-disabled delegation prefix and a SETSELFDELEGATE opcode to let wallet code burn the residual authority — but as of mid-2026 it's still Draft. Pectra closed one gap; the next one is open.

• 08

  How does LUKSO handle gasless transactions? #

  LSP25 (Execute Relay Call) defines executeRelayCall(signature, nonce, validityTimestamps, payload) as a function on the Universal Profile account itself. A controller signs the payload (with a nonce-channel design for parallel relay streams), a relayer submits the on-chain call and pays gas, and LSP6 permissions still gate what the signing controller can authorise — so the relayer is just infrastructure, with no ability to escalate authority by virtue of paying gas. There is no EntryPoint singleton, no UserOperation envelope, no bundler, no paymaster contract, and no trusted-forwarder list to govern. msg.sender at downstream targets is the account itself, natively. The trace shape stays direct: controller → account → target. See the LSP25 spec at ercsolved.dev/standards/lsp25-execute-relay-call/ and the comparison at ercsolved.dev/standards/compare/erc4337-lsp-stack/.

• 09

  What is LSP15 Transaction Relay Service API? #

  LSP15 standardises the off-chain HTTP API that a dapp uses to talk to a relayer. A dapp posts a signed payload; a compliant relayer service validates the signature, submits the transaction via LSP25 executeRelayCall on the destination Universal Profile, and pays the gas. Because LSP15 defines the wire interface, any compliant relayer implementation is swappable — a project can self-host (the reference implementation lives at github.com/lukso-network/tools-mock-relayer), pay a third-party service, or build their own. The vendor-SDK lock-in problem ERC-4337's ecosystem has (six+ different SDK shapes) doesn't exist on LSP15 because the integration is a standardised HTTP spec, not a vendor library.

• 10

  Do I need to run my own bundler to ship a gasless app? #

  On Ethereum with ERC-4337: technically no — Pimlico, Alchemy, Stackup, Biconomy, and ZeroDev all operate bundler RPCs you can pay to use. But you do need to (a) commit to a bundler vendor, (b) manage failover when their service degrades, (c) integrate their AA SDK, and (d) accept the centralisation surface that comes with most of mainnet UserOp volume flowing through 1–2 operators. On LUKSO with LSP25 + LSP15: you can self-host the open-source mock-relayer reference implementation, build your own LSP15-compliant service, or use any compliant relayer. The relayer doesn't gate validation or carry MEV-extraction power the way bundlers do.

• 11

  Can I pay gas in stablecoins or ERC-20 tokens? #

  Yes, via ERC-4337 paymasters that accept ERC-20 payments. The pattern: the user's UserOperation references an ERC-20 paymaster; the bundler asks the paymaster to validate; the paymaster pays ETH gas at the EntryPoint from its own deposit; postOp transfers the user's chosen ERC-20 from the user's account to the paymaster at an exchange rate the paymaster sets. Pimlico, Biconomy, and Alchemy operate ERC-20 paymasters for stablecoins (USDC, USDT, DAI). The user experience is 'I paid in USDC' but the underlying gas accounting still has to settle through ETH and through the paymaster's deposit. On LUKSO, the equivalent pattern lives at the relayer-policy layer: the LSP25 ABI is gas-agnostic, and the relayer can charge the user in any token (or sponsor entirely) via its own off-chain policy.

• 12

  Is gasless the same as account abstraction? #

  Overlapping but not the same. Account abstraction is the broader idea that accounts supply their own validation logic via smart contract code (multisigs, passkeys, session keys, social recovery) instead of being fixed single-keypair EOAs — see ercsolved.dev/erc-4337/ for the deeper treatment. Gasless transactions are specifically about separating the signer from the payer of gas. AA enables gasless (by giving the account programmable validation that can accept a relayer-submitted call), but you can have gasless without AA (ERC-2771 trusted forwarders predate AA and work on EOAs). And you can have AA without gasless (an ERC-4337 wallet where the user pays their own gas via the EntryPoint). They're commonly bundled because the production AA stacks (Pimlico, ZeroDev, etc.) ship gasless and AA together, but the standards are distinct.

Keep reading.#

• execute relay call → LSP25
• transaction relay service api → LSP15
• key manager → LSP6
• erc-725 account → LSP0
• call verification → LSP20
• universal receiver → LSP1
• gasless transactions vs lsp25+lsp15+lsp6+lsp0 (full matrix) → comparison
• all ERC ↔ LSP mappings → matrix
• start from your problem → problems