I have been working on ERC20 token development. My code is written using solidity and zeppelin frameworks.
So far I have used the test networks like Rinkeby, Ropsten to deploy and test all the ERC20 methods. Last night, I have to deploy the smart contract in the mainnet where 10000000 tokens had to be deployed but I deployed only 1000000 (missed a zero).
As it is deployed in the mainnet, mint is the only way to top up the initial amount instead of redeploying. Mint is achievable using remix by removing the internal keyword in the mint method. But it requires to redeploy the smart contract in order to use mint method, which customer would not agree to redo the same.
The only way I think is to use web3js API to achieve the same. But there are no content given in the web3js document to how to pragmatically mint (to top up the initial amount).
If any of you have faced a similar situation, please let me know how you tackled it.
Thanks,
Sriram
The mint using web3 would be just a call to the contract function just like from remix, nothing special. All you would have to do would be to call the function. But since this function internal you cannot call it directly not from remix, not from web3, not from any other library. To put it simply if you cannot call the function from remix you cannot do it from web3 either. Web3 offers nothing more than remix in terms access rights to the contract.
Related
I have deployed a contract on the BEP-20 network and now I don't need mint and owner address transfer functionality.
So I want to remove these options from the "write contract" options list.
If it is possible if yes then what can I do?
Smart contract bytecode is immutable. Assuming that your contract is not a proxy but a regular contract - you cannot change the already deployed code.
After you've made the changes in your local code, you'll need to recompile it, and deploy to a new address.
I am facing an odd case where I am calling a view method in a smart contract with the correct address and ABI but am getting a reversion from the contract itself when it's being called through a library such as web3 from a frontend web application.
However, when trying on remix for example, with the same contract and method and parameters and address, the method is working.
Can anyone provide some insight into this?
Had to use .call({from: userAddress}) instead of just .call()
I have my ERC1155 token contract deployed on Ethereum network
i want my token holders to make the token to 721 standard and burn the old tokens
how can i achieve that using a proxy contract
need some proper direction on this , thanks
So looking to migrate the OpenSea ERC1155 tokens to the new ERC721 tokens. The existing contract has 135 tokens.
a proxy contract won't let you do this migration for a couple of reasons, first a proxy contract just let you update the address of the contract where the actual logic is, but it has some limitations, like that the proxy contract should be deployed from the beginning you can't just deploy a proxy an expect that it changes or modify an existing contract, but let's say you have an upgreadable erc1155, for the limitation of the proxy you will probably have a lot of problems doing this update, because you can't change the way that the variables are defined or stored, you can't delete any existing function (you can leave it empty instead),and other things
probably you will need to deploy a new contract that will be the erc721, then you will have to make another contract that makes the swap, receive a token from the old contract and gives the token of the new contract, is on you how the contract will get the new tokens if it will mint the tokens or if it will have it, also you have to considere what you will do with the old tokens because if the old contract do not let the tokens to be burned you can't, but you could lock it in the same contract or something similar that is almost the same as burning it
When looking at other team's smart contracts, I often see code like this:
address constant public token = address(0xabc123...);
Where the hexadecimal number is the address of an earlier-deployed smart contract. Coming from JS and C++ background, I'm not a fan of this because it effectively hardcodes what should be in a configuration file directly into the smart contract code. Several questions come to mind when I see code like this:
What if I want to deploy this to another EVM-compatible network?
What if I want to deploy this to testnet?
I'm still relatively new to Solidity, so it's possible I'm missing some feature of truffle that allows me to insert these strings at the time of deployment, but I didn't see this mentioned in any of the tutorials I went through. I would much rather have something like a JSON configuration file for testnet/mainnet/L2-chain/etc instead of having N versions of the same file with minor differences. How should I handle these cases?
You can have a variable (instead of a constant) containing the token address. And this variable can be set from a constructor.
So you can effectively pass the value from an environment variable to the contract constructor, to the contract storage.
Example:
.env
TOKEN_ADDRESS=0x123
deploy.js using Truffle (docs) for example
MyContract.new(process.env.TOKEN_ADDRESS)
You can also use Hardhat (docs) or any other library allowing you to deploy to any network depending on the config.
MyContract.sol
pragma solidity ^0.8;
contract MyContract {
address token;
constructor(address _token) {
token = _token;
}
}
I want to create a crowdsale token contract similar to EOS. I am new to crowdsale token contract. I get the source code from etherscan.io. They are EOSTokenContract, EOSCrowdsale, EOS-Owner. I want to know how did they deployed their smart contract. Through truffle? or what kind of framework to deploy their smart contract.
Can i deploy a similar crowdsale contract using those three files?
My suggestion is to take a look to OpenZeppelin, they provide a good library to develop Smart Contracts, with good tutorials and guides and a specific focus on crowdsale contracts.
You can start from their basic example "How To Create Token and Initial Coin Offering Contracts Using Truffle + OpenZeppelin"
In EOS contract is written in C++ language while in ethereum in solidity. SO you can't deploy using truffle because it's not yet developed for EOS.