9 posts tagged with "Account Abstraction"

For five years, "insufficient SOL for transaction" has been Solana's most expensive error message. Every consumer app that ever pitched a non-crypto user lost some percentage of them right there — at the checkout step where a stranger has to acquire a second token just to spend the first one. In April 2026, the Solana Foundation finally shipped the answer: Kora, a fee relayer and signing node that lets dApps sponsor transactions natively, pay fees in any SPL token, and outsource signing to TEEs or KMS-backed vaults. It is not a flashy launch. It is a plumbing upgrade. And plumbing upgrades are how Base and Abstract quietly captured the last twelve months of consumer onboarding.

The question is no longer whether Solana can match the gasless UX of EVM consumer chains. Kora makes that part trivial. The question is whether closing the last-mile gap is enough to win back the developers who already built somewhere else.

What Kora Actually Ships​

Strip away the marketing and Kora is three things bolted together: a transaction relayer, a remote signer, and a policy engine. A dApp constructs a transaction, sets a Kora node as the fee payer, the user signs the payload from an embedded wallet, and the Kora operator co-signs and broadcasts. Validators still get paid in SOL. The user never holds any.

What makes it interesting is the validation layer. A Kora node does not blindly relay anything users hand it. It does three checks before signing:

• Instruction validation against the associated Solana programs, so malformed or malicious instructions get rejected before they hit a leader.
• Oracle-backed fee adequacy, comparing the offered SPL token amount against current SOL price plus operator margin, so the relayer is never running at a loss.
• Allowlist and blocklist enforcement at the program and token level, so an operator running a Kora node for a single dApp never accidentally sponsors a transaction targeting some random unaudited contract.

The signing path is where the architecture gets ambitious. Kora supports remote signing through Turnkey and AWS KMS out of the box, which means the private key that pays fees never lives on the relayer's disk. For a fintech building on Solana, that is the difference between "we rolled our own paymaster and crossed our fingers" and "our key custody story passes a SOC 2 audit."

The whole thing has been audited and differentially fuzz-tested by Runtime Verification, which is the kind of detail you mention only when you expect institutions to read the line item.

Why "Native" Beats "Smart Contract" Here​

The temptation is to compare Kora to ERC-4337 and assume Solana is catching up. The architectures are doing different things, and the difference matters.

ERC-4337 is account abstraction implemented as a parallel system on top of Ethereum. It introduces a separate mempool, a UserOperation object, a bundler role, and an EntryPoint contract — none of which the base protocol natively understands. Bundlers package user operations, paymasters sponsor fees, and an on-chain contract enforces validation. It works, and it has been deployed across Ethereum mainnet and major L2s, but it is a six-year construction project to retrofit a UX feature that the protocol never anticipated.

Solana's design ate that complexity at the protocol layer years ago. Every transaction already has a feePayer field. Partial signatures are native. Programs can validate arbitrary instructions. Kora is not a bundler-and-paymaster construction; it is a node operator that fills in the feePayer slot and signs with one of the partial signatures the protocol already accepts.

The practical consequence is latency and developer surface area. ERC-4337 transactions go through a separate mempool with its own ordering rules and propagation delays. Kora transactions go through the same path as every other Solana transaction, with the same sub-400ms finality. There is no bundler arbitrage market to think about, no EntryPoint contract version to track, no UserOperation gas estimation to debug.

What this buys Solana developers is something close to "set the fee payer field, ship the dApp." What it loses is some of the optionality EVM smart accounts get for free — multi-key auth, batched calls, on-chain session policies — though much of that is being built separately on Solana through PDAs and program-controlled accounts.

The Last-Mile Gap Solana Actually Had​

For all the talk about Solana's developer momentum in 2025 and 2026, the consumer wallet layer was the part that lagged. The infrastructure stack matured fast: Pump.fun's DEX volume topped $2B in Q1 2026, Jito and Marinade dominate liquid staking, Tensor turned NFT trading into a professional terminal. But every one of those products had to ship its own answer to "the user has no SOL."

The workarounds got creative. Pump.fun routed initial token acquisitions through embedded onramps. Jito pre-funded user accounts with dust amounts. Tensor leaned on Phantom and Backpack to handle the SOL acquisition step before users ever reached the bid book. Each of these worked individually and none of them composed. A user who onboarded through Pump.fun's flow did not arrive at Tensor with a fee-paying balance.

Meanwhile Base shipped Coinbase Smart Wallet's passkey flow, free gas sponsorship through Coinbase Developer Platform, and a developer SDK that hides the entire concept of a private key behind email login. Abstract took the same idea further with embedded wallets that feel like Web2 apps. The combined pitch to a consumer-app developer in 2025 was: build on Base, your users will not know they're onchain, and we'll pay the fees while you scale.

Kora does not replicate that pitch line for line. What it does is remove the architectural reason a Solana dApp could not write the same pitch. With Kora, a Solana team can now offer:

• Email or passkey signup through Privy, Turnkey, or Coinbase Embedded Wallets.
• Zero SOL balance required to transact.
• Fees paid in USDC, BONK, or the dApp's native token if it has one.
• Sub-second finality with no bundler in the path.

The pieces existed before. Octane was the open-source ancestor. Circle's Gas Station, Openfort, Portal, Gelato, Biconomy, and a half-dozen other vendors offered fee relaying as a service. What Kora changes is that the Solana Foundation itself is now shipping the standard, audited, KMS-compatible reference implementation. That removes "which third-party paymaster do we trust" from the decision tree for every team that was previously rolling their own or paying a vendor.

The Vendor Layer Above Kora​

Where things get interesting is what happens to the embedded wallet vendors that already built around the gap Kora just closed.

Privy, acquired by Stripe in June 2025, has been the consumer-app wallet of choice for Solana dApps that want email login. Solana is officially a secondary chain for Privy — the depth is on EVM — but the embedded wallet flow extends to Solana, and Privy already supports configuring a fee payer wallet that the app manages. Kora does not replace Privy; it gives Privy a standardized backend to plug into rather than each customer running their own paymaster service.

Turnkey is the security-first embedded signer that pairs naturally with Kora's remote signing API. Turnkey explicitly does not include paymaster infrastructure, so Solana teams that want hardware-isolated keys plus gasless UX have been forced to bolt two vendors together. Kora collapses that integration.

Dynamic, acquired by Fireblocks in 2025, brings multi-chain auth to institutional teams. The Fireblocks-backed positioning makes Dynamic the natural choice for fintechs that need both Solana and EVM coverage with enterprise compliance. Kora gives Dynamic a clean Solana fee-abstraction story that does not require Fireblocks to ship a competing paymaster.

Coinbase Developer Platform is the awkward one. Coinbase has invested heavily in making Base the default consumer chain through Coinbase Smart Wallet, free Base gas, and the embedded wallet SDK. Kora narrows the differentiation Base has been selling, especially for apps that want USDC-native flows where Solana already has scale advantages.

The likely outcome is that Kora becomes the default Solana backend for every embedded wallet vendor that did not want to operate a paymaster service themselves. The vendors compete on auth UX, key management, and policy controls. Kora handles the fee relay underneath. That is healthier for the ecosystem than the prior state where every consumer Solana dApp made an independent vendor decision and had to evaluate the security of each candidate's homegrown relayer.

What This Does and Does Not Solve​

Kora closes one gap definitively and leaves several others open. Worth being precise about which is which.

What Kora solves:

• The "user must hold SOL" UX cliff for any dApp willing to subsidize fees in another token.
• The "build vs buy a paymaster" decision for teams that previously had to choose between operational burden and vendor lock-in.
• The institutional acceptability gap, since the audit and KMS support let regulated entities run Kora nodes without rolling their own.

What Kora does not solve:

• Wallet acquisition itself — users still need an embedded wallet from somewhere, whether Phantom, Privy, Turnkey, or Coinbase.
• Account abstraction primitives like batched calls and session keys, which are still being assembled separately on Solana through PDAs and other program-level patterns.
• The economic question of who pays for the SOL that Kora operators front. For a dApp with token revenue or a stablecoin float, this is fine; for a free product, gas sponsorship is just a customer acquisition cost.
• Cross-chain UX, which still requires the user to interact with a bridge or a chain abstraction layer like LayerZero, Wormhole, or Across.

The "gasless infrastructure as protocol primitive" thesis cuts both ways. Solana now has the cleanest native fee abstraction story of any major chain. It also means the differentiation moves up the stack to wallet UX, recovery flows, and account abstraction features where EVM has a multi-year head start.

The Strategic Read for Builders​

For a team picking a chain in mid-2026, the calculus has shifted. Twelve months ago, the consumer-onboarding answer was Base, Abstract, or one of the new EVM consumer chains, full stop. Solana had developer mindshare and infrastructure momentum but lost retail users to the SOL acquisition step. That is no longer true.

