Open antondalgren opened 1 year ago
Although these methods shouldn't be used in production dapps in most cases, there are edge cases in which there are no alternatives to using these methods.
For example, in issue mentioned above (https://github.com/WalletConnect/walletconnect-monorepo/issues/1952), I use those methods simply to provide a general-purpose ethers.js Signer
wrapper for a WalletConnect session. The full Signer
spec requires these kinds of functions for a full implementation: (https://github.com/ethers-io/ethers.js/blob/ba967875f71019d367606f2b0bfae27879723a57/src.ts/providers/signer.ts#L124)
I believe that completely removing support for them at the API level is a damaging move to WalletConnect as a general-purpose toolkit.
The concerns for these methods can and should be acted upon at the wallet level with warnings to the user if a suspicious signature is being proposed.
It would be reasonable to remove the support for these methods (
eth_sign
,eth_signTransaction
) due to security reasons to not incentivise wallet developers and dApp developers to use these methods out in the wild. We must currently add exceptions to our supported list of methods to be able to test our wallet integration with the dApp.References:
eth_sign
https://twitter.com/CT_IOE/status/1534658825843683328eth_signTransaction
https://github.com/MetaMask/metamask-extension/issues/2506 https://github.com/MetaMask/metamask-extension/issues/3475An alternative would be to make it possible to select what methods you want to send in the sessionProposal from the
react-app
to the wallet.