Hi @pedrouid I am not against the proposal by itself. I think this is a great addition and I am myself building an application that would benefit from it. I am just against the idea of letting the applications provide parameters that could trick users.
the Wallet can query ‘eth_chainId’ and ‘net_version’, through the rpc url, verify the respective provided values.
My concern was about the network name, not the chainId. The chainId will restrict what tx is possible thanks to chainId replay protection. But if a name like “rinkeby testnet” is presented, the user might not read that the chainId used is actually 1 (mainnet). If the wallet can verify the name is valid, it could have provided it in the first place, without the need for the application to provide it. Hence why I think the name should not be provided by the application and the same apply for nativeCurrency
But this is an ERC, it’s a coordination mechanism between projects to expand the scope of what’s possible today yet still completepy optional for projects to adopt.
The fact that it is an ERC does not change the fact that as it stands, the proposal open up security issues.
the Wallet could query the chainId.network for the name and nativeCurrency fields and use those instead if present.
chainid.network could be compromised. We surely do not want the security of the user’s wallet to depend on it.
But if your wallet really want to do that, then we do not need the parameters (nativeCurrency, name) to be provided by the application then. The chainID would be sufficient for the wallet to fetch the rest via that mechanism.
rpcUrl would still be needed though for wallets that want to support unknown network.
So if we want to let application provide their own rpc URL and the chainID is unknown to the wallet itself, I would prescribe in the proposal that such wallet need to show a warning that the user is connecting to an unknown network and they should verify the chainID.