A consumer dApp launching today on Solana with Privy or Turnkey on the front end and Kora on the back end has functionally the same UX surface as the equivalent stack on Base. Email login, gasless transactions, fee payment in USDC, sub-second finality. The remaining differences are the runtime model, the tooling ecosystem, and the available liquidity. For an app that wants Solana's throughput and DEX depth, the UX argument for picking EVM has gotten substantially weaker.

For teams already shipping on Base, Kora does not change the immediate decision. It does change the long-term competitive pressure. If the consumer dApps with the cleanest UX start showing up on Solana because the new infrastructure is one less integration to worry about, the gravity around Base's consumer-onboarding moat starts to shift.

The honest read is that Kora is necessary but not sufficient. It removes a specific reason developers were not picking Solana for consumer apps. It does not by itself create a new reason to pick Solana. The next two quarters will show whether the embedded-wallet vendors actually default to Kora, whether new consumer dApps cite it as a reason for their chain choice, and whether the existing EVM consumer chains respond by improving their own infrastructure stories.

Either way, "user must acquire SOL before transacting" is finally a legacy problem, not a current one. That alone is worth shipping.

BlockEden.xyz operates production-grade Solana RPC infrastructure for teams building consumer dApps, payment rails, and trading systems. If you're integrating gasless flows or scaling a Solana product, explore our API marketplace for low-latency endpoints designed for the next generation of consumer crypto.

Sources​

• GitHub: solana-foundation/kora
• Kora — Never lose a user to 'insufficient SOL' again
• How to Enable Gasless Transactions on Solana with Kora — QuickNode
• Solana Foundation Introduces Kora — Metaverse Post
• Kora Fee Relayer Enables Solana App Onboarding And Fees — Cryptonomist
• Fee Sponsorship — Solana Cookbook
• What is ERC-4337 on Solana? — Solana Developers
• Account Abstraction: Ethereum vs Solana Explained — Squads
• How Circle's Gas Station Uses Fee Payers on Solana
• Sponsoring transactions on Solana — Privy Docs
• Best Solana Wallets for Developers in 2026 — Openfort
• Coinbase Smart Wallet — State of Wallets Part 2
• Anza outlines key developments for Solana in 2026 — Phemex

What if your social graph, the invisible map of every person you follow, every post you've liked, every creator you've tipped, wasn't locked inside a corporate database? What if migrating 650,000 profiles, 28 million social connections, and 12 million posts to a brand-new blockchain could happen in a single weekend, without any of those users lifting a finger?

That is exactly what Lens pulled off when it shipped Lens Chain and Lens V3. And in doing so, the project placed one of the biggest bets in Web3 to date: that SocialFi, decentralized social media with built-in monetization, needs its own purpose-built Layer 2, not a general-purpose chain shared with DeFi bots and NFT flippers. The stack of choice? ZKsync's ZK Stack for execution, Avail for data availability, and Aave's GHO stablecoin as the gas token.

It's an opinionated bet. It might also be the right one.

Imagine telling a DeFi bot to "swap all my WETH for USDC, supply it into Aave, but only if my final balance stays above $5,000." Today, that instruction requires a developer to hard-code every parameter before signing — the exact WETH balance, the expected USDC output, the Aave deposit amount — creating a brittle transaction that fails the moment market conditions shift between the block it was signed and the block it lands on-chain. ERC-8211, published on April 6, 2026, by Biconomy and the Ethereum Foundation, eliminates this brittleness entirely. It is the first Ethereum standard that lets AI agents read live chain state, validate conditions, and execute multi-step strategies in a single atomic transaction — turning static batch calls into intelligent, self-adjusting workflows.

The timing is not coincidental. Over 17,000 AI agents are now live on Virtuals Protocol alone. Coinbase's AgentKit powers autonomous wallets across multiple LLM providers. NEAR's co-founder has declared that "the users of blockchain will be AI agents." But until now, these agents have been forced to interact with DeFi through the same rigid transaction formats designed for humans clicking buttons on a frontend. ERC-8211 gives them something fundamentally different: the ability to compose decisions on-chain, at execution time, with built-in safety rails.

The Problem: Static Batching Was Never Built for Autonomous Agents​

Multi-call contracts like Multicall3 and ERC-4337 bundlers already let wallets batch multiple transactions into one. But every parameter must be locked at signing time. If an AI agent signs a batch to swap 2.5 WETH for USDC and supply the proceeds into Aave, the 2.5 WETH figure is frozen — even if the agent's actual balance changed between signing and execution due to a pending transfer arriving or a fee deduction.

This creates three cascading problems for autonomous agents:

• Stale state: By the time a batched transaction is included in a block, the on-chain state it assumed may no longer hold. A price shift of 0.3% can cause a swap to revert, wasting gas and leaving the strategy half-executed.
• Over-specification: Agents must pre-compute every intermediate value (exact output amounts, slippage thresholds, deposit quantities) before signing. For a five-step leverage loop, this means predicting five sequential outputs — any one of which can invalidate the rest.
• No conditional logic: Static batches are all-or-nothing. There is no way to say "proceed with step three only if the result of step two exceeds a threshold." An agent cannot express safety constraints within the batch itself.

The result is that today's AI agents execute DeFi strategies with the flexibility of a printed boarding pass — every detail must be correct before departure, and any change requires starting over.

How ERC-8211 Works: Fetchers, Constraints, and Predicates​

ERC-8211 introduces what Biconomy calls "smart batching" — a contract-layer encoding standard where each parameter in a batch declares how to obtain its value and what conditions that value must satisfy. The standard is built on three primitives:

Fetchers​

Every input parameter carries a fetcher type that determines how its value is sourced at execution time, not at signing time. Three fetcher types are available:

• RAW_BYTES: The value is hard-coded, identical to traditional batching.
• STATIC_CALL: The value is read from a live on-chain contract call — checking a balance, querying an oracle price, or reading a pool's reserves.
• BALANCE: The value is the native token or ERC-20 balance of the executing account at the moment of execution.

A routing destination then determines where the resolved value goes: into the call's target address, its value field, or its calldata.

Constraints​

Every resolved value can carry inline constraints — logical checks validated on-chain before the call proceeds. Supported constraint types include EQ (equals), GTE (greater than or equal), LTE (less than or equal), and IN (membership in a set). If any constraint fails, the entire batch reverts atomically.

In practice, this means an agent can say: "Fetch my WETH balance (BALANCE fetcher), confirm it is GTE 1.0 WETH (constraint), then pass the resolved value into the swap calldata (routing)."

Predicates​

Entries with target = address(0) act as pure assertion checkpoints. They encode a boolean condition on chain state — for example, verifying that a wallet's USDC balance remains above a safety floor after a leverage loop — without executing any external call. If the predicate fails, the batch reverts.

Together, these three primitives transform a batch from a static script into a reactive program: "Swap my full WETH balance for USDC, then supply exactly what arrived into Aave, but only if my final balance exceeds my safety floor." All in one transaction, all resolved at execution time.

The Emerging Agent Protocol Stack​

ERC-8211 does not exist in isolation. It slots into an increasingly coherent protocol stack that the Ethereum Foundation has been assembling specifically for autonomous agents:

The analogy is not accidental: ERC-8004 identifies who is transacting, ERC-8183 governs what work is being exchanged, ERC-8211 handles how the work executes on-chain, and x402 manages how payments flow between agents. Together, they form what industry observers have started calling the "TCP/IP moment for on-chain AI" — a layered stack where each protocol handles one concern cleanly.

ERC-8183 is particularly complementary. Its Job primitive — where a client agent hires a provider agent, escrowed funds are held, and an evaluator attests to delivery — generates exactly the kind of multi-step, conditional on-chain actions that ERC-8211 is designed to execute. An AI agent accepting a job through ERC-8183 might need to perform a series of DeFi operations (swap, supply, borrow) as part of fulfilling the work. ERC-8211 ensures those operations execute correctly even if market conditions change between job acceptance and execution.

Competing Approaches: AgentKit, NEAR Chain Signatures, and the Fragmentation Risk​

ERC-8211's smart batching is not the only framework vying to become the standard execution layer for AI agents:

