Content
@
0 reply
26 recasts
27 reactions
Dan Romero
@dwr.eth
Why don't ENS names work for sending with MetaMask Chrome extension on Base?
6 replies
1 recast
23 reactions
phil
@phil
https://docs.ens.domains/dapp-developer-guide/ens-l2-offchain#l2-resolver cc/ @greg
1 reply
0 recast
3 reactions
Dan Romero
@dwr.eth
@greg This is a good example of where ENS needs to be way more focused on execution vs. standards. Otherwise apps that make it easy to pay people will opt out of using ENS. :)
3 replies
1 recast
14 reactions
Jeff Lau
@jefflau.eth
If you mean, why aren’t we using the ethereum address? Account abstraction. Although I’m working on a default standard that would allow this to be set for EoAs.
1 reply
0 recast
1 reaction
jesse.base.eth 🔵
@jessepollak
can you say more?
1 reply
0 recast
0 reaction
Jeff Lau
@jefflau.eth
If the address isn’t an EoA we can’t guarantee the account exists on the L2. If it is an EoA though we could create a default address record that is signed by the EoA (guaranteeing it’s not an SCA) allowing it to be a fallback for all evm-based records. We could also do the same for a primary ens name default.
1 reply
0 recast
2 reactions
jesse.base.eth 🔵
@jessepollak
I feel like it's a step backwards to just solve this for EOAs. are you thinking about how to solve this for SCWs?
2 replies
0 recast
0 reaction
Jeff Lau
@jefflau.eth
Yes we are, but its a massive in flux problem that we internally refer to as the “l2 iceberg”
1 reply
0 recast
2 reactions
Jeff Lau
@jefflau.eth
Thinking about it now, we can just as easily allow defaults for SCW, but the user just needs to be deterministically deploying their SCW across different chains. And that's more a UX thing for wallets and SCWs to allow/enforce
0 reply
0 recast
0 reaction
