TLDR; This is a call from SCW, where the SCW does two transactions. The first being approiving the USDC & then second is calling Socket's registery to bridge the token using the function outboundTransferTo. Transaction Flow: User op was forwarded using Stackup bundler Every userOp call starts with EntryPoint - 0x5ff137d4b0fdcd49dca30c7cf57e578a026d2789 Smart Contract wallet address - 0x3a1ee02cf59821e4d8264a6ddfae970a99da25d5 SCW looks like an implementation of https://ethereum-magicians.org/t/erc-6900-modular-smart-contract-accounts-and-plugins/13885/20 This is mostly popularised by zeroDev protocol - https://mirror.xyz/konradkopp.eth/7Q3TrMFgx2VbZRKa7UEaisIMjimpMABiqGYo00T9egA Codebase - https://github.com/zerodevapp/kernel/blob/main/src/Kernel.sol

Project Summary I initially aimed to develop the proposed 4337 wallet, a browser extension wallet composed of three modules: extension, auth, and recovery. The aim was to support multiple SCW implementations by exposing the API to allow users to select the SCW implementation they prefer. However, the task turned out to be monumental, and some priorities needed to be set for EthDenver. Thus, we realigned our goals and came up with the following: Deprioritize the secure module for safe execution environments for multiple wallets. Finish onboarding with a custom screen for SCW to take user input. Inject the Web3Provider. Create a primary transaction confirmation screen that developers can clone and customize. Write a README for users to clone the repo and develop. Clean up any leftover issues. Modify the 2fa extension demo.

This document highlight the list of ideas that are worth exploring for our startup - PROTON Writing style - challenge - poroblem statement people - target ussers outcome - measurable change in people's life Accounts for app chains

Hey everyone, hope you're all doing well! I have an update on the wallet development. Our goal has been redefined and we're now focusing on making the wallet forkable and customizable for SCW with support for custom onboarding and transaction inputs. Our aim is to have the plugin ready by EthDenver. Here's what we have planned so far: De-prioritize the secure module for a safe execution environment for multiple wallets (Jan 29th) Finish the onboarding with a custom screen for SCW to take user input (Jan 29th) Inject the Web3Provider (Feb 4th) Create a primary transaction confirmation screen that developers can clone and customize (Feb 7th) Write a Readme for users to clone the repo and develop (Feb 14th) Clean up any leftover issues (March 1st)

I have been continuing to work on my wallet extension and unfortunately, I have encountered a few blockers that I have not yet been able to solve. However, since my last update, I have become more interested in the possibility of using EigenLayer for account abstraction. Before delving into a potential solution, let's first review the current problems facing wallet development: Fragmentation of ownership, especially when funds are not available on a specific chain. The use of the same address across multiple chains, particularly on newer chains like Starknet and Zksync. Difficulty in creating similar features across different chains; for example, it can be challenging to write zk verifiers in Cairo. The significant development effort required for supporting multiple chains. It is important to note that any solution must prioritize

Hello everyone, I wanted to give you all an update on the progress I've been making with our chrome extension and the development of smart contract wallets (SCWs). In this update, I'm excited to share that I've successfully been able to inject a Web3Provider into the current tab using the content script of our chrome extension. One of the areas I've been focusing on is adding multiple chain support for our SCWs. After some research, I've determined that the keyring controller will still be active on a single chain, and whenever we change the chain in the App, we'll be creating a new different instance of the keyring controller for that specific chain. As that I was researching multi-chain support, I came across the issue of how to have the same address across multiple chains, and the challenges around managing changing of ownership across multiple chains. To address this, I've been exploring the use of EigenLayer. I've even written a blog post on this topic, which you can check out at https://mirror.xyz/plusminushalf.eth/hIrS59bVgHhnSCC9B9rp7XnGT-PBOCWPponWwEzKjsE. In this post, I'm exploring the idea of a separate chain for wallets to mitigate the account management problem.

I am facing an issue with injecting Buffer (Nodejs) polyfill into my vite project. I have hightlighted the issue with the crxjs team which I feel is the main reason for the issue - https://github.com/crxjs/chrome-extension-tools/issues/617. To move forward I have made the following changes in my node_modules: Added ability to auto-lock the keyring controller using chrome.alarms/ Created a simple Account, that could perform all the functions of an EOA. Explored other SCW design to incorporate manual inputs, wrote about potential life cycle when a custom input from a user in needed in a wallet's lifecycle - https://hackmd.io/@plusminushalf/wallet-life-cycle The orignal design of the extension was the the App would coordinate with background script using redux actions using webext-redux. Then background script will send communications to Sandbox environment running inside an iframe where SCW's implementation will be executed. The problem came when we need custom user inputs and we have to validate every custom user input before sending it to the SCW. If you checkout KeyringViewInputField type in the link above, it exposes a function isValid. Since the defination of this function is inside the sandbox environment, everytime a value had to be validated App had to fire a redux action which will call background script which will call the sandbox and then the validation data will be returned. Since it was not the most optimised way, I am working on a new structure where App & sandbox environment can safely interact with each other without the need of interaction with the background script. Created a demo wallet locally which will be accepting a user input while creating a new account.