Coinbase AgentKit provides wallet infrastructure and on-chain action primitives for AI agents, with native support for OpenAI, Anthropic, and Llama models. In March 2026, World (Sam Altman's identity project) launched an AgentKit integration with x402 payments and World ID verification, enabling agents to carry cryptographic proof of human backing. AgentKit excels at wallet management and simple transactions but does not currently offer the conditional, state-aware execution that ERC-8211 provides.

NEAR Chain Signatures takes a different architectural approach: agents get their own NEAR accounts with private keys stored in Trusted Execution Environments (TEEs), and through Chain Signatures technology, they can sign transactions on any blockchain — Ethereum, Bitcoin, Solana — from a single NEAR-based identity. This solves the multi-chain problem elegantly but operates at the infrastructure layer rather than the execution semantics layer.

Visa's Trusted Agent Protocol and Google's AP2 (Agent Payment Protocol 2.0) address the payment and merchant-verification side, helping traditional commerce recognize and process AI agent transactions. They complement rather than compete with ERC-8211's on-chain execution focus.

The fragmentation risk is real. If AgentKit builds its own conditional execution primitives, or if NEAR develops a competing batch-execution standard, agents could face the same interoperability challenges that plagued early DeFi — multiple standards solving the same problem, none achieving critical mass. ERC-8211's advantage is its compatibility with existing account abstraction infrastructure (ERC-4337, ERC-7683) and its minimal footprint: it requires no protocol fork, no new opcode, and works with any smart account implementation.

Why This Matters: The 400,000-Agent Economy Needs On-Chain Composability​

The numbers paint a clear picture of urgency. Over 400,000 AI agents are now operating across blockchain networks, according to Chainalysis estimates. Virtuals Protocol alone has crossed $39.5 million in cumulative revenue from its 17,000+ agents. Coinbase's AgentKit supports autonomous wallets across every major LLM. The agent economy is not speculative — it is generating real revenue and executing real transactions today.

But these agents are constrained by infrastructure designed for human users. A human signing a swap on Uniswap can check the price, adjust slippage, and confirm — all within seconds. An autonomous agent operating at scale cannot afford this manual feedback loop. It needs to express complex strategies as self-contained, self-validating transaction bundles that execute correctly regardless of what happens between signing and inclusion.

ERC-8211's impact extends beyond DeFi automation. Consider these scenarios:

• Autonomous treasury management: A DAO treasury agent that rebalances across yield protocols, with predicate checks ensuring no single protocol holds more than 30% of funds — all in one atomic transaction.
• MEV-resistant execution: By resolving values at execution time rather than signing time, smart batches reduce the information available to MEV searchers who exploit stale parameters in pending transactions.
• Cross-protocol arbitrage: An agent that detects a price discrepancy between Uniswap and Curve can execute the arbitrage atomically with constraints ensuring minimum profit thresholds, eliminating the risk of executing one leg and failing on the other.

The Road Ahead: From Standard to Infrastructure​

ERC-8211 is still an ERC proposal, not a finalized standard. Its reference implementation is open-source and live in demo form, but adoption depends on wallet providers, bundler operators, and DeFi protocols integrating the smart batching interface. The standard's account-agnostic design — it works with ERC-4337 smart accounts, ERC-7683 cross-chain intents, and traditional EOAs through executor contracts — removes the biggest adoption barrier, but integration still requires active development.

The four-standard agent stack (ERC-8004 + ERC-8183 + ERC-8211 + x402) represents a coherent vision, but coherent visions in crypto have historically fragmented under competitive pressure. Whether the stack consolidates into a de facto standard or splinters into competing implementations will depend on which protocols ship production integrations first.

What is not in doubt is the direction. The blockchain's primary users are shifting from humans clicking through frontends to autonomous agents executing programmatic strategies. ERC-8211 is the first serious attempt to give those agents a transaction format that matches their capabilities — one that thinks before it transacts.

Building AI agents that interact with DeFi protocols across multiple chains? BlockEden.xyz provides high-performance RPC endpoints and data APIs for Ethereum, Sui, Aptos, and 20+ networks — the infrastructure layer your agents need for reliable on-chain reads and execution. Explore our API marketplace to get started.

For fifteen years, crypto's onboarding experience has been inexcusably broken. New users download a wallet, get bombarded with twelve random words they don't understand, discover they need ETH to do anything (but can't buy ETH without first having ETH for gas), and rage-quit before completing a single transaction. The industry called this "decentralization." Users called it hostile design.

Account abstraction—specifically ERC-4337 paired with Ethereum's May 2025 EIP-7702 upgrade—is finally fixing what should never have been broken. Over 40 million smart accounts have been deployed across Ethereum and Layer 2 networks, with nearly 20 million created in 2024 alone. The standard has enabled over 100 million UserOperations, marking a 10x increase from 2023. And with 87% of those transactions gas-sponsored by paymasters, we're witnessing the death of the "you need ETH to use Ethereum" paradox.

This isn't incremental improvement—it's the inflection point where crypto stops punishing users for not being cryptographers.

The 40 Million Smart Accounts Milestone: What Changed​

Account abstraction isn't new—developers have discussed it since Ethereum's early days. What changed in 2024-2025 was deployment infrastructure, wallet support, and Layer 2 scaling that made smart accounts economically viable.

ERC-4337, finalized in March 2023, introduced a standardized way to implement smart contract wallets without changing Ethereum's core protocol. It works through UserOperations—pseudo-transactions bundled and submitted by specialized nodes called bundlers—that enable features impossible with traditional externally owned accounts (EOAs):

• Gasless transactions: Paymasters sponsor gas fees, removing the ETH bootstrapping problem
• Batch transactions: Bundle multiple operations into one, reducing costs and clicks
• Social recovery: Recover accounts through trusted contacts instead of seed phrases
• Session keys: Grant temporary permissions to apps without exposing master keys
• Programmable security: Custom validation logic, spending limits, fraud detection

The 40 million deployment milestone represents 7x year-over-year growth. Nearly half of those accounts were created in 2024, accelerating through 2025 as major wallets and Layer 2s adopted ERC-4337 infrastructure.

Base, Polygon, and Optimism lead adoption. Base's integration with Coinbase Wallet enabled gasless onboarding for millions of users. Polygon's strong gaming ecosystem leverages smart accounts for in-game economies without requiring players to manage private keys. Optimism's OP Stack standardization helped smaller L2s adopt account abstraction without custom implementations.

But the real catalyst was EIP-7702, which activated with Ethereum's Pectra upgrade on May 7, 2025.

EIP-7702: How to Upgrade 300 Million Existing Wallets​

ERC-4337 smart accounts are powerful, but they're new accounts. If you've used Ethereum since 2015, your assets sit in an EOA—a simple key-value pair where the private key controls everything. Migrating those assets to a smart account requires transactions, gas fees, and risk of errors. For most users, that friction was too high.

EIP-7702 solved this by letting existing EOAs temporarily execute smart contract code during transactions. It introduces a new transaction type (0x04) where an EOA can attach executable bytecode without permanently becoming a contract.

Here's how it works: An EOA owner signs a "delegation designator"—an address containing executable code their account temporarily adopts. During that transaction, the EOA gains smart contract capabilities: batch operations, gas sponsorship, custom validation logic. After the transaction completes, the EOA returns to its original state, but the infrastructure now recognizes it as account-abstraction-compatible.

This means 300+ million existing Ethereum addresses can gain smart account features without migrating assets or deploying new contracts. Wallets like MetaMask, Trust Wallet, and Ambire can upgrade user accounts transparently, enabling:

• Gasless onboarding: Apps sponsor gas for new users, removing the ETH paradox
• Transaction batching: Approve and swap tokens in one click instead of two transactions
• Delegation to alternative key schemes: Use Face ID, passkeys, or hardware wallets as primary authentication

Major wallets implemented EIP-7702 support within weeks of the Pectra upgrade. Ambire and Trust Wallet rolled out support immediately, making their users' EOAs account-abstraction-ready without manual migration. This wasn't just a feature upgrade—it was retrofitting the entire installed base of Ethereum users with modern UX.

The combination of ERC-4337 (new smart accounts) and EIP-7702 (upgraded existing accounts) creates a path to 200 million+ smart accounts by late 2025, as industry projections estimate. That's not hype—it's the natural result of removing onboarding friction that crypto imposed on itself for no good reason.

100 Million UserOperations: The Real Adoption Metric​

Smart account deployments are a vanity metric if nobody uses them. UserOperations—the transaction-like bundles that ERC-4337 smart accounts submit—tell the real story.

The ERC-4337 standard has enabled over 100 million UserOperations, up from 8.3 million in 2023. That's a 12x increase in just one year, driven primarily by gaming, DeFi, and gasless onboarding flows.

87% of those UserOperations were gas-sponsored by paymasters—smart contracts that pay transaction fees on behalf of users. This is the killer feature. Instead of forcing users to acquire ETH before interacting with your app, developers can sponsor gas and onboard users instantly. The cost? A few cents per transaction. The benefit? Eliminating the number-one friction point in crypto onboarding.

Paymasters work in three modes:

1. Full sponsorship: The app pays all gas fees. Used for onboarding, referrals, or promotional campaigns.
2. ERC-20 payment: Users pay gas in USDC, DAI, or app-native tokens instead of ETH. Common in gaming where players earn tokens but don't hold ETH.
3. Conditional sponsorship: Gas fees sponsored if certain conditions are met (e.g., first transaction, transaction value exceeds threshold, user referred by existing member).

The practical impact: a new user can go from signup to first transaction in under 60 seconds without touching a centralized exchange, without downloading multiple wallets, and without understanding gas fees. They sign up with email and password (or social auth), and the app sponsors their first transactions. By the time they need to understand wallets and keys, they're already using the app and experiencing value.

This is how Web2 apps work. This is how crypto should have always worked.

Gasless Transactions: The Death of the ETH Bootstrapping Problem​

The "you need ETH to use Ethereum" problem has been crypto's most embarrassing UX failure. Imagine telling users of a new app: "Before you can try this, you need to go to a separate service, verify your identity, buy the network's currency, then transfer it to this app. Also, if you run out of that currency, none of your other funds work."

Paymasters ended this absurdity. Developers can now onboard users who have zero ETH, sponsor their first transactions, and let them interact with DeFi, gaming, or social apps immediately. Once users gain familiarity, they can transition to self-custody and managing gas themselves, but the

initial experience doesn't punish newcomers for not understanding blockchain internals.

Circle's Paymaster is a prime example. It allows applications to sponsor gas fees for users paying in USDC. A user with USDC in their wallet can transact on Ethereum or Layer 2s without ever acquiring ETH. The paymaster converts USDC to cover gas in the background, invisible to the user. For stablecoin-first apps (remittances, payments, savings), this removes the mental overhead of managing a volatile gas token.

Base's paymaster infrastructure enabled Coinbase to onboard millions of users to DeFi without crypto complexity. Coinbase Wallet defaults to Base, sponsors initial transactions, and lets users interact with apps like Uniswap or Aave before understanding what gas is. By the time users need to buy ETH, they're already experiencing value and have context for why the system works the way it does.

Gaming platforms like Immutable X and Treasure DAO use paymasters to subsidize player transactions. In-game actions—minting items, trading on marketplaces, claiming rewards—happen instantly without interrupting gameplay to approve gas transactions. Players earn tokens through gameplay, which they can later use for gas or trade, but the initial experience is frictionless.

The result: tens of millions of dollars in gas fees sponsored by applications in 2024-2025. That's not charity—it's customer acquisition cost. Apps have decided that paying $0.02-0.10 per transaction to onboard users is cheaper and more effective than forcing users to navigate centralized exchanges first.

Batch Transactions: One Click, Multiple Actions​

One of the most frustrating aspects of traditional Ethereum UX is the need to approve every action separately. Want to swap USDC for ETH on Uniswap? That's two transactions: one to approve Uniswap to spend your USDC, another to execute the swap. Each transaction requires a wallet popup, gas fee confirmation, and block confirmation time. For new users, this feels like the app is broken. For experienced users, it's just annoying.

ERC-4337 and EIP-7702 enable transaction batching, where multiple operations bundle into a single UserOperation. That same Uniswap swap becomes one click, one confirmation, one gas fee. The smart account internally executes approval and swap sequentially, but the user only sees a single transaction.

The use cases extend far beyond DeFi:

• NFT minting: Approve USDC, mint NFT, and list on marketplace in one transaction
• Gaming: Claim rewards, upgrade items, and stake tokens simultaneously
• DAO governance: Vote on multiple proposals in a single transaction instead of paying gas for each
• Social apps: Post content, tip creators, and follow accounts without per-action confirmations

This isn't just UX polish—it fundamentally changes how users interact with on-chain applications. Complex multi-step flows that previously felt clunky and expensive now feel instant and cohesive. The difference between "this app is complicated" and "this app just works" often comes down to batching.

Social Recovery: The End of Seed Phrase Anxiety​

Ask any non-crypto-native user what they fear most about self-custody, and the answer is invariably: "What if I lose my seed phrase?" Seed phrases are secure in theory but catastrophic in practice. Users write them on paper (easily lost or damaged), store them in password managers (single point of failure), or don't back them up at all (guaranteed loss on device failure).

Social recovery flips the model. Instead of a 12-word mnemonic as the sole recovery method, smart accounts let users designate trusted "guardians"—friends, family, or even hardware devices—who can collectively restore access if the primary key is lost.

Here's how it works: A user sets up their smart account and designates three guardians (could be any number and threshold, e.g., 2-of-3, 3-of-5). Each guardian holds a recovery shard—a partial key that, on its own, can't access the account. If the user loses their primary key, they contact guardians and request recovery. Once the threshold is met (e.g., 2 out of 3 guardians approve), the smart account's access is transferred to a new key controlled by the user.

Argent pioneered this model in 2019. By 2025, Argent has enabled social recovery for hundreds of thousands of users, with recovery success rates exceeding 95% for users who lose devices. The mental shift is significant: instead of "I need to protect this seed phrase forever or lose everything," it becomes "I need to maintain relationships with people I trust, which I'm already doing."

Ambire Wallet took a hybrid approach, combining email/password authentication with optional social recovery for high-value accounts. Users who prefer simplicity can rely on email-based recovery (with encrypted key shards stored across servers). Power users can layer social recovery on top for additional security.

The criticism: social recovery isn't purely trustless—it requires trusting guardians not to collude. Fair enough. But for most users, trusting three friends is far more practical than trusting themselves to never lose a piece of paper. Crypto's maximalist stance on "pure self-custody" has made the ecosystem unusable for 99% of humanity. Social recovery is a pragmatic compromise that enables onboarding without sacrificing security in realistic threat models.

Session Keys: Delegated Permissions Without Exposure​

Traditional EOAs are all-or-nothing: if an app has your private key, it can drain your entire wallet. This creates a dilemma for interactive applications (games, social apps, automated trading bots) that need frequent transaction signing without constant user intervention.

Session keys solve this by granting temporary, limited permissions to apps. A smart account owner can create a session key that's valid for a specific duration (e.g., 24 hours) and only for specific actions (e.g., trading on Uniswap, minting NFTs, posting to a social app). The app holds the session key, can execute transactions within those constraints, but can't access the account's full funds or perform unauthorized actions.

Use cases exploding in 2025-2026:

• Gaming: Players grant session keys to game clients, enabling instant in-game transactions (claiming loot, trading items, upgrading characters) without wallet popups every 30 seconds. The session key is scoped to game-related contracts and expires after the session ends.

• Trading bots: DeFi users create session keys for automated trading strategies. The bot can execute trades, rebalance portfolios, and claim yields, but can't withdraw funds or interact with contracts outside the whitelist.

• Social apps: Decentralized Twitter/Reddit alternatives use session keys to let users post, comment, and tip without approving each action. The session key is limited to social contract interactions and has a spending cap for tips.

The security model is time-boxed, scope-limited permissions—exactly how OAuth works for Web2 apps. Instead of giving an app full account access, you grant specific permissions for a limited time. If the app is compromised or behaves maliciously, the worst-case damage is contained to the session key's scope and duration.

This is the UX expectation users bring from Web2. The fact that crypto didn't have this for 15 years is inexcusable, and account abstraction is finally fixing it.

Base, Polygon, Optimism: Where 40M Smart Accounts Actually Live​

The 40 million smart account deployments aren't evenly distributed—they concentrate on Layer 2s where gas fees are low enough to make account abstraction economically viable.

Base leads adoption, leveraging Coinbase's distribution to onboard retail users at scale. Coinbase Wallet defaults to Base for new users, with smart accounts created transparently. Most users don't even realize they're using a smart account—they sign up with email, start transacting, and experience gasless onboarding without understanding the underlying tech. That's the goal. Crypto shouldn't require users to understand Merkle trees and elliptic curves before they can try an app.

Base's gaming ecosystem benefits heavily from account abstraction. Games built on Base use session keys to enable frictionless gameplay, batch transactions to reduce in-game action latency, and paymasters to subsidize player onboarding. The result: players with zero crypto experience can start playing Web3 games without noticing they're on a blockchain.

Polygon had early momentum with gaming and NFT platforms adopting ERC-4337. Polygon's low fees (often <$0.01 per transaction) make paymaster-sponsored gas economically sustainable. Projects like Aavegotchi, Decentraland, and The Sandbox use smart accounts to remove friction for users who want to interact with virtual worlds, not manage wallets.

Polygon also partnered with major brands (Starbucks Odyssey, Reddit Collectible Avatars, Nike .SWOOSH) to onboard millions of non-crypto users. These users don't see wallets, seed phrases, or gas fees—they see gamified loyalty programs and digital collectibles. Under the hood, they're using account-abstraction-enabled smart accounts.

Optimism's OP Stack standardization made account abstraction portable across rollups. Any OP Stack chain can inherit Optimism's ERC-4337 infrastructure without custom implementation. This created a network effect: developers build account-abstraction-enabled apps once, deploy across Base, Optimism, and other OP Stack chains with minimal modifications.

Optimism's focus on public goods funding also incentivized wallet developers to adopt account abstraction. Retroactive Public Goods Funding (RPGF) rounds explicitly rewarded projects improving Ethereum UX, with account abstraction wallets receiving significant allocations.

The pattern: low fees + distribution channels + developer tooling = adoption. Smart accounts didn't take off on Ethereum mainnet because $5-50 gas fees make paymaster sponsorship prohibitively expensive. They took off on L2s where per-transaction costs dropped to cents, making gasless onboarding economically viable.

The 200 Million Smart Account Endgame​

Industry projections estimate over 200 million smart accounts by late 2025, driven by ERC-4337 adoption and EIP-7702 retrofitting existing EOAs. That's not moonshot speculation—it's the natural result of removing artificial friction.

The path to 200 million:

1. Mobile wallet adoption. Ambire Mobile, Trust Wallet, and MetaMask Mobile now support account abstraction, bringing smart account features to billions of smartphone users. Mobile is where the next wave of crypto adoption happens, and mobile UX can't tolerate seed phrase management or per-transaction gas confirmations.

2. Gaming onboarding. Web3 games are the highest-volume use case for account abstraction. Free-to-play games with play-to-earn mechanics can onboard millions of players, sponsor initial transactions, and enable frictionless gameplay. If 10-20 major games adopt account abstraction in 2025-2026, that's 50-100 million users.

3. Enterprise applications. Companies like Circle, Stripe, and PayPal are integrating blockchain payments but won't subject customers to seed phrase management. Account abstraction enables enterprise apps to offer blockchain-based services with Web2-grade UX.

4. Social apps. Decentralized social platforms (Farcaster, Lens, Friend.tech) need frictionless onboarding to compete with Twitter and Instagram. Nobody will use decentralized Twitter if every post requires a wallet approval. Session keys and paymasters make decentralized social apps viable.

5. EIP-7702 retrofit. 300+ million existing Ethereum EOAs can gain smart account features without migration. If just 20-30% of those accounts adopt EIP-7702 features, that's 60-90 million accounts upgraded.

The inflection point: when smart accounts become the default, not the exception. Once major wallets (MetaMask, Trust Wallet, Coinbase Wallet) create smart accounts by default for new users, the installed base shifts rapidly. EOAs become legacy infrastructure, maintained for compatibility but no longer the primary user experience.

Why BlockEden.xyz Builders Should Care​

If you're building on Ethereum or Layer 2, account abstraction isn't optional infrastructure—it's table stakes for competitive UX. Users expect gasless onboarding, batch transactions, and social recovery because that's how Web2 apps work and how modern crypto apps should work.

For developers, implementing account abstraction means:

Choosing the right infrastructure: Use ERC-4337 bundlers and paymaster services (Alchemy, Pimlico, Stackup, Biconomy) rather than building from scratch. The protocol is standardized, tooling is mature, and reinventing the wheel wastes time.

Designing onboarding flows that hide complexity: Don't show users seed phrases on signup. Don't ask for gas fee approvals before they've experienced value. Sponsor initial transactions, use session keys for repeat interactions, and introduce advanced features gradually.

Supporting social recovery: Offer email-based recovery for casual users, social recovery for those who want it, and seed phrase backup for power users who demand full control. Different users have different threat models—your wallet should accommodate all of them.

Account abstraction is the infrastructure that makes your app accessible to the next billion users. If your onboarding flow still requires users to buy ETH before trying your product, you're competing with one hand tied behind your back.

For developers building applications with account abstraction, BlockEden.xyz provides the RPC infrastructure to support smart accounts at scale. Whether you're implementing ERC-4337 UserOperations, integrating paymaster services, or deploying on Base, Polygon, or Optimism, our APIs handle the throughput and reliability demands of production account abstraction. Explore our API marketplace to build the next generation of crypto UX.

Sources​

• ERC-4337 Documentation
• What is ERC-4337? | Alchemy
• EIP-7702 Implementation Guide | QuickNode
• Ethereum Pectra Upgrade Overview | Alchemy
• Pectra Upgrade & EIP-7702 Give EOAs Smart Wallet Superpowers | Circle
• What are Paymasters? (ERC-4337) | Alchemy
• Gasless transactions with paymaster | Base Documentation
• What is Account Abstraction? | Ambire Blog
• Why Account Abstraction Will Fix Crypto's Biggest Problem | Medium

AllScale.io is a legitimate, venture-backed stablecoin payment platform—not a token project—targeting freelancers and small businesses in emerging markets. Founded in February 2025 and backed by $6.5M from reputable crypto VCs including YZi Labs, Draper Dragon, and KuCoin Ventures, the company shows positive signals: a publicly doxxed team with verifiable experience at Kraken, Capital One, and Block, plus institutional backing from Hong Kong's Cyberport incubator. However, the absence of public security audits and the platform's extreme youth (under one year old) warrant careful due diligence before significant engagement.

What AllScale does and the problem it solves​

AllScale positions itself as the "world's first self-custody stablecoin neobank," specifically designed for the 600+ million global microbusinesses—freelancers, content creators, SMBs, and remote contractors—who struggle with traditional cross-border payments. The core problem: international freelancers face bank account barriers, high wire fees, currency conversion losses, and settlement delays often exceeding 5 business days.

The platform enables businesses to create invoices, receive payments in USDT or USDC regardless of how clients pay (credit card, wire, or crypto), and access funds instantly through a non-custodial wallet. Key products include AllScale Invoice (live since September 2025), AllScale Pay (social commerce via Telegram, WhatsApp, Line), and AllScale Payroll (cross-border contractor payments). The company emphasizes "invisible crypto"—clients may not know they're using blockchain rails while merchants receive stablecoins.

Current development stage: The platform is in public beta with a working product live on BNB Chain mainnet. Users can access the dashboard at dashboard.allscale.io, though a waitlist may apply.

Technical architecture relies on BNB Chain and account abstraction​

AllScale builds on existing blockchain infrastructure rather than operating its own chain. The primary technology stack includes:

The passkey-based approach eliminates the notorious UX friction of seed phrase management, lowering the barrier for mainstream adoption. The multi-chain paymaster sponsorship architecture handles transaction costs behind the scenes.

What's missing: AllScale maintains no public GitHub repositories—the infrastructure is proprietary and closed-source. No smart contract addresses have been published, no public APIs or SDKs are available, and technical documentation at docs.allscale.io focuses on user guides rather than architecture specifications. This opacity prevents independent technical verification of their claims.

No native token—the platform uses USDT and USDC​

AllScale does not have a native cryptocurrency token. This is a critical distinction from many Web3 projects: there is no ICO, IDO, token sale, or speculative asset involved. The company operates as a traditional Delaware C-corp raising equity funding.

The platform uses third-party stablecoins—primarily USDT and USDC—as the payment medium. Users receive payments in stablecoins, with automatic conversion from fiat or card payments. Integration with BNB Chain also provides access to USD1 (the Binance-affiliated stablecoin).

Revenue model (estimated, not publicly disclosed):

• Transaction fees on invoice/payment processing
• Currency conversion spreads on fiat-to-stablecoin exchanges
• B2B payroll management services
• On/off-ramp integration fees

The absence of a token eliminates certain risks (speculative volatility, tokenomics manipulation, regulatory securities concerns) but also means there's no token-based exposure for investors beyond equity participation.

Four publicly doxxed founders with verifiable backgrounds​

AllScale's team demonstrates strong transparency—all founders are publicly identified with verifiable professional histories:

Shawn Pang (CEO & Co-Founder): Computer Science and Business from Western University. Former Product Manager for payment fraud at Capital One; first PM in Canada at TikTok; co-founded HashMatrix, a growth marketing agency for AI products.

Ruoyang "Leo" Wang (COO & Co-Founder): Computer Engineering from University of Toronto. Background at PingCAP (distributed databases), IBM, AMD, and Scotiabank. Previous startup experience with CP Clickme.

Jun Li & Khalil Lin (Co-Founders): Additional co-founders with legal/compliance expertise, reportedly including OKX background. LinkedIn profiles available.

Avrilyn Li (Founding Product Manager): AI-to-Web3 entrepreneur from Ivey Business School, leading the payroll product.

The team claims collective experience from Binance, OKX, Kraken, Block (Square), Amazon, Dell, and HP. Total team size is approximately 7-11 employees.

Funding and investors​

Notable participating investors include KuCoin Ventures, Oak Grove Ventures, BlockBooster, Aptos, GSR Ventures, and V3V Ventures. Angel investors include Gracy Chen and Jedi Lu. The company is a member of the Hong Kong Cyberport Incubation Program, a government-backed tech accelerator.

Major security concern: no public audits or bug bounty program​

This is the most significant red flag in the research. Despite handling user funds through smart contract wallets:

• No public smart contract audits from recognized firms (CertiK, Hacken, Trail of Bits, OpenZeppelin, SlowMist)
• Not listed on CertiK Skynet or similar security databases
• No bug bounty program on Immunefi, HackerOne, or Bugcrowd
• No insurance or coverage mechanisms disclosed
• No security disclosure policy publicly visible

AllScale claims security features including self-custody architecture, automated KYC/KYB/KYT compliance, hardware security module (HSM) integration for passkeys, and 2FA support. The self-custody model does reduce platform counterparty risk—if AllScale were compromised, users' funds in their own wallets would theoretically be safer than in a custodial service.

On the positive side: No security incidents, hacks, or exploits have been reported for AllScale. However, given the platform's youth, this absence of incidents may simply reflect limited exposure rather than robust security.

Competitive landscape and market positioning​

AllScale competes in the rapidly evolving stablecoin payments space:

AllScale's differentiation factors:

• Self-custody model (users control funds)
• Passkey authentication eliminating seed phrase UX
• Zero gas fees via account abstraction
• Emerging market focus (Africa, Latin America, Southeast Asia)
• "Last-mile" SMB targeting vs. enterprise focus

Disadvantages: Extreme youth, small team, limited track record, competing against well-funded incumbents with established distribution channels.

Community presence is early-stage and B2B-focused​

AllScale maintains standard Web3 social channels:

• X (Twitter): @allscaleio (active since April 2025)
• Telegram: AllScaleHQ community group
• Discord: Active server with community ID visible
• LinkedIn: AllScale Inc company page
• Newsletter: "The Stablecoin Scoop" on Substack

The community is early-stage, with engagement primarily through AMA sessions, X Spaces, and partnership announcements. AllScale hosted the Scale Stablecoin Summit in Hong Kong (June 2025) with HashKey Group and Amber Group.

No traditional DeFi metrics apply: AllScale is a payments platform, not a DeFi protocol, so TVL (Total Value Locked) metrics are not applicable. The platform is not listed on DeFiLlama or Dune Analytics. User count and retention metrics are mentioned by investors but not publicly disclosed.

Notable partnerships include BNB Chain (official ecosystem partner), Skill Afrika (African freelancer communities), Ethscriptions (L1 permanence), and Asseto (RWA tokenization for yield products).

Risk assessment reveals moderate-risk early-stage venture​

Positive legitimacy signals​

• Publicly doxxed team with verifiable professional backgrounds
• Reputable crypto VCs (YZi Labs, Draper Dragon, Amber Group, KuCoin Ventures)
• Hong Kong Cyberport institutional backing
• Delaware C-corp legal structure
• Working product live on BNB Chain mainnet
• No scam allegations, BBB complaints, or community warnings found
• No anonymous team concerns
• No unrealistic yield promises or token speculation
• Compliance-forward positioning (GENIUS Act, Hong Kong Stablecoin Ordinance)

Areas requiring caution​

• Extreme youth: Founded February 2025, under one year old
• No public security audits despite handling funds
• No bug bounty program
• No independent user reviews or community feedback available
• Closed-source infrastructure—cannot independently verify claims
• Press coverage primarily press release syndication, not independent journalism
• Centralization risks: Company-operated platform, BNB Chain dependency
• Small team (~7-11 people) executing ambitious global scope

Not found (potential yellow flags by absence)​

• No user metrics publicly disclosed
• No revenue figures
• No formal advisory board
• No specific regulatory licenses (Hong Kong framework not yet effective)

Recent developments and roadmap​

Recent milestones (2025):

• December 8: $5M seed round announced (YZi Labs led)
• November: AllScale Pay live on BNB Chain; Skill Afrika partnership
• October: Ethscriptions partnership for L1 permanence
• September: AllScale Invoice product launch
• August: BNB Chain integration with USD1 support
• June: Scale Stablecoin Summit Hong Kong; $1.5M pre-seed funding

Upcoming:

• Q1 2026: Latin America market expansion
• Future: DeFi yield options, expanded cross-chain capabilities, B2B enterprise solutions

Conclusion​

AllScale.io emerges as a legitimate early-stage startup rather than a scam concern, backed by credible investors and a transparent, verifiable team. The project addresses a real market problem—cross-border payment friction for emerging market freelancers—with a thoughtful technical approach leveraging account abstraction and stablecoins.

However, two significant gaps demand attention before meaningful engagement: the complete absence of public security audits and the closed-source infrastructure that prevents independent verification. For a platform handling user funds, these omissions are material concerns regardless of the team's credentials.

Overall risk rating: Moderate. The venture shows strong legitimacy signals but carries inherent early-stage risks. Potential users should start with small amounts until security audits are published. Potential partners should request direct access to technical specifications and audit reports. The project is worth monitoring as it matures, particularly for any security audit announcements in Q1 2026.

Imagine a world where users can interact with your dApp seamlessly, without needing to hold any native tokens (SUI). This is no longer a distant dream. With Sui's Gas Station (also known as a Paymaster), developers can cover gas fees on behalf of their users, completely removing one of the biggest barriers for new entrants to Web3 and enabling a truly frictionless on-chain experience.

This article provides a complete guide to upgrading your dApp to be gas-less. We'll dive deep into the core concepts of the Sui Paymaster, its architecture, implementation patterns, and best practices.

1. Background and Core Concepts: What is a Sponsored Transaction?​

In the world of blockchain, every transaction requires a network fee, or "gas." For users accustomed to the seamless experiences of Web2, this is a significant cognitive and operational hurdle. Sui addresses this challenge at the protocol level with Sponsored Transactions.

The core idea is simple: allow one party (the Sponsor) to pay the SUI gas fees for another party's (the User) transaction. This way, even if a user has zero SUI in their wallet, they can still successfully initiate on-chain actions.

Paymaster ≈ Gas Station​

In the Sui ecosystem, the logic for sponsoring transactions is typically handled by an off-chain or on-chain service called a Gas Station or Paymaster. Its primary responsibilities include:

1. Evaluating the Transaction: It receives a user's gas-less transaction data (GasLessTransactionData).
2. Providing Gas: It locks and allocates the necessary gas fee for the transaction. This is usually managed through a gas pool composed of many SUI Coin objects.
3. Generating a Sponsor Signature: After approving the sponsorship, the Gas Station signs the transaction with its private key (SponsorSig), certifying its willingness to pay the fee.
4. Returning the Signed Transaction: It sends back the TransactionData, which now includes the gas data and the sponsor's signature, to await the user's final signature.

In short, a Gas Station acts as a refueling service for your dApp's users, ensuring their "vehicles" (transactions) can travel smoothly on the Sui network.

2. High-Level Architecture and Interaction Flow​

A typical gas-less transaction involves coordination between the user, the dApp frontend, the Gas Station, and a Sui Full Node. The interaction sequence is as follows:

Flow Breakdown:

1. The User performs an action in the dApp UI, which constructs a transaction data package without any gas information.
2. The dApp sends this data to its designated Gas Station to request sponsorship.
3. The Gas Station verifies the request's validity (e.g., checks if the user is eligible for sponsorship), then populates the transaction with a Gas Coin and its signature, returning the semi-complete transaction to the dApp.
4. The User sees the full transaction details in their wallet (e.g., "Purchase one NFT") and provides the final signature. This is a crucial step that ensures the user maintains consent and control over their actions.
5. The dApp broadcasts the complete transaction, containing both the user's and the sponsor's signatures, to a Sui Full Node.
6. After the transaction is finalized on-chain, the Gas Station can confirm this by listening for on-chain events or receipts, then notify the dApp backend via a webhook to close the loop on the business process.

3. Three Core Interaction Models​

You can use the following three interaction models individually or in combination to suit your business needs.

Model 1: User-Initiated → Sponsor-Approved (Most Common)​

This is the standard model, suitable for the vast majority of in-dApp interactions.

1. User constructs GasLessTransactionData: The user performs an action within the dApp.
2. Sponsor adds GasData and signs: The dApp backend sends the transaction to the Gas Station, which approves it, attaches a Gas Coin, and adds its signature.
3. User reviews and gives final signature: The user confirms the final transaction details in their wallet and signs it. The dApp then submits it to the network.

This model strikes an excellent balance between security and user experience.

Model 2: Sponsor-Initiated Airdrops/Incentives​

This model is perfect for airdrops, user incentives, or batch asset distributions.

1. Sponsor pre-fills TransactionData + signs: The Sponsor (typically the project team) pre-constructs most of the transaction (e.g., airdropping an NFT to a specific address) and attaches its sponsorship signature.
2. User's second signature makes it effective: The user only needs to sign this "pre-approved" transaction once for it to be executed.

This creates an extremely smooth user experience. With just one click to confirm, users can claim rewards or complete tasks, dramatically increasing the conversion rates of marketing campaigns.

Model 3: Wildcard GasData (Credit Line Model)​

This is a more flexible and permission-based model.

1. Sponsor transfers a GasData object: The Sponsor first creates one or more Gas Coin objects with a specific budget and transfers ownership directly to the user.
2. User spends freely within the budget: The user can then freely use these Gas Coins to pay for any transactions they initiate within the budget's limits and validity period.
3. Gas Coin is returned: Once depleted or expired, the Gas Coin object can be designed to be automatically destroyed or returned to the Sponsor.

This model is equivalent to giving the user a limited-time, limited-budget "gas fee credit card," suitable for scenarios requiring a high degree of user autonomy, such as offering a free-to-play experience during a game season.

4. Typical Application Scenarios​

The power of the Sui Paymaster lies not just in solving the gas fee problem, but also in its ability to deeply integrate with business logic to create new possibilities.

Scenario 1: Paywalls​

Many content platforms or dApp services require users to meet certain criteria (e.g., hold a VIP NFT, reach a certain membership level) to access features. The Paymaster can implement this logic perfectly.

• Flow: A user requests an action → the dApp backend verifies the user's qualifications (e.g., NFT ownership) → if eligible, it calls the Paymaster to sponsor the gas fee; if not, it simply denies the signing request.
• Advantage: This model is inherently resistant to bots and abuse. Since the sponsorship decision is made on the backend, malicious users cannot bypass the qualification check to drain gas funds.

Scenario 2: One-Click Checkout​

In e-commerce or in-game purchase scenarios, simplifying the payment process is critical.

• Flow: The user clicks "Buy Now" on a checkout page. The dApp constructs a transaction that includes the business logic (e.g., transfer_nft_to_user). The user only needs to sign to approve the business transaction in their wallet, without worrying about gas. The gas fee is covered by the dApp's Sponsor.
• Advantage: You can encode business parameters like an order_id directly into the ProgrammableTransactionBlock, enabling precise on-chain attribution for backend orders.

Scenario 3: Data Attribution​

Accurate data tracking is fundamental to business optimization.

• Flow: When constructing the transaction, write a unique identifier (like an order_hash) into the transaction's parameters or into an event that will be emitted upon execution.
• Advantage: When the Gas Station receives the on-chain receipt for a successful transaction, it can easily extract this order_hash by parsing the event or transaction data. This allows for a precise mapping between on-chain state changes and specific backend orders or user actions.

5. Code Skeleton (Based on the Rust SDK)​

Here is a simplified code snippet demonstrating the core interaction steps.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

For a complete implementation, refer to the official Sui documentation's Gas Station Tutorial which offer out-of-the-box code examples.

6. Risks and Protection​

While powerful, deploying a Gas Station in a production environment requires careful consideration of the following risks:

• Equivocation (Double-Spending): A malicious user might try to use the same Gas Coin for multiple transactions in parallel, which would cause the Gas Coin to be locked by the Sui network. This can be effectively mitigated by assigning a unique Gas Coin per user or transaction, maintaining a blacklist, and rate-limiting signing requests.
• Gas Pool Management: In high-concurrency scenarios, a single large-value Gas Coin can become a performance bottleneck. The Gas Station service must be capable of automatically splitting large SUI Coins into many smaller-value Gas Coins and efficiently reclaiming them after use. Professional Gas Station providers like Shinami offer mature, managed solutions for this.
• Authorization and Rate Limiting: You must establish strict authorization and rate-limiting policies. For instance, manage sponsorship limits and frequencies based on user IP, wallet address, or API tokens to prevent the service from being drained by malicious actors.

7. Ecosystem Tools​

The Sui ecosystem already offers a rich set of tools to simplify Paymaster development and deployment:

• Official SDKs (Rust/TypeScript): Include high-level APIs like sponsor_transaction_block(), significantly reducing integration complexity.
• Shinami Gas Station: Provides an all-in-one managed service, including automated Gas Coin splitting/reclaiming, detailed metrics monitoring, and webhook notifications, allowing developers to focus on business logic.
• Enoki / Mysten Demos: The community and Mysten Labs also provide open-source Paymaster implementations that can be used as a reference for building your own service.

8. Implementation Checklist​

Ready to upgrade your dApp to the gas-less era? Go through this checklist before you start:

• Plan Your Funding Flow: Define the Sponsor's funding source, budget, and replenishment strategy. Set up monitoring and alerts for key metrics (e.g., gas pool balance, consumption rate).
• Reserve Attribution Fields: When designing your transaction parameters, be sure to reserve fields for business identifiers like order_id or user_id.
• Deploy Anti-Abuse Policies: You must implement strict authorization, rate-limiting, and logging mechanisms before going live.
• Rehearse on Testnet: Whether building your own service or integrating a third-party Gas Station, always conduct thorough concurrency and stress testing on a testnet or devnet first.
• Continuously Optimize: After launch, continuously track transaction success rates, failure reasons, and gas costs. Fine-tune your budget and strategies based on the data.

Conclusion​

The Sui Paymaster (Gas Station) is more than just a tool for covering user gas fees. It's a powerful paradigm that elegantly combines a "zero SUI on-chain" user experience with the business need for "order-level on-chain attribution" within a single, atomic transaction. It paves the way for Web2 users to enter Web3 and provides developers with unprecedented flexibility for business customization.

With an increasingly mature ecosystem of tools and the current low gas costs on the Sui network, there has never been a better time to upgrade your dApp's payment and interaction flows to the gas-less era.

How to drop wallet friction, keep users flowing, and forecast the upside

What if your Web3 app had the same seamless sign-up flow as a modern Web2 service? That's the core promise of zkLogin on the Sui blockchain. It functions like OAuth for Sui, letting users sign in with familiar accounts from Google, Apple, X, and more. A zero-knowledge proof then securely links that Web2 identity to an on-chain Sui address—no wallet pop-ups, no seed phrases, no user churn.

The impact is real and immediate. With hundreds of thousands of zkLogin accounts already live, case studies report massive gains in user conversion, jumping from a dismal 17% to a healthy 42% after removing traditional wallet barriers. Let's break down how it works and what it can do for your project.

Why Wallets Kill First‑Time Conversion​

You've built a groundbreaking dApp, but your user acquisition funnel is leaking. The culprit is almost always the same: the "Connect Wallet" button. Standard Web3 onboarding is a maze of extension installations, seed phrase warnings, and crypto-jargon quizzes.

It’s a massive barrier for newcomers. UX researchers observed a staggering 87% drop-off the moment a wallet prompt appeared. In a telling experiment, simply re-routing that prompt to a later stage in the checkout process flipped the completion rate to 94%. Even for crypto-curious users, the primary fear is, “I might lose my funds if I click the wrong button.” Removing that single, intimidating step is the key to unlocking exponential growth.

How zkLogin Works (in Plain English)​

zkLogin elegantly sidesteps the wallet problem by using technologies every internet user already trusts. The magic happens behind the scenes in a few quick steps:

1. Ephemeral Key Pair: When a user wants to sign in, a temporary, single-session key pair is generated locally in their browser. Think of it as a temporary passkey, valid only for this session.
2. OAuth Dance: The user signs in with their Google, Apple, or other social account. Your app cleverly embeds a unique value (nonce) into this login request.
3. ZKP Service: After a successful login, a ZKP (Zero-Knowledge Proof) service generates a cryptographic proof. This proof confirms, "This OAuth token authorizes the owner of the temporary passkey," without ever revealing the user's personal identity on-chain.
4. Derive Address: The user's JWT (JSON Web Token) from the OAuth provider is combined with a unique salt to deterministically generate their permanent Sui address. The salt is kept private, either client-side or in a secure backend.
5. Submit Transaction: Your app signs transactions with the temporary key and attaches the ZK proof. Sui validators verify the proof on-chain, confirming the transaction's legitimacy without the user ever needing a traditional wallet.

Step‑by‑Step Integration Guide​

Ready to implement this? Here’s a quick guide using the TypeScript SDK. The principles are identical for Rust or Python.

1. Install SDK​

The @mysten/sui package includes all the zklogin helpers you'll need.

pnpm add @mysten/sui

2. Generate Keys & Nonce​

First, create an ephemeral keypair and a nonce tied to the current epoch on the Sui network.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. Redirect to OAuth​

Construct the appropriate OAuth login URL for the provider you're using (e.g., Google, Facebook, Apple) and redirect the user.

4. Decode JWT & Fetch User Salt​

After the user logs in and is redirected back, grab the id_token from the URL. Use it to fetch the user-specific salt from your backend, then derive their Sui address.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. Request ZK Proof​

Send the JWT to a prover service to get the ZK proof. For development, you can use Mysten’s public prover. In production, you should host your own or use a service like Enoki.

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Sign & Send​

Now, build your transaction, set the sender to the user's zkLogin address, and execute it. The SDK handles attaching the zkLoginInputs (the proof) automatically. ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // Any Move call
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // The magic happens here
});

