Convert v5 signer to v6 signer

[Hugo0]

Ethers Version

6.6.2 & 5.7.2

Search Terms

eip1993, ethers v5, ethers v6

Describe the Problem

I need to convert an ethers v5 signer to and ethers v6 signer. Would like some guidance on how to do this.

if it's an EOA signer, it's relatively simple:

// if EOA wallet, just get the private key and provider and instantiate a new ethers v6 wallet
// signer is ethers v5 object
  if (signer.privateKey) {
    const provider = signer.provider;
    const privateKey = signer.privateKey;
    const wallet = new ethers.Wallet(privateKey, provider);
    return wallet;
  }

However, i'm a little bit lost as to how exactly I should deal with JsonRpcSigners & more. Any tips?

Environment

Ethereum (mainnet/ropsten/rinkeby/goerli), node.js (v12 or newer), Browser (Chrome, Safari, etc), React Native/Expo/JavaScriptCore

[Hugo0]

@ricmoo Could I get some guidance on this? Is this feasible, to take in an ethers v5 Signer object and 1-1 map it to an ethers v6 Signer object?

My stopgap solution is to have 2 versions of the sdk, one for ethers v5 and one for ethers v6, but it's quite painful to maintain.

Any other ideas highly welcome

[ricmoo]

Heya! Sorry, this fell off my radar.

When comparing the TypeScript type incompatibilities, what does it complain about? I think they should be mostly already compatible, except the _signTypedData became signTypedData and the getNonce should point to the getTransactionCount.

The other option you have is to sub-class the AbstractSigner which accepts an v5 Signer and just fill in the abstract methods to point to the equivalent methods?

Ideally more people would move to v6. Do you know of any hang ups? I can help anyone that needs migrating, especially frameworks and such. :)

[JADcooler]

Heya! Sorry, this fell off my radar.

When comparing the TypeScript type incompatibilities, what does it complain about? I think they should be mostly already compatible, except the _signTypedData became signTypedData and the getNonce should point to the getTransactionCount.

The other option you have is to sub-class the AbstractSigner which accepts an v5 Signer and just fill in the abstract methods to point to the equivalent methods?

Ideally more people would move to v6. Do you know of any hang ups? I can help anyone that needs migrating, especially frameworks and such. :)

The docs are the bottleneck in migrating :( even though ur probably doing a good job developing

[apuigsech]

I need to do exactly the same.

@Hugo0 did you make any progress?

[Hugo0]

@apuigsech nope, delayed the project and we just support ethersv5 for now. But these guys told me they did it (i haven't looked through their code though) https://github.com/0xsquid/squid-sdk

[yonathan9669]

Hey @ricmoo @chainlink/funtions-toolkit is still using v5 and I can't find a way to pass a v6 Signer and make it work on some of their functions.

So, I need to do the opposite thing. From v6 to v5.

code

ts error

runtime error

[Phoeni0x]

Hi @ricmoo, I am integrating Privy with EAS SDK, at the moment Privy generates ethersv5 signers and EAS SDK uses v6 internally to sign offchain attestations. What'd be your recommendation/guidance to migrate signers from v5->v6 in this case?

Heya! Sorry, this fell off my radar.

When comparing the TypeScript type incompatibilities, what does it complain about? I think they should be mostly already compatible, except the _signTypedData became signTypedData and the getNonce should point to the getTransactionCount.

The other option you have is to sub-class the AbstractSigner which accepts an v5 Signer and just fill in the abstract methods to point to the equivalent methods?

Ideally more people would move to v6. Do you know of any hang ups? I can help anyone that needs migrating, especially frameworks and such. :)

[Phoeni0x]

To quickly circumvent the issue for now I am using:

signer.signTypedData = function(params, types, signer) {
        return this._signTypedData(params, types, signer)
}

[Ahmedborwin]

@yonathan9669 Hey, I'm going through the same issue right now. Did you manage to find a solution?

[yonathan9669]

Hello, Yes I did. Let me point you right where I did the workaround. I'm sorry for the delayed response.

---

Here you will find the exact commit I made for it.

Please, notice I also modify my tsconfig.json in order to have a direct access to the ethers@v5 required for the workaround.

Here you have the relevant parts of the code.

import { Wallet, providers } from "ethers@v5";
...
export async function getManager(hre: HardhatRuntimeEnvironment) {
...

const { url, // This is the RPC URL from hardhat.config.ts ... } = await getNetworkConfig(hre);

// Workaround for the incompatibility between ethers v6 and v5. @chainlink/functions-toolkit is using ethers v5. const deployerPrivateKey = process.env.DEPLOYER_PRIVATE_KEY ?? "0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"; const provider = new providers.JsonRpcProvider(url); const signer = new Wallet(deployerPrivateKey, provider); // End of workaround. goal: ethers v5 Signer with the deployer private key using the hre network.

subscriptionManager = new SubscriptionManager({ signer, // Here is the signer I needed. ... });

... }