Content pfp
Content
@
https://ethereum.org
0 reply
0 recast
0 reaction

✳️ dcposch pfp
✳️ dcposch
@dcposch.eth
Two UX Original Sins Holding Ethereum Back 1. Hex addresses 2. Connect Wallet no mass adoption till we we submerge both (they'll live on, just not user-facing) why? (1/3)
11 replies
12 recasts
92 reactions

✳️ dcposch pfp
✳️ dcposch
@dcposch.eth
ADDRESSES - NO VALIDATION. you can accidentally send $10k to the USDC contract address--burnt--and UIs won't warn you. conversely, no way to prevent arbitrary inbound. every address is an everything bagel! so for now, every wallet must support any asset arriving on any chain. explain this to your parents (h/t @phil):
2 replies
0 recast
6 reactions

✳️ dcposch pfp
✳️ dcposch
@dcposch.eth
CONNECT WALLET - website proposes arbitrary transactions and signatures. user eyeballs and clicks "accept" or "reject". fundamentally impossible to make safe in general case, even with simulation. devtool UX in practice HOW TO FIX?
2 replies
0 recast
7 reactions

✳️ dcposch pfp
✳️ dcposch
@dcposch.eth
Our best guess: 1. L2 ENS / FID. give everyone a name (*) 2. INBOX. handle "any asset, any chain" without complicating the UI 3. TRUSTED CONTRACTS. Daimo, for example, uses specific, well-understood contracts. nice UI, no "lose money" button = happy users (**)
2 replies
2 recasts
6 reactions

✳️ dcposch pfp
✳️ dcposch
@dcposch.eth
(*) - I'd love to see a base58 address format that includes chainID. shorter, better. (**) - we can still do a lot (swaps, fast cross chain sends, etc). can even add subaccounts for arbitrary actions with risk limited to the subaccount. more soon ⚡ i️f this sounds interesting to you, DM me. we're hiring. /end
1 reply
0 recast
5 reactions

Daniel Nordh pfp
Daniel Nordh
@dnordh
Agree, chain ID included in address would solve a lot of user errors.
0 reply
0 recast
0 reaction