7. Persist Session​

For a smoother user experience, encrypt and store the keypair and salt in IndexedDB or local storage. Remember to rotate them every few epochs for enhanced security.

KPI Projection Template​

The difference zkLogin makes isn't just qualitative; it's quantifiable. Compare a typical onboarding funnel with a zkLogin-powered one:

👉 What this means: For a campaign driving 10,000 unique visitors, that's the difference between 300 first-day on-chain actions and over 2,500.

Best Practices & Gotchas​

To create an even more seamless experience, keep these pro-tips in mind:

• Use Sponsored Transactions: Pay for your users' first few transaction fees. This removes all friction and delivers an incredible "aha" moment.
• Handle Salts Carefully: Changing a user's salt will generate a new address. Only do this if you control a reliable recovery path for them.
• Expose the Sui Address: After signup, show users their on-chain address. This empowers advanced users to import it into a traditional wallet later if they choose.
• Prevent Refresh Loops: Cache the JWT and ephemeral keypair until they expire to avoid asking the user to log in repeatedly.
• Monitor Prover Latency: Keep an eye on the proof-generation round-trip time. If it exceeds 2 seconds, consider hosting a regional prover to keep things snappy.

Where BlockEden.xyz Adds Value​

While zkLogin perfects the user-facing flow, scaling it introduces new backend challenges. That's where BlockEden.xyz comes in.

