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
Darryl Yeo 🛠️
@darrylyeo
Hmm, EIP-1637 seemed like a pretty reasonable proposal. Wonder why it never caught on or got revisited. cc @pedrouid https://github.com/ethereum/EIPs/issues/1637 https://docs.metamask.io/wallet/how-to/send-transactions/#chain-id
1 reply
0 recast
1 reaction
Pedro Gomes
@pedrouid
Although it was an optional param… there was a lot of resistance to change an existing interface Fortunately we no longer need ERC-1637 because this was solved with the new ERC-5792 authored by @lsr
1 reply
1 recast
2 reactions
Darryl Yeo 🛠️
@darrylyeo
Oh neat. This would be a good list to incorporate. https://www.eip5792.xyz/ecosystem/wallets
1 reply
0 recast
0 reaction
