Discussing all things related to account abstraction on Ethereum, including     - EIPs / ERCs 
- Smart account architecture 
and more!

Main

Ethereum Account Abstraction

Really excellent guide to upgradable smart accounts and how they play with 7702 by @horsefacts.eth

I'm eth newbie..just learning
(working on @farcaster)

terminally.online

Really excellent guide to upgradable smart accounts and how they play with 7702 by @horsefacts.eth  

https://warpcast.notion.site/Account-Upgradeability-Deep-Dive-Public-1976a6c0c10180c0a4f8cb592830a69e

Maybe a stupid question: can a smart account change its implementation using 7702?

Will it eventually be possible to prevent an EOA that was upgraded to a smart account via 7702 from signing transactions for the account?

Etherspot’s Skandha Bundler supports EntryPoint v0.8, delivering EIP-7702 authorization, ERC-712 signatures, and optimized gas usage. 

Multi-chain ready across #Ethereum, #Polygon, and more with top-tier Account Abstraction. 

Read more 👇

Etherspot’s Skandha Bundler supports EntryPoint v0.8, delivering EIP-7702 authorization, ERC-712 signatures, and optimized gas usage. 

Multi-chain ready across #Ethereum, #Polygon, and more with top-tier Account Abstraction. 

Read more 👇
https://go.etherspot.io/PvVlJht

Has there been any proposal for a standard like DMARC to validate that transactions that appear to be "from" an address due to event logs actually are? Seems like a very similar problem to domain spoofing and related to AA since transactions are submitted by a relayer or bundler.

I’m becoming more and more convinced of the fat wallet thesis 

Every app can’t be responsible for reconciling user funds (across chains!) to make things happen

App should ask the wallet if the user can get enough of a token to do a thing and then the wallet should reconcile funds before doing the thing

What is the consensus on EIP-7702? Is it going to be another small stepping stone ala 4337 or will there be big immediate UX improvements this time?

it's pretty obvious that the endgame for crypto wallets is an OS-level wallet that gives you apple pay UX

but i think the standard pattern will look something like per-app sub accounts that can pull in liquidity from the main wallet and give you embedded wallet ux with easy asset management across all apps

I created a TS library for sending ERC-4337 user operations, currently supporting Kernel and Nexus, designed to work with ethers.js. Feedback is welcome!
https://github.com/ethaccount/sendop

Solidity v0.8.29 includes syntax for relocating a contract's storage variables to an arbitrary location. This is necessary to make EIP7702 secure. Put together a quick thread that makes clear why this is the case: https://x.com/0xEricBrown/status/1900189049026998457

https://warpcast.com/ericbrown.eth/0xdb90a73f

Excited to contribute to the public good space with the Mobile Wallet Protocol in Unity

A protocol using the previous work from Coinbase now also available for games! Secure e2e communication between wallets and games

(Soon) Token approvals no more

Patiently waiting for EIP-7702

I'd like to see more sophisticated rate-limiting features on Safe and competing multisig wallets. Is it possible via transaction guards? How can non-coder users access it?

So, for example:

- Can only send $10,000 via the Uniswap contract per 24 hours
- Can only send $1,000 to address X per 1 hour

Nothing else can be sent from the wallet. Changing these requires X/Y multisig permissions, and takes 7 days to execute.

Just an example, but the point is, the user can customise as per their needs. Rationale: User doesn't lose everything in one go if hacked - there's time and possibility to fix the situation.

Great read

I tried to to implement smart wallet session keys in my app when they first released them - it was confusing, intimidating, and felt pretty sketchy 

Sub accounts might just work.

Great read

I tried to to implement smart wallet session keys in my app when they first released them - it was confusing, intimidating, and felt pretty sketchy 

Sub accounts might just work.

https://blog.base.dev/subaccounts