Nexus Smart Account Architecture

The Nexus Smart Account architecture is designed to provide a robust, modular, and flexible framework for managing smart accounts. This section delves into the architecture of the Nexus project, explaining the core components and how they interact to offer advanced functionalities.

Overview

Nexus Smart Accounts are compliant with ERC-7579, ERC-4337, ERC-7739, and ERC-7484 standards. These standards enhance the modularity, security, and extensibility of Nexus, particularly through typed signature validation, module attestations, and multi-type module installations, ensuring secure, flexible, and gas-optimized smart account management.

The following diagrams illustrate the overall flow and structure of the Nexus Smart Account.

Core Components

Smart Account Factory

The Smart Account Factory is responsible for deploying new smart accounts. It interacts with the EntryPoint to ensure that smart accounts are created and initialized correctly.

EntryPoint

The EntryPoint serves as the main gateway for executing user operations and managing the flow of transactions. It handles validation, gas estimation, and ensures that transactions comply with predefined rules.

Paymaster

The Paymaster module supports various payment schemes, including sponsorship and token-based payments. It ensures that transactions have sufficient gas to execute and handles gas reimbursements.

Validation Modules

Validation Modules are essential for verifying the integrity and authenticity of transactions. They include various schemes such as ECDSA ownership, multi-signature validation, session key management, and the nested typed data validation workflow.

ERC-7739 introduces readable typed signatures, enhancing phishing resistance and preventing replay attacks across multiple smart accounts. This standard improves user confidence and security by enabling validators to process nested typed data signatures. This implementation ensures compatibility with wallet clients like Metamask.

ERC-7484 adds an extra layer of security by introducing Registry Adapters for smart accounts. These adapters allow the system to verify security attestations for individual modules through an attestation registry. By associating security attestations with specific modules, ERC-7484 ensures that only secure and trustworthy modules can be installed, further enhancing the modular security model.

Execution Modules

Execution Modules handle the actual execution of transactions. They support different execution modes, including single, batch, and delegate calls. Execution modules ensure that transactions are executed securely and efficiently. Multi-Type Execution: The Nexus architecture supports multi-type execution modules. This allows for executing multiple types of modules (validators, executors, hooks) in a single operation using the MODULE_TYPE_MULTI. This enhances flexibility and reduces the overhead of deploying and managing different module types separately.

Hook Modules

Hook modules in Nexus allow adding custom logic before or after transactions. One critical feature is resource locking, particularly for emergency hook uninstallations. When a hook needs to be removed, the emergencyUninstallHook function applies a timelock to secure the process, preventing accidental or malicious removal by enforcing a delay before the hook can be uninstalled.

• Pre-Execution Hooks: Triggered before the main transaction to handle tasks like validating inputs or checking preconditions.
• Post-Execution Hooks: Triggered after the transaction to log activities or initiate follow-up actions.

[!IMPORTANT]
Resource locking ensures that key modules, such as hooks, cannot be uninstalled without waiting for a pre-defined timelock, safeguarding the account's integrity. Hooks are essential for adding custom behavior, including additional validations, logging, or triggering events based on the transaction flow.

Fallback Handlers

Fallback handlers manage transactions that do not match any predefined function signatures or encounter errors during execution. They ensure that the smart account can gracefully handle unexpected conditions and provide a mechanism for recovering from errors.

Execution Flow

The execution flow in Nexus Smart Accounts involves multiple steps, including validation, execution, and post-execution hooks. The following subsections explain the different execution types and how they are managed within the system.

Execution Modes

Nexus supports various execution modes to cater to different use cases:

• Single Execution: Executes a single transaction.
• Batch Execution: Executes multiple transactions in a single call.
• Delegate Execution: Executes transactions in the context of another contract.

Nexus also introduces Enable Mode, a signature-based execution mechanism that enables specific modules using typed signatures. This is validated using the _checkEnableModeSignature function, which supports both standard and ERC-7739 signature validation flows. Enable Mode ensures that modules are dynamically enabled using trusted signatures from registered validators.

Signature Flows Supported:

• ERC-7739 Typed Data
• Legacy Validation

Execution Functions

The core functions responsible for managing executions are:

• execute: Handles single or batch transactions based on the specified mode.
• executeFromExecutor: Allows an executor module to perform transactions on behalf of the smart account.
• executeUserOp: Executes user operations via a call using the contract's context.

Security Considerations

[!IMPORTANT] Security is paramount in the Nexus architecture. All execution functions are protected by strict access control mechanisms to prevent unauthorized transactions. The architecture also supports ERC-7484 security attestations, where modules can be validated through a registry to ensure they meet predefined security standards. This feature prevents the use of unverified or potentially vulnerable modules.

• onlyEntryPointOrSelf: Ensures that only the EntryPoint or the smart account itself can execute certain functions.
• withHook: Adds pre and post-execution hooks to ensure that additional checks and balances are applied during transaction execution.

Call and Execution Types

• CallType: Defines how the execution calldata should be decoded (single, batch, or delegate).
• ExecType: Determines how the account should handle the execution (default, try/catch).

Example Usage

When a user wants to execute a batch of transactions, the execute function is called with the appropriate ExecutionMode. The system will decode the batch, validate each transaction, and then execute them in sequence.

[!NOTE] It's crucial to ensure that all necessary validation modules are installed and configured correctly to maintain the integrity and security of the smart account.

Conclusion

The Nexus Smart Account architecture is designed to offer a high level of flexibility, security, and modularity. By leveraging advanced execution modes and validation mechanisms, Nexus provides a robust framework for managing smart accounts in the Ethereum ecosystem. Additionally, the inclusion of ERC-7484 enables the system to validate the security of modules through registries, ensuring a higher level of trust and security

Nexus is fully compatible with the latest version of the Entrypoint contract, v0.7, ensuring seamless integration with advanced Ethereum account abstraction features.

For further details and technical documentation, please refer to the Nexus GitHub repository.