Skip to main content

Why Pay Protocol Doesn't Use ERC-4337 for Now?

· 5 min read
Pay Protocol Dev
Pay Protocol Dev
Pay Protocol Development Team

In the blockchain field, ERC-4337 (Account Abstraction) has been very popular in recent years. It proposes a new account system that allows wallets to move beyond traditional Externally Owned Accounts (EOA) and be completely defined by smart contracts.

It sounds ideal:

  • User operations are submitted through UserOperation (UserOps) instead of regular transactions.
  • Bundlers collect users' UserOps, bundle them into a single transaction, and submit to the blockchain.
  • Account logic (signature methods, multi-factor authentication, limits, recovery mechanisms) is completely controlled by contracts, providing more flexible wallet experiences.

However, after in-depth research, we found: The real-world effectiveness of ERC-4337 in payment business is not as perfect as imagined.

1. Cost Issue: Gas Is Not Actually Cheaper​

  • ERC-4337's Problem

    • Each UserOps requires individual verification of signatures, nonces, and limit logic.
    • These validations are not natively executed by the blockchain main protocol, but simulated by Bundlers in the memory pool.
    • The final calldata submitted on-chain is longer and more complex, resulting in transaction fees often 2-3 times higher than regular transactions.
    • This extra overhead essentially trades "higher costs for more complex wallet logic".

  • Pay Protocol's Solution

    • Users don't need to operate themselves; merchants can batch operations, significantly reducing costs.
    • No additional verification logic, more concise on-chain data, Gas consumption cheaper than standard transactions.

👉 In payment scenarios, low cost is far more important than complex features. Merchants want "cheaper per transaction", not "fancier signature methods".

2. Compatibility Issues​

  • ERC-4337's Problem

    • While the standard unifies UserOps interfaces, specific implementations vary greatly.
    • Smart contract wallets provided by different service providers (like ZeroDev, Biconomy) have inconsistent structures.
    • Application layer faces extremely high compatibility costs when supporting multiple providers. In practice, developers are often forced to choose one provider and get locked into their ecosystem.

  • Pay Protocol's Solution

    • Our keyless accounts are based on contract factories, following standard EVM logic.
    • Works out-of-the-box on any EVM public chain, without depending on specific service providers.

👉 For merchants, the real meaning of openness is not "new standards", but "switch chains anytime, integrate anytime".

3. Upgrade & Maintenance: Proxy Complexity vs Template Simplicity​

  • ERC-4337's Problem

    • Once contract wallets are deployed, their logic is hardcoded.

    • To add new features, the Proxy upgrade pattern is typically required:

      1. Write a new logic contract first.
      2. Modify Proxy pointer to point to new logic.
      3. Handle old data migration and security audits.

    • This process is not only cumbersome but also prone to introducing new vulnerabilities, increasing audit costs.

  • Pay Protocol's Solution

    • Keyless accounts are batch-generated based on template contracts.
    • When upgrades are needed, simply publish a new template version and batch-generate new accounts.
    • No need to handle Proxy complexity; migration path is simple and direct.

👉 Simplicity is security; the more complex the contract structure, the higher the probability of issues.

4. Security Risks: Greater Flexibility Also Brings Larger Attack Surface​

  • ERC-4337's Problem

    • Since account logic is programmable, it can theoretically support any signature or permission control method.
    • But greater flexibility also means more ambiguous security boundaries.
    • Past cases have shown: attackers can create "unauthorized accounts" through vulnerabilities, even bypassing verification.
    • Such risks are unacceptable in payment business.

  • Pay Protocol's Solution

    • The logic of keyless accounts is extremely simple: just a factory contract responsible for generating standard accounts.
    • No complex multi-factor verification or external dependencies, thus no additional attack surface.

👉 For the payment industry, security comes first.

Comparison Summary​

DimensionERC-4337Pay Protocol Keyless Accounts
CostUserOps cost 2-3x higher, increased Gas costMerchant batch aggregation, low operation cost, minimal Gas cost
CompatibilityLarge provider differences, difficult cross-platform applicationWorks directly on any EVM chain
Upgrade & MaintenanceRequires Proxy upgrades, complex and costlyUpdate template once, batch deploy, simple maintenance
Security RiskFlexible but large attack surface, known vulnerability casesExtremely simple logic, small attack surface

Our Conclusion​

ERC-4337 represents the future direction of wallet development: more flexible, more personalized, more intelligent. But it's still in early stages with an immature ecosystem:

  • Bundler operation relies on a few service providers → De facto centralization.
  • High costs → Not suitable for high-frequency payments.
  • Upgrade and compatibility not friendly enough → Increases maintenance costs.

For payment business, saving money, peace of mind, and security are the core values.

Therefore, Pay Protocol will not adopt ERC-4337 for now, but chooses a more direct, controllable, and stable keyless account solution to provide merchants and users with a payment experience that's usable today and secure enough.

Summary in one sentence: ERC-4337 is the future, but Pay Protocol is solving today's payment problems.