You're getting an overflow error, because javascript can't represent this number with enough accuracy. Even if you were able to convert it to a number, comparing it with any other would not be reliable, because of the imprecision.
That is actually exactly what BigNumbers are for..
So instead of converting it and comparing it, use BigNumber's comparison operators: https://docs.ethers.io/v5/api/utils/bignumber/
You can use:
a.lt(b)
a.lte(b)
as an example
- Can you control the owner address of the contract when deploying?
await ethers.getSigners();
, returns an array of signers, by default when deploying if you're not specifying any signer. It uses index[0] of ethers.getSigners();
- How do you go about setting that?
You can call functions using other signers
(accounts / wallets):
await yourContract.connect(signer[index]).yourFunction();
- The address you want to use as the owner must be available on the network your deploying to?
All addresses across all EVM compatible chains (Ethereum Virtual Machine) so you can use for example your MetaMask to interact with any other EVM-compatible network using the same address (so same private key).
- What about local development on the hardhat network?
theoretically, you can use the wallet you're using on your local to deploy on mainnet.
- I've seen the docs about calling contract functions after you deploy
using the hardhat console (instantiating a factory, await calls to a
function, etc.), is this the "standard" way to call contract
functions such as administrative onlyOwner functions like withdraw()
or pause(), etc.? Is this approach acceptable for mainnet?
Hardhat is a development environment tool for compiling, deploying, testing, and debugging your Ethereum software. You can interact with your smart contract using the hardhat console, using scripts (e.g, web3.js ethers.js, etc), CLI, remix, metamask, etherscan, etc. There is no standard, for this.
You can deploy on testnet first to test, if it works on testnet it'll work on mainnet
Best Answer
There are two relevant RPC methods here:
evm_increaseTime
andevm_setNextBlockTimestamp
. In both cases, they affect the next block but don't mine one.evm_increaseTime
receives a number of seconds that will be added to the timestamp of the latest block.evm_setNextBlockTimestamp
receives an absolute UNIX timestamp (again, in seconds), and so it's not affected by the current block.Examples
evm_increaseTime
evm_setNextBlockTimestamp
Keep in mind that Hardhat Network validates that the new timestamp is bigger than the previous one, so you can't send any value.