6 posts tagged with "Account Abstraction"

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.