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

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.

---

5. Target Customer Base: toC vs toB Fundamental Differences

• ERC-4337's Positioning

  • Primarily targets C-end individual users, providing them with smarter wallet experiences.
  • Focuses on solving individual user pain points: forgetting private keys, complex signature operations, lack of social recovery, etc.
  • Users are willing to pay extra costs for better experiences, with relatively low sensitivity to Gas fees.
  • Pursues wallet functionality differentiation and personalization.

• Pay Protocol's Positioning

  • Focuses on serving B-end merchants and payment platforms, helping them quickly integrate blockchain payments.
  • Emphasizes enterprise-level needs: batch processing, cost control, compliance requirements, system integration.
  • Merchants are extremely cost-sensitive; even a 1% reduction in transaction fees brings significant benefits.
  • Pursues stability, predictability, and large-scale operations.

👉 Different customer groups have completely different core demands. ERC-4337 solves "making personal wallets more user-friendly", while Pay Protocol solves "making merchant payments more cost-effective".

---

Comparison Summary

Dimension	ERC-4337	Pay Protocol Keyless Accounts
Target Customer	Individual Users, pursuing wallet experience upgrades	Merchants & Payment Platforms, pursuing cost & efficiency
Cost	UserOps cost 2-3x higher, increased Gas cost	Merchant batch aggregation, low operation cost, minimal Gas cost
Compatibility	Large provider differences, difficult cross-platform application	Works directly on any EVM chain
Upgrade & Maintenance	Requires Proxy upgrades, complex and costly	Update template once, batch deploy, simple maintenance
Security Risk	Flexible but large attack surface, known vulnerability cases	Extremely 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 focuses on enhancing personal wallet experiences, while Pay Protocol focuses on solving enterprise payment cost issues.

---