Account Logic Separation

The core principle of ALS is the separation of concerns. The account (often a simple Externally Owned Account or a minimal smart contract wallet) holds assets like ETH or tokens. A separate logic contract contains the application's business rules. The logic contract is granted permission to operate on the account's assets, but does not hold them directly.

• Benefit: Isolates risk. A bug in the logic contract does not necessarily compromise the underlying assets if permissions are correctly managed.

Because application logic resides in a separate contract, it can be upgraded, replaced, or composed without needing to migrate assets. This enables:

• Protocol Upgrades: Deploy a new, improved logic contract and point the account to it.
• Logic Composability: A single account can interact with multiple, specialized logic contracts (e.g., one for lending, one for swapping).
• Gas Efficiency: Users can deploy lightweight account proxies that delegate to heavy, shared logic contracts.

ALS introduces a clear permission layer. The account contract explicitly defines what actions a logic contract can perform, often through function selectors and allowance limits. This is more granular than blanket approve() functions in ERC-20 tokens.

• Example: An account could allow a DeFi logic contract to borrow up to 1000 USDC but not to withdraw any ETH.
• Mitigates Risk: Limits the blast radius of a compromised logic contract, a principle known as the Principle of Least Privilege.

ALS allows for complex transaction flows to be abstracted into a single user approval. A relayer or bundler can submit a transaction where the user's account executes a sequence of operations across multiple logic contracts, paying fees in the network's native token or even with ERC-20 tokens via gas abstraction.

• Benefit: Enables sponsored transactions and session keys, where users pre-approve certain actions for a limited time, improving the dApp experience.

ALS is commonly implemented using proxy patterns and the delegatecall EVM opcode. A minimal proxy contract (the account) stores the asset state and delegatecalls to a logic implementation contract.

• How it works: delegatecall executes code from the logic contract in the context of the proxy's storage. The logic contract's code runs, but it reads/writes to the proxy's state, including its asset balances.
• Standard: The ERC-4337 account abstraction standard is a prominent implementation of ALS concepts.

In a traditional monolithic contract design, assets and logic are bundled. To upgrade, you must migrate all user funds and state to a new contract—a complex and risky process. ALS solves this by making the logic stateless with respect to asset custody.

• Monolithic: Contract A holds 100 ETH and contains swap logic.
• ALS: Account X holds 100 ETH. Logic Contract Y contains swap logic and is permitted to move assets from X. Y can be upgraded to Y_v2 without touching the 100 ETH in X.

A pattern where a user grants a limited-use key to a dApp, separating one-time approval logic from ongoing interaction logic. The session key:

• Is restricted to specific contract functions, spending limits, and a time window.
• Allows seamless user interaction (e.g., in a game) without constant wallet pop-ups.
• Resides in the smart account's logic, which can revoke it at any time, separating the revocation authority from the temporary usage permission.

Separates the logic of account ownership from the logic of account recovery. Instead of a single private key, recovery is managed by:

• A set of guardians (other wallets or trusted entities).
• A configurable threshold (e.g., 3-of-5) required to execute a recovery transaction.
• A time-delay security period to prevent malicious recovery attempts. This logic is encoded in the smart account contract, making the account resilient to key loss without relying on a centralized service.

A contract that separates the logic of who pays transaction fees from the logic of who signs the transaction. This enables:

• Sponsored transactions: A dApp or employer pays the gas for a user.
• Pay in ERC-20 tokens: Users pay fees in USDC, bypassing the native token (ETH).
• Subscription models: Gas costs are deducted from a prepaid balance. The Paymaster validates the payment logic independently in the EntryPoint, abstracting gas complexity from the end-user.

Separates the logic of signature verification from the core account execution. A smart account can implement multiple validation modules, allowing it to support:

• Multi-chain signatures: Verify a signature from a different blockchain (e.g., Solana sig on Ethereum).
• Biometric authentication: Use a device's secure enclave for signing.
• ZK-SNARK proofs: Prove membership in a group without revealing identity.
• Traditional Web2 auth: Use a signature from an OAuth provider like Google. This turns the account into a programmable verification endpoint.

By decoupling the signing authority from the asset vault, this model creates a powerful security boundary. The core asset-holding account can be a simple, non-upgradable contract or a hardware-secured vault, minimizing its attack surface. Signing logic—handling transaction validation, multi-signature rules, or session keys—resides in a separate, potentially more complex module. This isolation ensures a compromise in the signing logic does not directly compromise the primary assets, as the vault only obeys pre-defined, limited instructions.

Account logic separation turns authorization into a programmable layer. Developers can implement sophisticated spending policies and access controls without modifying the core asset store. Examples include:

• Delegated Signing: Granting a hot wallet limited authority (e.g., up to 1 ETH per day) via a session key.
• Multi-factor Rules: Requiring approvals from a combination of devices, biometrics, or trusted third parties.
• Time-locks & Vesting: Automatically enforcing schedules for fund release. This enables enterprise-grade security models and complex DeFi interactions directly at the account level.

This separation is the foundation for social recovery and non-custodial account abstraction. Users are no longer solely dependent on a single private seed phrase. Recovery can be managed through:

• Guardian networks of trusted contacts or institutions.
• Hardware security modules (HSMs) for enterprise custody.
• Policy-based fallbacks that trigger under specific conditions. It allows for seamless interactions, such as paying gas fees in any token (gas abstraction) and batching multiple operations into a single transaction, without sacrificing ultimate asset custody.

The signing logic module becomes a upgradable component independent of the asset state. This allows for:

• Iterative Security Improvements: New signature schemes (e.g., quantum-resistant algorithms) can be adopted without moving assets.
• Feature Rollouts: Adding support for new standards or dApp-specific functionalities.
• Governance-Controlled Updates: DAOs can manage and upgrade the authorization logic for treasury accounts in a transparent, on-chain manner. This modularity future-proofs accounts and reduces the risk and friction associated with traditional contract migrations.

This pattern is central to smart contract wallets (like Safe, Argent) and account abstraction initiatives (ERC-4337). It shifts the paradigm from externally owned accounts (EOAs) with fixed logic to contract accounts with programmable intent. For dApps, it enables:

• Sponsored Transactions: Applications can pay for user gas, lowering onboarding barriers.
• Atomic Multi-Operations: Complex DeFi strategies can be executed safely in one user-approved bundle.
• Custom Security Models: Tailored wallets for institutions, DAOs, and high-net-worth individuals.

While powerful, this architecture introduces new complexities:

• Increased Gas Costs: Inter-contract calls and more complex validation logic can lead to higher transaction fees.
• Audit Surface: Both the vault and logic contracts, plus their interaction, must be rigorously audited.
• Standardization: Widespread adoption requires robust standards (e.g., ERC-4337, ERC-6900) to ensure interoperability between different logic modules and wallets.
• Network Support: Not all Layer 1 blockchains natively support this model at the protocol level, relying on layer-2 solutions or specific VM features.

Account Logic Separation (ALS) is a security architecture that decouples the authorization logic (who can sign) from the execution logic (what actions can be performed) within an account abstraction system. This creates a clear security boundary, preventing a compromised execution module from tampering with the core signing mechanisms or upgrading the account without proper authorization.

• Authorization Module: Manages signer validation and multi-signature rules.
• Execution Module: Contains the business logic for specific actions (e.g., token swaps, transfers).
• Upgrade Module: A separate, highly restricted component that can modify other modules, if the design allows upgrades.

By separating logic, ALS directly addresses the monolithic contract risk. A bug or exploit in one execution module does not automatically compromise the entire account's funds or control structure.

• Contained Breaches: An attacker who exploits a DeFi interaction module may drain that module's allowances but cannot change the account's owners or drain other assets held in separate vaults.
• Granular Permissions: Modules can be granted specific, limited authorities (e.g., "can spend up to 1 ETH from vault A"), following the principle of least privilege.

The Account Abstraction ecosystem has standardized ALS patterns.

• ERC-4337: Introduces the separation between an Account (holding state and validation logic) and Bundlers/Paymasters (execution and gas abstraction). The account's validateUserOp function is distinct from its execution functions.
• ERC-6900: Explicitly standardizes modular smart contract accounts. It defines core interfaces for a Root Account that orchestrates Modules (e.g., validators, executors, hooks), enforcing strict separation and interoperability.

This architectural pattern provides several concrete security advantages:

• Auditability: Smaller, focused modules are easier to formally verify and audit.
• Reduced Attack Surface: A malicious or buggy plugin cannot escalate privileges to core account control.
• Safe Extensibility: New functionality can be added via new modules without risking the security of existing assets and permissions.
• Recovery Pathways: A compromised module can be individually disabled or upgraded without needing a full account migration.

While enhancing security, ALS introduces design complexity that must be managed.

• Gas Overhead: Inter-module calls and state management can increase transaction gas costs.
• Orchestration Risk: The root account or module manager becomes a critical piece; its logic must be flawless and ideally immutable.
• Composability Challenges: Ensuring modules interact safely, without unexpected side-effects, requires rigorous testing and standard interfaces like those proposed in ERC-6900.

ALS builds upon and interacts with other fundamental security patterns.

• Principle of Least Privilege: The foundational security concept ALS operationalizes for smart contracts.
• Upgradeability Patterns (e.g., Proxy, Diamond): Often used in conjunction with ALS to allow modules to be updated, but must be implemented with extreme caution to not reintroduce centralization risks.
• Formal Verification: The separation of logic makes it more feasible to mathematically prove the correctness of critical authorization modules.