>npx hardhat run --network mainnet scripts/deploy.js
network: mainnet
Deploying CanYourPet...
\node_modules\@ethersproject\logger\src.ts\index.ts:225
const error: any = new Error(message);
^
Error: insufficient funds for intrinsic transaction cost (error={"name":"ProviderError","code":-32000,"_isProviderError":true}, method="sendTransaction", transaction=undefined, code=INSUFFICIENT_FUNDS, version=providers/5.5.0)
at Logger.makeError (\node_modules\@ethersproject\logger\src.ts\index.ts:225:28)
at Logger.throwError (\node_modules\@ethersproject\logger\src.ts\index.ts:237:20)
at checkError (\node_modules\@ethersproject\providers\src.ts\json-rpc-provider.ts:53:16)
at \node_modules\@ethersproject\providers\src.ts\json-rpc-provider.ts:215:24
at processTicksAndRejections (node:internal/process/task_queues:96:5)
>npx hardhat run --network mainnet scripts/deploy.js
network: mainnet
Deploying CanYourPet...
\node_modules\@openzeppelin\upgrades-core\src\deployment.ts:70
throw new TransactionMinedTimeout(deployment);
^
Error: Timed out waiting for transaction 0xdb16512986f4b9abf14e2e0110cb02e112ad96260908abb23a95b61459ffa515
at waitAndValidateDeployment (\node_modules\@openzeppelin\upgrades-core\src\deployment.ts:70:15)
at fetchOrDeployGeneric (\node_modules\@openzeppelin\upgrades-core\src\impl-store.ts:43:5)
at deployImpl (\node_modules\@openzeppelin\hardhat-upgrades\src\utils\deploy-impl.ts:60:16)
at Proxy.deployProxy (\node_modules\@openzeppelin\hardhat-upgrades\src\deploy-proxy.ts:35:28)
at main (\scripts\deploy.js:18:14)
[Thrid try]
modify pollTimeout
deployment.ts
const pollTimeout = 600e3//60e3;
>npx hardhat run --network mainnet scripts/deploy.js
network: mainnet
Deploying CanYourPet...
\node_modules\@openzeppelin\upgrades-core\src\deployment.ts:43
throw new InvalidDeployment(cached);
^
Error: No contract at address 0x52c692a5A4cf508393382C6DDc28529afc185D46 (Removed from manifest)
at resumeOrDeploy (\node_modules\@openzeppelin\upgrades-core\src\deployment.ts:43:13)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at \node_modules\@openzeppelin\upgrades-core\src\impl-store.ts:34:23
at Manifest.lockedRun (\node_modules\@openzeppelin\upgrades-core\src\manifest.ts:118:14)
at fetchOrDeployGeneric (\node_modules\@openzeppelin\upgrades-core\src\impl-store.ts:26:24)
at deployImpl (\node_modules\@openzeppelin\hardhat-upgrades\src\utils\deploy-impl.ts:60:16)
at Proxy.deployProxy (\node_modules\@openzeppelin\hardhat-upgrades\src\deploy-proxy.ts:35:28)
at main (\scripts\deploy.js:18:14)
Hey, I've got the same problem with Polygon Mumbai testnet, but everything is fine on Ropsten. I investigated a bit and it looks like it computes the resulting contract address wrong for some reason, so it actually deploys contract, but writes the wrong address to the manifest and then cannot validate the implementation there.
The address of a contract depends on the sender and it's nonce (and they are queried from the deploy tx) , and since the other networks are fine, I'd suggest there is a bug that returns the wrong value for some brief period of time after transaction was submitted. And I'd suggest that it's an address and not nonce (or both), since:
I tried generating a lot of contract addresses for my account with different nonces and the addresses Upgrades got was not there.
On some of the addresses Upgrades got I actually found a someone else's contract.
I've also found a workaround for this:
You just need to change the address to the real one (from explorer) in the manifest - .openzeppelin/{network}.json
To do this you can just copy the manifest contents while it still in progress (it takes quite some time between implementation deployment and the error) before the deployed implementation manifests gets deleted and then, after the error paste it back and change the address.
Or I guess you can get implementation manifest from other network where it works and change tx and address as well.
I've managed to check. The lookup of transaction by hash returns "0x0000000000000000000000000000000000000000" as "from" for a brief period after sending it. That's what causes the issue
Same Issue here using @openzeppelin/hardhat-upgrades 1.12.0. @Denis_Baturin's solution works for me. Actually had to repeat the process, one for the implementation and another for the proxy admin. I'd be happy to contribute with a PR for the fix if someone can guide me.
@madoke We will look into this further but any PRs would be welcome. You can take a look at the contributing guide.
@Scaryama@Denis_Baturin@madoke As a workaround for now, if you are using Infura, can you try Alchemy (or vice versa) and see if it makes any difference?