tate pfp

tate

@taytems.eth

154 Following
161 Followers
tate pfp
tate
@taytems.eth
meow meow meow meow only for 4 hours meow meow meow now on zora meow meow meow meow meow meow 4 HOURS!!! ZORA!!!!!!!!!! MEOW MEOW MEOW MEOW MEOW MEOW https://zora.co/collect/zora:0xa4c62207fa22f6315cbb8973c0c2cc275a63fc82/1
0 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
yep, in newer viem functions this is handled natively though
0 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
wip but made this https://github.com/ensdomains/hardhat-chai-matchers-viem
0 reply
0 recast
3 reactions
tate pfp
tate
@taytems.eth
will fix this, but you can clear your browser cache and it’ll work
2 replies
0 recast
1 reaction
tate pfp
tate
@taytems.eth
testing https://feat-farcaster-frame.ens-app-v3.pages.dev/nick.eth
0 reply
1 recast
9 reactions
tate pfp
tate
@taytems.eth
hmmmm... https://github.com/ensdomains/ens-app-v3/pull/703
1 reply
2 recasts
9 reactions
tate pfp
tate
@taytems.eth
can't give out too much alpha, but just to clarify: - the ENS *registry* is the spearhead of the ENS protocol in a single contract (owner/resolver) - the .eth *registrar* manages .eth registrations and *uses* the ENS registry to assign ownership they are different things
1 reply
0 recast
1 reaction
tate pfp
tate
@taytems.eth
registry itself will always be on L1 - .eth registrations aren’t built-in to the registry
1 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
to bring .eth to the masses, registration can’t stay on mainnet :)
1 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
as for bridging solutions to actually manage a name entirely on L2, with the current registry design it pretty much requires a workaround of some kind rather than being native to the protocol, which is something that we didn’t want to do, and are now tackling the core issue of
1 reply
0 recast
1 reaction
tate pfp
tate
@taytems.eth
the bull run has been unfortunate timing because most of our L2 scaling solutions are just now becoming ready for production, so ENS has felt inaccessible for many, especially from the ENS app
1 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
we have been progressing with ENS support on L2 continuously for years, things like CCIP-read, EVMGateway, L2 reverse registrar, etc, are all built and part of the L2 roadmap
1 reply
0 recast
1 reaction
tate pfp
tate
@taytems.eth
there has been an org-wide shift in focus entirely towards ENS on L2s very recently - we aren’t just exploring, we’re executing
1 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
cooking
1 reply
0 recast
2 reactions
tate pfp
tate
@taytems.eth
yep
0 reply
0 recast
1 reaction
tate pfp
tate
@taytems.eth
depends on what that support looks like to you. you can already use tanstack query alongside wagmi’s config for any viem-compatible functions.
1 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
registering an ens name still requires mainnet interaction for now. there are certain gas savings that could be had by creating a registration aggregator on L2, but nowhere near the savings of other L1 => L2 comparisons
0 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
fuck
0 reply
0 recast
0 reaction
tate pfp
tate
@taytems.eth
don’t actually do that, there is no way chatgpt can correctly rewrite this lib in rust what’s your context/use-case? might be able to make this happen
2 replies
0 recast
0 reaction
tate pfp
tate
@taytems.eth
it would be useful for apps that explicitly intend on resolving FIDs, yes. but there is no ENS spec for resolving something like an FID, so it couldn't be builtin to libraries like ethers unless there was an exemption for it.
0 reply
0 recast
0 reaction