5 posts tagged with "Account Abstraction"

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.