Modules

Modular Smart Accounts (MSA) provides a superior level of adaptability compared to normal accounts. Unlike normal accounts, which often require developer intervention for modifications and involve intricate proxy upgrades, MSA employs an innovative approach by decentralizing functionalities into external contracts known as modules. With MSA, users gain the ability to effortlessly install or uninstall these modules, eliminating the necessity for complete account redeployment.

Abstraxn's Modular Smart Account (MSA) incorporates two distinct types of modules:

• Validation modules - These modules establish various signature schemes or authorization mechanisms, ensuring validation of users permitted to execute specific actions on the account by adhering to standard interfaces.
• Execution modules - These modules define customized execution functions, streamlining the execution of actions permitted by the account.

Enabling Modules:

During the deployment of the Modular Smart Account (MSA), a default validation module is enabled. Internally, this process triggers the deployCounterFactualAccount method on the smart account factory. The selection of the module used to deploy the MSA determines its ultimate address, given its counterfactual nature.

A new module can be enabled via a userOp transaction on a smart account by specifying the module address and moduleSetupData. Internally, this activates the setupAndEnableModule method on the Module Manager. The newly enabled module can then be designated as the active validation module for subsequent transactions.

const isEnabled = await smartAccount.isModuleEnabled(module_address);
if (!isEnabled) {
 const enableModuleTrx = await smartAccount.getEnableModuleData(
   module_address
 );
 transactionArray.push(enableModuleTrx);
}
smartAccount = smartAccount.setActiveValidationModule(module);

As per the code, the initial step is to verify whether the module is already enabled. If the module is not enabled, a transaction can be performed to enable it.

note

The module passed during the deployment acts as the default validation module. This module gets used as an active validation module if no other module is enabled.

Validation Modules

The validation Module is a module that extends the abstract contract BaseAuthorizationModule** - which implements the IBaseAuthorizationModule interface. This interface requires the implementation of the following methods:

• validateUserOp: This method verifies userOperation by expecting userOp callData for executing method calls of the Smart account and userOp signature encoded as ABI. Additionally, it requires the module address.
• isValidSignature: This method validates an EIP-1271 signature.
• isValidSignatureUnsafe: This method also validates an EIP-1271 signature but anticipates the data Hash to already encompass smart account address information.

Validation modules are invoked with a “call”. It has its own storage and doesn’t share storage with Abstraxn Smart Account. Since validation module storage is accessed during the validation phase, ERC-4337 storage rules apply to this.

info

Validation Modules in MSA play a crucial role in determining who can perform actions, ensuring security and proper authorization.

Following is the list of Validation Modules:

• ECDSA Ownership Module: Widely embraced as a validation module for Abstraxn smart accounts, this module seamlessly integrates with MPC providers like Web3Auth. It abstracts EOA Private Key storage, facilitating a web2-like experience such as email login.
• Multichain ECDSA Validator Module: This module significantly enhances user experience in deploying and configuring Smart Accounts across multiple chains. An extension of the ECDSA Module, it enables the dispatch of multiple userOps on different chains using a single signature.
• Session key Manager Validation Module: This module facilitates transaction execution using sessions. It verifies whether a given user operation aligns with the permissions defined within the session key and confirms that the operation has been signed by that session key. It can only function as an active validation module.
• MultiOwnedECDSAModule: This module is a modification of the ECDSA Module, allowing the setup of multiple signers. Any of the enabled owners can authorize a transaction using the ECDSA signature.

How to create a custom Validation Module

Developers possess the freedom to craft a custom validation module tailored to their specific needs. This validation module must extend the BaseAuthorizationModule, which implements the IAuthorizationModule and ISignatureValidator interfaces.

Key Imports and Their Roles

1. BaseAuthorizationModule
   • Core Structure: Serves as the foundational structure for your custom module.
   • Link to Interfaces: Establishes connections to IAuthorizationModule and ISignatureValidator.
2. IAuthorizationModule
   • Operation Validation: Oversees the validation of user operations (userOp).
   • Method Implementation: Specifies the methods your module must implement for operation validation.
3. ISignatureValidator
   • Signature Security & Standardization: Focuses on validating signatures and adheres to the ERC-1271 standard for smart contract-based signatures.
   • isValidSignature Method: Crucial for verifying signatures and ensuring security.

note

Adherence to the functionalities and standards outlined by these interfaces is paramount. It guarantees the secure and efficient operation of your custom validation module. Once thorough testing and auditing are completed, a pull request (PR) can be submitted to integrate the module with the SDK. A detailed guide for this process is available here.

After thorough testing and auditing, a pull request (PR) can be submitted to integrate the module with the SDK. A detailed walkthrough of the same is linked.

Execution Modules

Execution functions perform any custom logic permitted by the account.

Two default execution functions, namely execute and executeBatch, facilitate open-ended execution necessary for AA-flow. The custom execution module must initiate a function call from within the account's context by reverting to the Smart Account. The diagram below illustrates the execution flow for Modular Smart Accounts.

caution

Execution modules should be carefully developed and integrated, as they directly control the actions an account can perform.