• API Layer: Our high-throughput, geo-routed RPC nodes ensure your zkLogin transactions are processed with minimal latency, regardless of user location.
• Observability: Get out-of-the-box dashboards to track key metrics like proof latency, success/fail ratios, and your conversion funnel's health.
• Compliance: For apps that bridge into fiat, our optional KYC module provides a compliant on-ramp directly from the user's verified identity.

Ready to Ship?​

The era of clunky, intimidating wallet flows is over. Spin up a zkLogin sandbox, plug in BlockEden’s full-node endpoint, and watch your sign-up graph bend upward—while your users never even have to hear the word “wallet.” 😉

For years, the crypto world has been hampered by a critical usability problem: the wallet. Traditional wallets, known as Externally Owned Accounts (EOAs), are unforgiving. A single lost seed phrase means your funds are gone forever. Every action requires a signature, and gas fees must be paid in the chain's native token. This clunky, high-stakes experience is a major barrier to mainstream adoption.

Enter Account Abstraction (AA), a paradigm shift set to redefine how we interact with the blockchain. At its core, AA transforms a user's account into a programmable smart contract, unlocking features like social recovery, one-click transactions, and flexible gas payments.

The journey toward this smarter future is unfolding along three distinct paths: the battle-tested ERC-4337, the efficient Native AA, and the highly anticipated EIP-7702. Let's break down what each approach means for developers and users.

