add convenience method for checking if a contract is deployed
See original GitHub issueconst someContract = new ethers.Contract( ... )
const isDeployed = await someContract.isDeployed()
if (!isDeployed) {
// deploy it
}
// continue
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (1 by maintainers)
Top Results From Across the Web
How To Deploy And Verify A Smart Contract From Remix
Remix IDE is a convenient tool for building and testing your solidity smart contracts online. This short tutorial will explain how we can...
Read more >Deploying your first smart contract - ethereum.org
Once you are on the "deploy and run" transactions screen, double check that your contract name appears and click on Deploy.
Read more >Creating and Deploying a Contract - Remix's documentation!
The transaction is created which deploys the instance of testContract . In a “normal” blockchain, you would have to wait for the transaction...
Read more >How to create and deploy smart contracts on the NEAR ...
Developers and users prefer NEAR Protocol because of its convenient user ... our configuration while deploying, testing and calling the smart contract.
Read more >How to develop, test, and deploy smart contracts using Ganache
Managing smart contracts is an important job of a blockchain developer, and this tutorial explains how to get started with them.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I don’t really see much value in an
.isContract
method, since it is literally just doing((await provider.getCode(address)) === "0x")
. It seems simple enough and I could imagine someone expecting the call to verify the bytecode matches the contract bytecode, which a contract doesn’t have. I have considered a similar thing for the contract factory, but it is not reliable, since the initcode is what the Factory has, not the runtime, and since the initcode is executed there is no way to verify that it is correct (see halting problem 😉).So, I would think in many cases people would care about what the bytecode is, not that it simple exists and otherwise it is a very simple call to do yourself. The vast majority of use-cases does not need to check either, since the a contract is generally long-lived and deployed long before interacting with it, especially customers.
If this is for testing, the ContractFactory adds the
.deployTrasaction
on the Contract, so it is easy toawait contract.deployTransaction.wait()
, which also throws if the contract failed to deploy. So, it should almost never be the case you have a contract connected to an unknown-to-be-deployed contract, unless you have tests running across multiple processes, which sounds painful… 😒If you are looking for deterministic deployments though, you might be interested in rooted or wisps.
Does that all make sense?
@ricmoo, I do have usage scenario where the deployment of the contract are completely separated from where it is used(say multi-node scale out situation), thus the .wait().then() style is rarely used. So logical .isContract(someAddress) of some form is used a lot. Though I am with you that a thin wrapper of .getCode() is probably not worth to be added as a generic library feature. It can be easily implemented via HOF or mixin for those who prefers it.