Tony D’Addeo
@deodad
ditching wallet_switchEthereumChain 🔚 the stateful model of wallet connections where a wallet is connected to an application on a single chain feels broken wallets are moving towards programmatic switching and displaying all assets for all chains all the time which delivery a much better UX applications are moving towards using their own Ethereum RPC providers for public rpc requests and are only sending actions that require a signature to the wallet given this can we get rid of `wallet_switchEthereumChain` entirely and specify the chain on individuals requests like `eth_sendTransaction`? it's a common stumbling block for devs and adds a cognitive overhead since transactions needs to be wrapped in logic to inspect the current chain and switch
5 replies
5 recasts
32 reactions
Darryl Yeo 🛠️
@darrylyeo
This seems like a behavior /walletbeat ought to track. Under the Ecosystem category perhaps. cc @polymutex.eth
1 reply
0 recast
1 reaction
polymutex
@polymutex.eth
This is a real UX problem for sure, but since solving it requires frontend/wallet cooperation, it requires standardization before Walletbeat can track it in a productive way.
1 reply
0 recast
1 reaction
Darryl Yeo 🛠️
@darrylyeo
I’m most curious about whether upon receiving `eth_sendTransaction` with a supported chain ID different from the “current chain ID”, wallets: • error • ignore the specified chain ID and sign the transaction with the “current chain ID” instead • accept the tx quietly without changing the “current chain ID” • accept the tx and also change / announce the new “current chain ID” as if they had also received `wallet_switchEthereumChain` / `wallet_updateEthereumChain`
2 replies
0 recast
1 reaction