💡 Path 1: The Pioneer — ERC-4337​

ERC-4337 was the breakthrough that brought account abstraction to Ethereum and EVM chains without changing the core protocol. Think of it as adding a smart layer on top of the existing system.

It introduces a new transaction flow involving:

• UserOperations: A new object that represents a user's intent (e.g., "swap 100 USDC for ETH").
• Bundlers: Off-chain actors that pick up UserOperations, bundle them together, and submit them to the network.
• EntryPoint: A global smart contract that validates and executes the bundled operations.

The Good:

• Universal Compatibility: It can be deployed on any EVM chain.
• Flexibility: Enables rich features like session keys for gaming, multi-signature security, and gas sponsorship via Paymasters.

The Trade-off:

• Complexity & Cost: It introduces significant infrastructure overhead (running Bundlers) and has the highest gas costs of the three approaches, as every operation goes through the extra EntryPoint logic. Because of this, its adoption has flourished primarily on gas-friendly L2s like Base and Polygon.

ERC-4337 walked so that other AA solutions could run. It proved the demand and laid the groundwork for a more intuitive Web3 experience.

🚀 Path 2: The Integrated Ideal — Native Account Abstraction​

If ERC-4337 is an add-on, Native AA is building smart features directly into the blockchain's foundation. Chains like zkSync Era and Starknet were designed from the ground up with AA as a core principle. On these networks, every account is a smart contract.

