abstractooor

@konrad

129 Following

171 Followers

Kurt pfp

@kurtlarsen.eth

Onchain permissions for EOAs using Smart Sessions and EIP-7702

0 reply

2 recasts

5 reactions

Kurt pfp

@kurtlarsen.eth

Introducing Rhinestone Protocol 1.0 🧩 The first smart account interoperability protocol Transforming smart accounts into the next open platform, aggregating and unifying the account stack to maximize distribution for devs. The foundations for the account-centric dev platform 🚀 For the full write up: https://blog.rhinestone.wtf/rhinestone-protocol-1-0-hits-mainnet-695469dce425 For the summary: https://x.com/rhinestonewtf/status/1851277911363633506

0 reply

3 recasts

7 reactions

Timur Badretdinov pfp

Timur Badretdinov

Introducing Token Validator An ERC-7579 validator that gates access to a smart account based on the token balance. Supports ERC20/ERC721/ERC1155 tokens, custom minimum balance, limiting to specific tokend IDs, and N-of-X multisig schemes. https://github.com/Destiner/lil-modules/tree/main/src/TokenValidator

1 reply

1 recast

6 reactions

abstractooor pfp

tbh I'm not familiar enough with the zk side but def feels feasible on the smart contract/module side

0 reply

0 recast

1 reaction

Timur Badretdinov pfp

Timur Badretdinov

I made an ENS Renewals module. It is an executor module that automatically renews ENS domains owned by the smart account. https://github.com/Destiner/lil-modules/tree/main/src/ENSRenewal

1 reply

5 recasts

17 reactions

Timur Badretdinov pfp

Timur Badretdinov

breaking down the "userop by eoa" demo: 1) signing & sending the authorization 2) initializing the zerodev kernel account 3) sending the userop

2 replies

3 recasts

11 reactions

Timur Badretdinov pfp

Timur Badretdinov

shared some learnings on making erc7579 validators with @rhinestone modulekit https://destiner.io/blog/post/erc7579-validators-with-modulekit/

0 reply

2 recasts

5 reactions

abstractooor pfp

an account can just implement a 712 envelope over the userOp or userOp hash - 4337 is agnostic to how this happens

1 reply

0 recast

1 reaction

Rhinestone pfp

⚡Funding Secured! ⚡ We’ve raised $5M, led by @1kxnetwork and with participation from @coinfund-io @latticefund Heartcore Circle @alchemyplatform @zksync and @buildoncyber Transforming smart accounts into a platform for open innovation 🚀

1 reply

3 recasts

10 reactions

Timur Badretdinov pfp

Timur Badretdinov

introducing 𝘴𝘤𝘰𝘱𝘦 the block explorer for account abstraction ∗ first-class UserOp support ∗ account labels ∗ contract search ∗ keyboard-first UI live at https://scope.sh

9 replies

10 recasts

57 reactions

Stephen Gordon pfp

ERC 6900 vs 7579 A debate from EthCC with @noam from Alchemy and @konrad from Rhinestone https://ethcc.io/archive/The-abstracted-wars-6900-VS-7579

0 reply

1 recast

1 reaction

abstractooor pfp

I think that would depend on the implementations/access control of the executors. Another solution would be to just do a batched call from the account to first call executor1 then executor2. Would that work in this case?

0 reply

0 recast

0 reaction

abstractooor pfp

imo something like ERC-7555 to port embedded wallets across apps

0 reply

0 recast

1 reaction

abstractooor pfp

imo 7212 was never that pressing for rollups since the execution cost was already quite cheap

0 reply

0 recast

1 reaction

abstractooor pfp

wasnt it relatively cheaper pre-4844 since now execution gas is a higher percentage of total gas on L2s?

1 reply

0 recast

0 reaction

abstractooor pfp

yeah, there are a few open questions such as around in protocol revocability that people disagree on but I think the spec is getting there. Yeah, one tx could drain your wallet, but this is a property of any smart account. However, you can use modules to make your account more secure and protect yourself from that

0 reply

0 recast

1 reaction

abstractooor pfp

EIP-7702 to be included in Pectra and will bring smart accounts to any EOA user!!!

1 reply

1 recast

7 reactions

KS pfp

Seems about right imo

1 reply

2 recasts

3 reactions

abstractooor pfp

- ... of different module features this means that a lot of features are just much harder to build if not impossible

0 reply

0 recast

1 reaction

abstractooor pfp

that only gives you a subset of the features of modular accounts though. you dont get: - complex hook behavior (due to 4337 restrictions in validation) - fallbacks for future compatibility (eg how safe can be used with 4337) - customisable execution logic (eg output of function is input to next) - easy composability

1 reply

0 recast

1 reaction