Modular Account V2

Modular Account V2 contains a suite of modular smart contract accounts and modules. Modular Account V2 is maximally secure, modular, and has the cheapest creation costs amongst ERC4337-compatible smart contract accounts.

The accounts are upgradeable, can create session keys with scoped permissions on the account, and can use gas sponsorship provided by the ERC-4337 protocol. It can be used for most smart account use cases due to high flexibility from its modular design.

Modular Account V2 contains 4 smart account implementations:

• ModularAccount (ERC4337 compatible)
• SemiModularAccountBytecode (ERC4337 compatible)
• SemiModularAccountStorageOnly (ERC4337 compatible)
• SemiModularAccount7702 (EIP-7702 + ERC4337 compatible)

The repository also contains 2 signature verification modules and 4 permissioning modules.

Scope

In-Scope Targets

Smart Contracts in Scope

Following are in-scope contracts from the github repo: https://github.com/alchemyplatform/modular-account/tree/v2.0.x

Out-of-Scope

Smart contracts not in the v2.0.x release branch are considered out of scope.

Known Issues

Known issues from previous security reviews are considered out of scope.

Previous security reviews can be found at: https://github.com/alchemyplatform/modular-account/tree/v2.0.x/audits

Other known issues that are out of scope:

• SemiModularAccount7702: when upgrading to a SMA7702 account from an existing account, or upgrading from an SMA7702 account to a new 7702 account, if the signature format is the same in the new account, the bundler is able omit the upgrade from the auth tuple to keep the gas paid for updating the auth tuple. This can be mitigated by starting from or ending with an account with a different signature format. This would be addressed in a subsequent release.
• Deferred Actions: Bundlers or relayers can replace deferred actions with separate deferred actions. Deferred actions are meant to be used in a way such that removing it would cause a validation failure, e.g. approving ERC20 tokens to a ERC20 paymaster before the paymaster validation check, or installing a session key before validation of that session key, thus security impacts due to such usage are considered out of scope.

Specific Types of Issues

• User error: Examples include: transferring tokens or account ownership to address(0), or financial losses due to granting permissions to a malicious entity, or using a non EIP-7702 account in the EIP-7702 context.
• Interactions with 3rd party malicious code. Examples include: installing a faulty or malicious module.
• Bad behavior from owners. Examples include: an owner DoSing another owner of the same account.
• Security impacts to accounts due to issues in the ERC-4337 EntryPoint would not be eligible for a modular account bug bounty.
• Issues related to counterfactual addresses or cryptography attacks that are not economically viable. Examples include generating a hash collision to take over a user's undeployed ERC-4337 account, or mining EOA addresses to collide with smart contract accounts.
• Design choices related to protocol. Examples include: two step ownership transfers.
• Rounding errors.
• Relatively high gas consumption.
• Extreme market turmoil vulnerability.

Prohibited Actions

• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Live testing on public chains, including public mainnet deployments and public testnet deployments is prohibited. We recommend testing on local forks, for example using foundry.
• Privacy violations, destruction of data, and actions that cause interruption or degradation of our services are prohibited. Only interact with accounts you own or with explicit permission of the account holder.
• Public disclosure of bugs without the written consent of the Alchemy team is prohibited.
• No Conflicts of Interest. Any individual who is or has ever been employed by Alchemy (or their family), or who is or has ever been a contractor of Alchemy, may not participate in the Bug Bounty. Additionally, any individual who has been involved in or contributed to the development of the code of the bug in question (or their family) may not participate in the Bug Bounty.

Eligibility

• You must discover a previously-unreported, non-public vulnerability that is not previously known by the Alchemy team and is within the scope of this bug bounty program (the "Program").
• You must provide all KYC and other documents as requested.
• You must be the first to disclose the unique vulnerability, in compliance with the disclosure requirements. A vulnerability caused by an underlying issue that is the same as an issue on which a reward has been paid under this Program is not eligible for a reward.
• You must provide sufficient information to enable our engineers to reproduce and fix the vulnerability.
• You cannot exploit the vulnerability in any way, including through making it public or by obtaining a profit (other than a reward under this Program).
• You cannot publicize or exploit a vulnerability in any way, other than through private reporting to us.
• You must refrain from any privacy violations, destruction of data, interruption or degradation of any of the assets or systems in scope.
• You cannot engage in any unlawful conduct when disclosing the bug, including through threats, demands, or any other coercive tactics.
• You must be at least 18 years old at the time of submission.
• You cannot reside in a country under (or otherwise be subject to) any trade or economic sanctions by the United States Treasury's Office of Foreign Assets Control or other applicable sanctions laws, or where the laws of the United States or local law prohibits participation.
• You cannot be one of our current or former employees (or their family member), or a vendor or contractor who has been involved in the development of the code of the bug in question.
• You must comply with all the rules of the Program, including but not limited to, refraining from engaging in any Prohibited Actions.

Severity and Rewards

Risk Classification Matrix

Smart Contracts

Rewards given are determined by the security impact, as well as the likelihood of the security impact. All submissions need to contain a clear, reproducible and working proof-of-concept to be eligible for a reward. Any submissions that do not require a redeployment would be capped at a low or medium severity.

Impact Assessment

The impact levels provided below should only be considered guidelines as the impact of a report will be defined on a case-by-case basis solely determined by Alchemy.

Critical:

• Stealing funds or permanently freezing funds from accounts on a large scale (20+% TVL across all accounts, and/or stealing native tokens or common ERC20s)
• Loss of control or access to accounts

High:

• Stealing funds, or temporarily/permanently freezing funds from accounts at a medium scale (1-20% TVL across all accounts)
• Loss of access to important features on accounts

Medium:

• Stealing funds, or temporarily/permanently freezing funds from accounts at a smaller scale (such as gas related issues)
• Loss of access to other features on accounts
• Loss of funds, or temporarily/permanently freezing funds from the AccountFactory contract
• Loss of control or access to the AccountFactory contract

Low:

• The issue does not pose an immediate risk but is relevant to security best practices.

Likelihood Assessment

The likelihood levels provided below should only be considered guidelines as the impact of a report will be defined on a case-by-case basis solely determined by Alchemy.

High: Affects most accounts in production. Must affect accounts in the default configuration from the factory, or for very common use cases such as session keys, and/or requires little to no privileged access.

Medium: Affects a significant portion of accounts in production. It must also be likely under specific conditions or scenarios, or it being a reasonably common use case, or a likely configuration of the account, and/or requires little to no privileged access.

Low: Rare but conceivable. This may cover use cases that are not in production today, or attacks that require privileged access.

Reward Ranges

Note: Actual reward amounts are determined at Alchemy's sole discretion. Factors influencing payout include quality of report, completeness, and the severity and exploitability of the vulnerability.

Other Terms

By submitting your report, you grant Alchemy any and all rights, including intellectual property rights, needed to validate, mitigate, and disclose the vulnerability. All reward decisions, including eligibility for and amounts of the rewards and the manner in which such rewards will be paid, are made at Alchemy's sole discretion. The terms and conditions of this Program may be altered, and this Program may be wound down, at any time.