Is there a way to automate an ERC20 token deploy? Can a contract receive some parameters to configure the new token and then deploy it returning the new token address?
I'm trying to create a contract that speaks with a dapp which instructs the contract to create and then deploy a given ERC20 token with the given parameters (name, sym, decimals...)
Is this possible?
I've found that a Dapp can deploy a contract:
https://ethereum.stackexchange.com/questions/36698/deploying-a-smart-contract-using-dapp
But can a contract deploy a contract? Is this too pricy?
But can a contract deploy a contract?
Yes. A contract can deploy a contract.
See for example Uniswap v2 UniswapV#Factory deploying pair contracts using CREATE2 (deterministic deployed contract addresses).
Is this too pricy?
This is a business model question and cannot be answered based on the information you provided in the question.
Related
Remix is telling me "Currently you have no contract instances to interact with." But that's because Remix Won't Allow me to deploy my contract. Please Help I'm new to thisPicture of my remix smart contract
You have not compiled your smart contract. You need to first compile your smart contract only then you can deploy your smart contract.
I want to deploy my own ERC-20 token on different blockchains, so is there any possibility to deploy the same token contract on different blockchains. If we do that we can't give the same name and symbol for three blockchains. can anybody tell me what is the solution for this problem? Or can we deploy the contract with the same contract address on three blockchains?
can we deploy the contract with same contract address on three blockchains.
It depends on the network that you're deploying to and the address that you're deploying from. Assuming that the networks of your choice have the same 1) address format and 2) calculation of deployed contract address - then yes, you'll be able to deploy your contract on the same address on multiple networks.
For example Ethereum and BSC do have both of these features. But even though Tron network supports EVM-compatible smart contracts, it has a different way to calculate its addresses, so it won't be possible to deploy your contract on Tron network with the same address as on Ethereum or BSC.
The key to deploy the contract to the same address on multiple networks, is to deploy from the same address, and using the same params:
In case of the regular CREATE opcode, the transaction deploying the contract needs to have the same nonce (and the same from) value across all networks.
Or if you're using the CREATE2 opcode, you need to pass the same contract bytecode, the same salt (to the CREATE2), and again, you need to send the deploying transaction from the same address.
If we do that we can't give the same name and symbol for three blockchains
It is technically possible, so I'm assuming it's "just" a limitation of your business case or some tool that you're using, or a possible simple misunderstanding of how the ERC-20 standard works.
pragma solidity ^0.8;
contract MyToken {
string public constant name = "MyToken";
string public constant symbol = "MyT";
// TODO rest of your token contract source code
}
Learning Solidity along with token development.
I'm having a hard time understanding how tokens with multiple smart contracts interact with each other.
I've read through other tokens with multiple contracts on GitHub and reviewed contracts on OpenZeppelin but they all appear somewhat orphaned.
Let's say we developed a token that has a supply and tracks wallet address to amount using a map. The contract is released and is given an address. Admin or privilege methods are protected via owner address validation. Then we release a second contract that needs to make apply a fee for transactions.
How does the second (token transaction fees) contract interact with the data stored on the first (token contract)? Does the second contract need to also verify ownership?
Any contract on Ethereum can interact with any other contract by using Interfaces. You can call methods from the second contract on the first contract for an ERC20 token as below:
Define ERC20 Interface
interface ERC20 {
function balanceOf(address account) external view returns (uint256);
}
Use the interface and token contract address to call methods on the first contract:
ERC20(tokenContractAddress).balanceOf(0xabcd....);
The similar approach can be used for any contracts
as most of the BEP20-Tokens-Contracts are online available on GitHub or BSCScan you should be able to just copy the code and paste it into remix.ethereum.org and deploy it. I did that and the contract deployed successfully to the BSC but the token information are missing. What do I do wrong?
Here is the code I copied: https://bscscan.com/address/0x0cF011A946f23a03CeFF92A4632d5f9288c6C70D#code
and here is my contract deployed to the BSC: https://bscscan.com/address/0xf5be6f7f00a4870b46f3ab6d16f5095731da97d7
I have just changed the name of the token, but the token information are not showing up on BscScan nor do I see the token in my Wallet. Any help is appreciated!
Your contract's bytecode contains just the Address contract bytecode. Since it's the first contract in the list (sorted alphabetically), I assume you simply forgot to select the contract that you wanted to compile.
You need to select the NyanCatToken contract (which effectively imports the Address as well) when compiling in Remix.
I am currently developing a dapp on ethereum. From what I know msg.sender should has the value of the account who interact with it. However, it keeps the value of the deployer's account.
I am using metamask and solidity ^0.4.24. I am deploying the contact using truffle framework and also Ganache GUI as my virtual node
function getMe() public view returns(address){
return msg.sender;
}
So, I expect this code to return the hash of the account which is interacting with the contract but instead I am taking back the address of the acount which deployed it
msg.sender contains the value of the address of the caller. You must be deploying and interacting from the same account, probably using accounts[0].