jw 🦺 ERC6551 pfp

jw 🦺 ERC6551

@0xjw.eth

327 Following
226 Followers


BENNY G ✳️ pfp
BENNY G ✳️
@0xbg.eth
a few weeks ago we launched the closed beta of @perdotma in berlin. here's how it went... (stay to the end for an invite code):
1 reply
2 recasts
9 reactions

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Tried this (immediately firing a chainChanged event after approving the session), but Privy still requests a signature for the first chain in the optionalChains list (arbitrum). Is there a way to signal support for all optionalChains but have Privy choose the correct one for signing?
1 reply
0 recast
1 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
You can verify it is a TBA by computing the TBA address with the expected input values and comparing it with the actual address. The alternative would be to pre-compute the addresses for all/a subset of TBAs and index them
1 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
This is very cool!
0 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Very cool - had been wondering if there was an easy way to check for opcode support like this
0 reply
0 recast
2 reactions

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Excited to roll out cross-chain support for TBAs today! So many cool use cases to be built now that your NFT can do anything on any chain https://twitter.com/tokenbound_/status/1768323785739141449
0 reply
1 recast
2 reactions

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
That said, this approach is ultimately working around not being able to render an iframe
0 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Mostly (a) using dynamically generated SVGs because it's more convenient than rendering a png/jpeg.
1 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
This is very helpful, thank you!
0 reply
0 recast
1 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Nice!
0 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
That's awesome! Would love to contribute. Would be ideal if compatible with react + viem
1 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Big fan of callthis :) Mostly looking for a front end library I could include in projects that need an embedded tx builder interface
1 reply
0 recast
1 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
cc @shazow.eth
1 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Are there any good libraries for turning an ABI into a form?
1 reply
1 recast
2 reactions

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
cc @v
0 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Frame behavior question - it seems like the url included in the signed message when a button is clicked is always the original url of the frame, not the post_url. Is this expected? Is there any way to include the post_url in the signed data?
1 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Mina is the closest I've seen to this. Doesn't it use a curve-based signature scheme for accounts though? I'm wondering if replacing curve-based signature verification with hash-based proof verification might result in simpler / cheaper / faster proofs.
1 reply
0 recast
0 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
Is anyone working on zk-based consensus? Intuitively it seems like you could replace zk-unfriendly signatures in consensus algorithms with (recursive) proofs of pubkey = hash(privatekey, data) using a zk-friendly hash, which would enable much cheaper / faster proofs.
3 replies
1 recast
1 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
I don't see why not! Assuming @paragraph supports ERC-1271 signatures it should work with TBAs out of the box.
3 replies
0 recast
1 reaction

jw 🦺 ERC6551 pfp
jw 🦺 ERC6551
@0xjw.eth
ERC6551 accounts can execute operations (calls where msg.sender == account), but cannot originate transactions (calls where tx.origin == account). This is the same behavior as any other smart contract account.
1 reply
0 recast
3 reactions