The Good:

• Efficiency: By integrating AA logic into the protocol, it strips away the extra layers, leading to significantly lower gas costs compared to ERC-4337.
• Simplicity for Devs: Developers don't need to manage Bundlers or a separate mempool. The transaction flow feels much more like a standard one.

The Trade-off:

• Ecosystem Fragmentation: Native AA is chain-specific. An account on zkSync is different from an account on Starknet, and neither is native to Ethereum mainnet. This creates a fragmented experience for users and developers working across multiple chains.

Native AA shows us the "endgame" for efficiency, but its adoption is tied to the growth of its host ecosystems.

🌉 Path 3: The Pragmatic Bridge — EIP-7702​

Set to be included in Ethereum's 2025 "Pectra" upgrade, EIP-7702 is a game-changer designed to bring AA features to the masses of existing EOA users. It takes a hybrid approach: it allows an EOA to temporarily delegate its authority to a smart contract for a single transaction.

Think of it as giving your EOA temporary superpowers. You don't need to migrate your funds or change your address. Your wallet can simply add an authorization to a transaction, allowing it to perform batched operations (e.g., approve + swap in one click) or have its gas sponsored.

The Good:

• Backward Compatibility: It works with the billions of dollars secured by existing EOAs. No migration needed.
• Low Complexity: It uses the standard transaction pool, eliminating the need for Bundlers and drastically simplifying infrastructure.
• Mass Adoption Catalyst: By making smart features accessible to every Ethereum user overnight, it could rapidly accelerate the adoption of better UX patterns.

