7963
Timur Badretdinov
@destiner.eth #7963
head of optics @scope
12560 Follower 178 Following
Made a smart account module to automatically renew ENS names.
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
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
this week i shipped a plugin to token-gate the smart accounts
https://github.com/Destiner/lil-modules
https://github.com/Destiner/lil-modules
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
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
(quoting bc not a member)
this is a hard problem, and i don't think any simple solution would fix it
warpcast needs to support:
1. users with no FC, no wallet
2. users with no FC, but with wallet
3. users with FC and a wallet
(FC = active FC account)
this inevitably creates tension:
1. on the UI level, you will need to branch out based on the user initial state
2. somehow you need to onboard users with no FC and no wallet while getting rid of the local mnemonic in the WC app
you can pick an embedded wallet provider, but then every FC app needs to use the same one (bad vendor lock-in)
it's possible to use a passkey backend as @stephancill suggests, but that wallet will be tied to the merkle backend forever PLUS merkle needs to build a wallet around it.
if you doesn't want to build a wallet, but still want to onboard walletless users, the only choice IMO is to outsource that part to wallet apps.
this is a hard problem, and i don't think any simple solution would fix it
warpcast needs to support:
1. users with no FC, no wallet
2. users with no FC, but with wallet
3. users with FC and a wallet
(FC = active FC account)
this inevitably creates tension:
1. on the UI level, you will need to branch out based on the user initial state
2. somehow you need to onboard users with no FC and no wallet while getting rid of the local mnemonic in the WC app
you can pick an embedded wallet provider, but then every FC app needs to use the same one (bad vendor lock-in)
it's possible to use a passkey backend as @stephancill suggests, but that wallet will be tied to the merkle backend forever PLUS merkle needs to build a wallet around it.
if you doesn't want to build a wallet, but still want to onboard walletless users, the only choice IMO is to outsource that part to wallet apps.
did a glowup for the personal website as i plan to post a bit
typography is hugely inspired by some of my favorite tech blogs
typography is hugely inspired by some of my favorite tech blogs
this week i shipped whatsabi integration to provide ABI decoding for unverified contracts
looks like a good time to switch to an ENS username
gradually adding support for unverified contracts, starting with whatsabi integration
Added whatsabi support for unverified contracts
Starting with function sigs (including the internal calls), soon adding events, and more later.
Below is an example of a decoded call that is not verified anywhere.
s/o to @shazow.eth for making such a great lib
Starting with function sigs (including the internal calls), soon adding events, and more later.
Below is an example of a decoded call that is not verified anywhere.
s/o to @shazow.eth for making such a great lib
this is the first time i could figure out how to claim moxie lol
this week i've been working on making /scope more human-readable
contructor args, function names, internal calls (incl. the output!), and reverts are now decoded
contructor args, function names, internal calls (incl. the output!), and reverts are now decoded
Waitlists for new Raycast apps
— Windows 👉 raycast.com/windows
— iOS 👉 raycast.com/ios
First come, first served
— Windows 👉 raycast.com/windows
— iOS 👉 raycast.com/ios
First come, first served
i wonder if anybody ever used those
𝘯𝘦𝘸 𝘪𝘯 𝘴𝘤𝘰𝘱𝘦: 𝘴𝘵𝘢𝘵𝘦 𝘥𝘪𝘧𝘧 𝘵𝘳𝘢𝘤𝘪𝘯𝘨
see balance, code, and storage changes for any transaction
see balance, code, and storage changes for any transaction
me: i love this font, i wonder which one is it
font: .AppleSystemUIFont 💀
font: .AppleSystemUIFont 💀
imagine using this to read tuple values
i've never used solana, i've never built on solana, and probably never will
yet i don't have any bad feelings about it
those constant ETH vs SOL "debates" between the same 100 ppl to win over the same 10k users are pathetic
crypto is default dead anyway, go build something useful
yet i don't have any bad feelings about it
those constant ETH vs SOL "debates" between the same 100 ppl to win over the same 10k users are pathetic
crypto is default dead anyway, go build something useful
if you work with internal calls, scope have recently became much more useful for that (and will become even more useful soon 🤫)
shipped a couple improvements to the trace view
1. showing revert type (failed / out of gas) on hover
2. subtree folding
3. expand call details on click
really love how this part of the app turned out!
1. showing revert type (failed / out of gas) on hover
2. subtree folding
3. expand call details on click
really love how this part of the app turned out!
while we're at it, added revert sources for UserOps
also shows when the UserOp is failed due to being out of gas
also shows when the UserOp is failed due to being out of gas