Keyring Builder Every wallet must export a keyringBuilder. This function will be called and must return a keyring. Type of keyringBuilder is defined below: export type keyringBuilder = { (): Keyring; uid: string; }; uid is used as a global unique identifier for a keyringBuilder. For example a simple-account's keyringBuilder is described as: export const SimpleAccountKeyringBuilder = () => {

I finalised on the architecure while setting up the everything required for the wallet, you can read more about it here: https://hackmd.io/4CoD1N-sR0O16HhUL40YFQ I created a version of Keyring controller that will control all the keyrings of wallets. Every keyring by wallet must implement the following interface: export interface Keyring { type: string; serialize: () => Promise<object>; deserialize: (data: object) => Promise<void>; addAccounts: (numberOfAccounts?: number) => Promise<string[]>; getAccounts: () => Promise<string[]>; signTransaction: (

Project: Eth Keyring Controller Link: https://github.com/MetaMask/KeyringController ChatGPT Generated documentation The KeyringController is a class that manages keyrings (collections of keys) and their associated data. It allows users to create, import, export, and delete keyrings and keys, as well as lock and unlock the keyrings. The KeyringController uses the ObservableStore class to store data and the EventEmitter class to emit events when data is updated. It also uses the encryptor module to encrypt and decrypt data. The KeyringController constructor takes an options object as an argument with the following optional properties: initState: Initial state object for the observable store. keyringBuilders: An array of keyring builders to use for creating keyrings. The default keyring builders are SimpleKeyring and HdKeyring.

I started with the project at the repo - https://github.com/plusminushalf/epf-wallet I helped in mentoring people participating in EthIndia, we had a track specific for Account Abstraction & we saw 60+ project submissions. - https://twitter.com/plusminushalf/status/1599671432744951811 I explored SES for a secure environment to execute wallet specific implementation APIs - https://github.com/endojs/endo/tree/master/packages/ses SES depends on eval function, which is not exposed in the chrome extensions. The workaround that I have found is to run ses in an iframe & have the compatmentalised codebase in iframe instead. This could lead to iframes in popup, content as well as app. I am not sure of the performance hits that will happen due to this side effect. I am strugling with how to load the SCW implementation APIs dynamically with chrome extension manifest v3. v2 supports dynamic loading but it is supposed to be deprecated soon. I also have contributed to the EIP 4337 by improving the defination of preVerificationGas. A lot of people were asking questions about what it encapsulate, so an updated description was needed for that.

This document highlights the current challenges and possible solutions if we use Metamask Snaps to develop a 4337 wallet version. Sending transaction Currently, there is no way to intercept eth_sendTransaction. So if a Dapp initiates the RPC call, by default the call will always go through the Metamask EOA. Metamask does allow us to show any insights on the transaction by exposing the function onTransaction but neither can we stop the EOA transaction nor can we redirect it through the SCW. We can define a custom RPC method, Starknet's wallet snap also created a new method starkNet_sendTransaction. This means that Dapps will have to call this custom RPC method whenever they want to send transactions through the SCW implementation. This may not be ideal as this would restrict the usage of the SCW and require change on Dapp's end. Since Dapps will have to make changes in their codebase to batch transactions & use paymasters, it can be argued that we can expose a new RPC method using the Metamask snaps for sending transactions too. This though will decrease the usage of SCW for normal transactions but can increase its adoption slowly as Dapps start connecting paymasters or batching transactions like approval & deposit. Dapp specific paymasters

Abstract We are moving closer towards the finalisation of EIP-4337. A lot of effort by the core team has been put into designing the contracts, mempool, DOS protections etc. But the team haven't had time to properly support UserOps through one of the browser extension wallets. In this cohort, I intend to work on making a user-facing wallet which can then pave the way forward for the wallets in the Ethereum ecosystem. The larger goal is to test the eip enough and make it ready for everyday use. Once we get AAs into everyday use we can then easily work towards the depreciation of EOAs from the ecosystem. Objectives With this wallet I intend to achieve the following objectives: Ability to create a SCW Recover a SCW

Onboarding to a AA wallet has to be different from how we used to onboard the users on an EOA. Let’s break the problem into three sets of problems: Creating a new wallet Importing a wallet Using hardware wallet to sign the transactions of AA. Creating a new wallet The easiest way for users to store private keys is through seed phrases. The hierarchical relation between a seed phrase & a private key is that a seed phrase can generate multiple private keys using Hierarchal Deterministic (HD) Wallet.[1] The current implementation of the AA wallet in SimpleWalletApi allows us to create multiple AA wallets corresponding to a single private key.[2]