Kurt

@kurtlarsen.eth

273 Following

319 Followers

Kurt pfp

@kurtlarsen.eth

This was meant to be a quote post. Seems you can’t quote post into a channel. Initial post below https://warpcast.com/v/0x0ceba636

0 reply

0 recast

1 reaction

Kurt pfp

@kurtlarsen.eth

This is an interesting perspective. I don’t think it needs to be an either or. The benefit of supporting EOA + 7702 is increased TAM for the developer. However, I would argue that there is no upside to giving new users an EOA + 7702, only downsides due to feature limitations and security. My recommendation would be to support a smart account that is 7702 compatible. Upgrade the existing EOA users and give the new users a full smart account.

7 replies

16 recasts

40 reactions

Kurt pfp

@kurtlarsen.eth

Yesterday, we announced the Resource Lock Hook for ERC-7579 smart accounts. This Hook Module enables any specialized execution layer to seamlessly integrate with ERC7579 accounts and execute any intent through a single signature. Launching Q1 2025, with more to come! https://x.com/rhinestonewtf/status/1869044965797773656

2 replies

1 recast

4 reactions

Kurt pfp

@kurtlarsen.eth

Thanks for hosting @reown @walletconnect The notion of the account-centric developer platform is only just starting to take off. ERC-7579 is the shared standard that will bring this to fruition. Rhinestone is a vehicle to accelerate it

0 reply

0 recast

5 reactions

Kurt pfp

@kurtlarsen.eth

Onchain permissions for EOAs using Smart Sessions and EIP-7702

0 reply

2 recasts

6 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

4 recasts

8 reactions

Kurt pfp

@kurtlarsen.eth

Disaster planning for your self-sovereign users? You need Social Recovery or the infamous Deadman Switch Both Smart Account features are part of our open-source Core Modules. Available to anyone and everyone building on Modular Smart Accounts. Check out our the guides ↓ Social Recovery https://docs.rhinestone.wtf/module-sdk/using-modules/social-recovery Deadman Switch https://docs.rhinestone.wtf/module-sdk/using-modules/deadman-switch

0 reply

0 recast

9 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

3 reactions

Kurt pfp

@kurtlarsen.eth

Hey Varun, We've done a lot of thinking about this at @rhinestone and it's formed the basis for a lot of the open source work we've done with Safe, zkSync, Biconomy, ZeroDev, OKX, and a number of others. The standard is called ERC-7579. This is a minimal standard for modular smart accounts. Modules are self-contained smart contracts that extend the functionality of a Smart Account. This will allow you to continue to support existing features (passkeys, gas abstraction, secure recovery mechanisms etc) but also provide new tools for the problems you raise. 1. If a user wants to change apps they can import the account and enable a new signer dedicated to that app or enable a session key to give the app scoped access. 2. No direct solution, but scoped executor modules and session keys can make this secure, whilst still open and programmable for applications. 3. Any developer can build a module, which under the right permissioning framework, can allow apps/users to extend the functionality of their account

0 reply

1 recast

2 reactions

Kurt pfp

@kurtlarsen.eth

ERC-7579. 35 modules, and we haven't even started! A slosh of compatible smart accounts inbound. erc7579.com/modules

1 reply

0 recast

9 reactions

Kurt pfp

@kurtlarsen.eth

Could definitely be a module. We have an executor that allows one account to pay for the gas of another account. This was mainly built for a sub account architecture but could extend to this fourth option with modification

0 reply

0 recast

1 reaction

Kurt pfp

@kurtlarsen.eth

0 reply

0 recast

0 reaction

Kurt pfp

@kurtlarsen.eth

0 reply

0 recast

0 reaction

Kurt pfp

@kurtlarsen.eth

0 reply

0 recast

0 reaction

Kurt pfp

@kurtlarsen.eth

0 reply

0 recast

0 reaction

Kurt pfp

@kurtlarsen.eth

I personally prefer the pain and angst of running my own bundler and payment. Plus permissionless.js is just too smooth and simple to implement. And your turn around times on questions/requests in our dedicated channel are too quick.

0 reply

2 recasts

2 reactions

Kurt pfp

@kurtlarsen.eth

0 reply

0 recast

0 reaction

Kurt pfp

@kurtlarsen.eth

Nice. Looking forward to playing around with the product

0 reply

0 recast

1 reaction

Kurt pfp

@kurtlarsen.eth

0 reply

0 recast

0 reaction

Kurt pfp

@kurtlarsen.eth

$Degen procured. Time to find out what all this tipping is about

0 reply

0 recast

0 reaction