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
33 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
