What is ERC4337 on Solana?

ERC-4337 is a standard designed to bring Account Abstraction (AA) to Ethereum. Under Ethereum’s existing account model, user accounts (externally owned accounts, or EOAs) and contract accounts (CAs) are strictly separated, and a CA cannot issue transactions on its own. This means that whenever developers want to implement advanced features such as multisig or social recovery they typically have to rely on an EOA to trigger those contract functions and pay transaction fees, which can lead to a less streamlined user experience.

To address this, ERC-4337 introduces a separate mempool and “bundler” (block producer) mechanism that does not require major protocol-layer changes. Through this system, contract accounts (CAs) can directly initiate and sign transactions. In doing so, developers gain the flexibility to implement features like social recovery, fee sponsorship, session keys, and other custom security models, ultimately making Account Abstraction a reality on Ethereum.

How Has Solana Already Solved the Same Problem?

In contrast to Ethereum’s approach, Solana was designed from the outset to support account abstraction at a protocol level. Below are the main reasons why Solana inherently addresses many of the issues that ERC-4337 seeks to solve:

All Accounts as Flexible Data Storage

Solana treats every account as a flexible “storage bucket,” capable of holding arbitrary data. In other words, an account on Solana is not limited to storing a simple balance or nonce: 

• Data Persistence: Each account can store state and metadata for various use cases, similar to how a file in a filesystem can contain different types of content. 
• Ownership: An account on Solana specifies which program (smart contract) owns it. That ownership determines how the account’s stored data is controlled, updated, or validated. 

This design naturally allows for much broader state management compared to traditional EOAs on Ethereum, which are restricted to storing only balances and nonces.

Programs as Executable Accounts

Solana smart contracts are called programs, and each program is also an account, specifically, an executable account. By contrast, a non-executable (data) account is used to store actual state (e.g., user balances, configuration data, or other custom info): 

• Program Account: Contains compiled code that the Solana runtime can execute. 
• Data Account: Holds data and assets that a program manages. 

Because programs exist as dedicated accounts, developers can easily separate a contract’s logic from the storage of user or application data. In many ways, this is more modular than Ethereum’s approach, where code and state reside within the same contract account.

العناوين المشتقة من البرنامج (PDAs) - جوهر AA الأصلي في سولانا

التشابه الوثيق مع "حساب العقد كمُنشئ للمعاملة" في ERC-4337 هو ميزة العنوان المشتق من البرنامج (PDA) في سولانا. العنوان المشتق من البرنامج هو عنوان يتم إنشاؤه بواسطة برنامج سولانا نفسه، بدلاً من أن يكون مُشتقاً من مفتاح خاص. وهذا له تداعيات أساسية: 

لا حاجة لمفتاح خاص

• يمكن للعنوان المشتق من البرنامج "التوقيع" بشكل فعال على التعليمات على السلسلة دون امتلاك مفتاح خاص. تتعرف بيئة تشغيل سولانا على أن برنامجاً معيناً مُخوَّل بالتصرف نيابة عن هذا العنوان. 

قواعد ومنطق مخصص 

• نظراً لأن العنوان المشتق من البرنامج مرتبط ببرنامج معين، يمكن للمطورين تضمين قواعد مثل حدود الإنفاق، أو القوائم البيضاء/السوداء، أو آليات الاسترداد الاجتماعي، أو أذونات تشبه الجلسات، مباشرة في المنطق على السلسلة. 

عقود ذاتية التنفيذ 

• على إيثيريوم، يتطلب تجريد الحساب عموماً استدعاءات خارجية (من EOA أو عبر مجمّع ERC-4337) لكي يقوم العقد بأي شيء. على سولانا، يمكن لبرنامج يتحكم في العنوان المشتق من البرنامج إدارة انتقالات الحالة بشكل مستقل ضمن قيود بيئة تشغيل سولانا. 

من دفع رسوم المعاملات نيابة عن المستخدمين إلى تمكين تدفقات التوقيع المتعدد المتقدمة أو إعادة التوازن الآلية في بروتوكولات التمويل اللامركزي، توفر العناوين المشتقة من البرنامج مجموعة من الإمكانيات الأصلية في سولانا.

Built-In Support for Complex Interactions (CPI)

Solana also supports Cross-Program Invocation (CPI), which allows programs, and by extension their PDAs, to interact directly with one another. This is essential for composability: 

• A program can call another program using CPI, while retaining control over its PDAs and adhering to the Solana runtime’s security model. 
• Developers do not need external bundlers or specialized “entry points” to chain multiple contract calls. Instead, they orchestrate everything via straightforward CPI calls within a single transaction flow. 

For account abstraction, CPI means seamless composability among different programs and PDAs precisely the kind of flexibility ERC-4337 is designed to enable on Ethereum.

A Comparison with ERC-4337

When viewed side by side, Solana’s account model and Ethereum’s ERC-4337 solution both aim to provide more dynamic, programmable user accounts. However: 

• Ethereum (ERC-4337): Relies on a bundler and a specialized mempool to let contract accounts originate transactions without deep protocol changes. 
• Solana: Naturally supports an environment where any account can store custom data, and where programs can own PDAs that operate without private keys. 

يسعى كلا النهجين لتحسين تجربة المستخدم وتوسيع نطاق التطبيقات على السلسلة. لكن تصميم سولانا أصلي ولا يتطلب معايير أو مقترحات إضافية لتحقيق وظائف مماثلة.