The Trade-off:

• Not "Full" AA: EIP-7702 doesn't solve key management for the EOA itself. If you lose your private key, you're still out of luck. It's more about enhancing transaction capabilities than overhauling account security.

Head-to-Head: A Clear Comparison​

The Future is Convergent and User-Centric​

These three paths aren't mutually exclusive; they are converging toward a future where the wallet is no longer a point of friction.

1. Social Recovery Becomes Standard 🛡️: The era of "lost keys, lost funds" is ending. AA enables guardian-based recovery, making self-custody as safe and forgiving as a traditional bank account.
2. Gaming UX Reimagined 🎮: Session keys will allow for seamless gameplay without constant "approve transaction" pop-ups, finally making Web3 gaming feel like Web2 gaming.
3. Wallets as Programmable Platforms: Wallets will become modular. Users might add a "DeFi module" for automated yield farming or a "security module" that requires 2FA for large transfers.

For developers and infrastructure providers like Blockeden.xyz, this evolution is incredibly exciting. The complexity of Bundlers, Paymasters, and various AA standards creates a massive opportunity to provide robust, reliable, and abstracted infrastructure. The goal is a unified experience where a developer can easily integrate AA features, and the wallet intelligently uses ERC-4337, Native AA, or EIP-7702 under the hood, depending on what the chain supports.

The wallet is finally getting the upgrade it deserves. The transition from static EOAs to dynamic, programmable smart accounts is not just an improvement—it's the revolution that will make Web3 accessible and safe for the next billion users.

Hello and welcome back to our blockchain blog! Today, we will be diving into an exciting new proposal called ERC-4337, which introduces account abstraction to Ethereum without requiring any consensus-layer protocol changes. Instead, this proposal relies on higher-layer infrastructure to achieve its goals. Let's explore what ERC-4337 has to offer and how it addresses the limitations of the current Ethereum ecosystem.

What is ERC-4337?​

ERC-4337 is a proposal that introduces account abstraction to Ethereum through the use of a separate mempool and a new type of pseudo-transaction object called a UserOperation. Users send UserOperation objects into the alternative mempool, where a special class of actors called bundlers package them into a transaction making a handleOps call to a dedicated contract. These transactions are then included in a block.

The proposal aims to achieve several goals:

1. Enable users to use smart contract wallets with arbitrary verification logic as their primary accounts.
2. Completely remove the need for users to have externally owned accounts (EOAs).
3. Ensure decentralization by allowing any bundler to participate in the process of including account-abstracted user operations.
4. Enable all activity to happen over a public mempool, eliminating the need for users to know direct communication addresses of specific actors.
5. Avoid trust assumptions on bundlers.
6. Avoid requiring any Ethereum consensus changes for faster adoption.
7. Support other use cases such as privacy-preserving applications, atomic multi-operations, paying transaction fees with ERC-20 tokens, and developer-sponsored transactions.

Backwards Compatibility​

Since ERC-4337 does not change the consensus layer, there are no direct backwards compatibility issues for Ethereum. However, pre-ERC-4337 accounts are not easily compatible with the new system because they lack the necessary validateUserOp function. This can be addressed by creating an ERC-4337 compatible account that re-implements the verification logic as a wrapper and setting it as the original account’s trusted op submitter.

Reference Implementation​

For those interested in diving deeper into the technical details of ERC-4337, a reference implementation is available at https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Security Considerations​

The entry point contract for ERC-4337 must be heavily audited and formally verified, as it serves as a central trust point for the entire system. While this approach reduces the auditing and formal verification load for individual accounts, it does concentrate security risk in the entry point contract, which must be robustly verified.

Verification should cover two primary claims:

1. Safety against arbitrary hijacking: The entry point only calls an account generically if validateUserOp to that specific account has passed.
2. Safety against fee draining: If the entry point calls validateUserOp and passes, it must also make the generic call with calldata equal to op.calldata.

Conclusion​

ERC-4337 is an exciting proposal that aims to introduce account abstraction to Ethereum without requiring consensus-layer protocol changes. By using higher-layer infrastructure, it opens up new possibilities for decentralization, flexibility, and various use cases. While there are security considerations to address, this proposal has the potential to greatly improve the Ethereum ecosystem and user experience.