feat: choosing your signer, light account, modular account doc update (…

…#215)

Co-authored-by: Rohan Thomare <rohanthomare@gmail.com>

packages/core/src/account/base.ts

@@ -142,6 +142,7 @@ export abstract class BaseSmartContractAccount<
   /**
    * this should return the init code that will be used to create an account if one does not exist.
    * This is the concatenation of the account's factory address and the abi encoded function data of the account factory's `createAccount` method.
+   * https://github.com/eth-infinitism/account-abstraction/blob/abff2aca61a8f0934e533d0d352978055fddbd96/contracts/core/SenderCreator.sol#L12
    */
   protected abstract getAccountInitCode(): Promise<Hash>;
 

site/packages/aa-accounts/light-account/introduction.md

@@ -70,5 +70,6 @@ const result = await LightSmartContractAccount.transferOwnership(
 
 ## Developer Links
 
-[LightAccount Github Repo](https://github.com/alchemyplatform/light-account)
-[Quantstamp Audit Report](https://github.com/alchemyplatform/light-account/blob/main/Quantstamp-Audit.pdf)
+- [LightAccount & Simple Account Deployment Addresses](/smart-accounts/accounts/deployment-addresses)
+- [LightAccount Github Repo](https://github.com/alchemyplatform/light-account)
+- [Quantstamp Audit Report](https://github.com/alchemyplatform/light-account/blob/main/Quantstamp-Audit.pdf)

site/smart-accounts/accounts/choosing-a-smart-account.md

@@ -38,14 +38,10 @@ Account Kit provides a default smart account called `LightAccount`.
 
 For most applications, we recommend using the Light Account. It is [deployed](/smart-accounts/accounts/deployment-addresses) on Ethereum, Optimism, Arbitrum, Polygon, Base, and the respective testnets.
 
-Here's a snippet that demonstrates how to work with the Light Account using Account Kit. This snippet sets up a Light Account and initiates a `UserOperation` from it:
-
-<!--@include: ../../getting-started.md{56,68}-->
-
 ## Modular Account (coming soon)
 
-We authoring a standard for modular smart accounts called [ERC-6900](https://eips.ethereum.org/EIPS/eip-6900). Soon we will release an ERC-6900 compatible [Modular Account](/smart-accounts/accounts/modular-account). This will be an optional upgrade from Light Account to unlock an ecosystem of plugins for your smart account stack.
+We are authoring a standard for modular smart accounts called [ERC-6900](https://eips.ethereum.org/EIPS/eip-6900). Soon we will release an ERC-6900 compatible [Modular Account](/smart-accounts/accounts/modular-account). This will be an optional upgrade from Light Account to unlock an ecosystem of plugins for your smart account stack.
 
 ## Use Your Own Account
 
-If Light Account doesn't fit your specific needs, you can always use your own smart account implementation with Account Kit. To learn how, see the guide on [Using Your Own Account Implementation](/smart-accounts/accounts/using-your-own).
+If Light Account doesn't fit your specific needs, you can always use your own smart account implementation with Account Kit. To learn how, see our guide in the [Using Your Own](/smart-accounts/accounts/using-your-own) section.

site/smart-accounts/accounts/modular-account.md

@@ -18,33 +18,46 @@ head:
       content: Coming soon! Follow this guide to use Modular Accounts with Account Kit, a vertically integrated stack for building apps that support ERC-4337.
 ---
 
-# Modular Account Smart Contract
+# Modular Account
 
-We are working towards the first stable version of [ERC-6900](https://eips.ethereum.org/EIPS/eip-6900) with [the community](https://ethereum-magicians.org/t/erc-6900-modular-smart-contract-accounts-and-plugins/13885).
-
-Soon after, we will release an ERC-6900 compatible Modular Account in Account Kit. It will support new use cases like session keys, account recovery, spending limits, and any ERC-6900 plugin you can imagine. The Light Account is forward-compatible with ERC-6900 so you can optionally upgrade it to the Modular Account once released.
-
-If you're developing a plugin or modular account, we'd love to chat! Join the Modular Accounts [Telegram group](https://t.me/+KfB9WuhKDgk5YzIx) or [say hello](mailto:account-abstraction@alchemy.com) to a team member at Alchemy.
+Soon after the first stable version of [ERC-6900](https://eips.ethereum.org/EIPS/eip-6900), we will release an ERC-6900 compatible Modular Account in Account Kit. It will support new use cases like session keys, account recovery, spending limits, and any ERC-6900 plugin you can imagine. The Light Account is forward-compatible with ERC-6900 so you can optionally upgrade it to the Modular Account once released.
 
 Read on to learn more about ERC-6900 and modular accounts.
 
-# Motivation
+:::tip Note
+We are working towards the first stable version of [ERC-6900](https://eips.ethereum.org/EIPS/eip-6900) with [the community](https://ethereum-magicians.org/t/erc-6900-modular-smart-contract-accounts-and-plugins/13885). If you're developing a plugin or modular account, we'd love to chat! Join the Modular Accounts [Telegram group](https://t.me/+KfB9WuhKDgk5YzIx) or [say hello](mailto:account-abstraction@alchemy.com) to a team member at Alchemy.
+:::
+
+## Motivation
 
 In the coming years, we expect most user accounts to be smart contract accounts that leverage the benefits of account abstraction. These accounts will generally share a similar set of core features such as signature validation and ownership transfer. To ensure this core feature set is secure and does not contain any vulnerabilities, it will be prudent for most developers to re-use battle-tested smart accounts rather than writing their own accounts.
 
 However, smart acounts are also programmable, enabling developers to build new and innovative features that hook into the validation and execution logic of a smart account. We hope and expect to see a diverse ecosystem of plugins flourish.
 
 In order to maximize interoperability and code re-use, these plugins will ideally share a standard interface that is compatible with every smart contract account.
 
-# ERC-6900: Modular Smart Contract Accounts and Plugins
+Refer to the Account Abstraction [series](https://www.alchemy.com/blog/account-abstraction) on our blog to learn more.
+
+## ERC-6900: Modular Smart Contract Accounts and Plugins
+
+### Introduction
 
 We authored [ERC-6900](https://eips.ethereum.org/EIPS/eip-6900) to propose a standard interface for modular smart contract accounts and plugins.
 
+The standard builds on earlier work by the Android developer community to standardize the interface between smart accounts and plugins. Each compliant plugin will incorporate a manifest that establishes various functions and hooks that need to be added to the smart account on installation. It will also specify aspects of the plugin (metadata, dependencies and permissions) that are necessary to constrain the plugin’s ability to act on the smart account.
+
+Taken together, these interactions enable a workflow that supports the seamless installation of plugins in a manner that ensures security and flexibility:
+
+1. Plugin developers and users set each plugin’s permissions and specifies validation and hooks during installation of the the plugin onto the account.
+2. Based on these permissions, plugins can then change account states or execute on behalf of the account.
+
 By standardizing basic functions and interfaces, ERC-6900 seeks to foster a growing ecosystem of wallet and plugin developers. These developers should be able to write one plugin that works with all smart accounts, rather than fragmenting their efforts across multiple different account implementations.
 
 For users, this standard will make it easier to discover and enable plugins. Imagine a future where a user with an ERC-6900 compatible account can install any of a thousand plugins to their smart account.
 
-### **Architecture**
+For more detailed specifications of transaction flows, see the [ERC-6900 spec](https://eips.ethereum.org/EIPS/eip-6900).
+
+### Architecture
 
 The standard focuses on the development of modules or plugins, and on the interactions between these plugins and modular smart contract accounts (or “MSCA”). Following [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337), it splits validation and execution functions in order to allow for greater customization within these components while also ensuring that they remain composable. It also adds pre- and post-execution hooks as a third functional component to plugins, enabling more finely grained functionality.
 
@@ -65,17 +78,8 @@ The standard seeks to support open innovation in plugin development by standardi
 - **Execution functions** are smart contracts that specify the execution logic for functions within a plugin.
 - **Hooks** specify more fine-grained actions and validations that can be designed to occur pre- or post-validation, and pre- or post-execution.
 
-### **Interacting with plugins**
+### Interacting with plugins
 
 ERC-6900 seeks to balance the benefits of open composability in users’ and developers’ choices with the need to maintain fundamental characteristics of security and interoperability. At a high level, it does this by standardizing how accounts and plugins interact with each other, as well as the pre-installation requirements for plugins.
 
 ERC-6900 provides multiple possible types of interactions with plugins that vary with the nature of the account. For ERC-4437 compliant smart accounts, it follows that standard’s introduction of `Entrypoint` contract calls via UserOperations. The standard also supports calls from other account types, whether EOA or a different smart account standard.
-
-The standard also builds on earlier work by the Android developer community to standardize the interface between smart accounts and plugins. Each compliant plugin will incorporate a manifest that establishes various functions and hooks that need to be added to the smart account on installation. It will also specify aspects of the plugin (metadata, dependencies and permissions) that are necessary to constrain the plugin’s ability to act on the smart account.
-
-Taken together, these interactions enable a workflow that supports the seamless installation of plugins in a manner that ensures security and flexibility:
-
-1. Plugin developers and users set each plugin’s permissions and specifies validation and hooks during installation of the the plugin onto the account.
-2. Based on these permissions, plugins can then change account states or execute on behalf of the account.
-
-For more detailed specifications of transaction flows, see the [ERC-6900 spec](https://eips.ethereum.org/EIPS/eip-6900).