5

It depends. Ethereum is a general-purpose platform and Solidity is an expressive language, so things can potentially work according to arbitrary rules that your developer codifies. That means both intent and quality need to be aligned in your own best interests and the interests of your users. It is challenging to confirm either intent or quality unless ...


5

You are violating one of the basic concepts of blockchain. You can't remove anything! If the contract has a method in place for disabling its functionality that's fine. However, it will always remain on the blockchain.


4

There is nothing wrong. When you do your first token transfer it will automatically be visible.


4

Smart contracts are immutable (code cannot be changed) by design. Truffle and ZeppelinOS are platforms for the development of smart contracts for Ethereum based blockchains. Truffle migrate manages the deployment of contracts to blockchain(s). Each time you migrate a contract you deploy a new instance to a new public address. To use the new smart ...


4

In case of truffle the stored values will not remain in the upgraded contract whereas in proxy approach it is possible to obtain the stored values in the upgraded contract too. In truffle upgrade a new version of contract is being deployed to the network and we will be obtaining a new contract address. If try to console the contract address in migrations ...


4

I assume you deployed it on the Main Net using MetaMask. Probably the gas limit of the transaction was too low. Otherwise the gas price was to low. Please send a screenshot of your MetaMask transactions, in case above didn't fix it.


3

Sure. To deploy smart contract one needs to publish a transaction with empty to address and with data containing contract initialization code concatenated with values of constructor parameters. Initialization code usually consists of constructor byte code and contract's byte code to be deployed. So, deployed byte code does not contain constructor and ...


3

I'm pretty sure that your suggestion is correct. The contract was deployed in tx with hash 0xd47b26a4bb5cacb3792f2d849ef298295af62fcf5943cfc5e987b0c7c798f162 The 0x607108c4... cotract creator is 0x584b3fb1..., because inside this contract new was called. And the external accout called 0x584b3fb1... contract to create the tx. So, it is to address that ...


3

This seems to be a remix bug. When you deploy it using web3 or so it should work properly. Everything should be fine. As the other answer stated you can bypass this problem.


2

The only direct options you have are msg.sender and tx.origin (which shouldn't be used basically ever). There is no way to get addresses which are "between" these addresses. Otherwise, as smarx stated, you should pass the desired owner address as a parameter and use that.


2

What you are looking for is eth_getCode: Returns code at a given address. Example: $ curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0x0289eC8BDFBF5f6d90102E752e674F18f7a8Ed03", "latest"],"id":1}' http://127.0.0.1:8545 {"jsonrpc":"2.0","id":1,"result":"...


2

Found the answer. It turns out that the web3 options aren't exactly optional for Ganache: I had to change: const provider = ganache.provider() const web3 = new Web3(provider); To: const provider = ganache.provider() const OPTIONS = { defaultBlock: "latest", transactionConfirmationBlocks: 1, transactionBlockTimeout: 5 }; const web3 = new Web3(...


2

Try changing on for once var myContract = new web3.eth.Contract(_abi, senderAddress, options); const toDeploy = myContract.deploy({ data: _bytecode, arguments: [100000, "0xD41396Fa287B20311DD389D563539d8578dad23e"] }); toDeploy .send({ gas: 5000000, from: myAddress }) .once("confirmation", (confirmationNumber, receipt) => { //After several ...


2

The EVM bytecode (compiled form) is available/observable to all users at all times. The data in contract states, including variables explicitly marked private, is available/observable to all users at all times. private describes visibility to other contracts but it is a misunderstanding to assume it implies protection for confidential information. ...


2

You could look at OpenZeppelin Contracts ERC20 Token documentation to see if this meets your needs for an ERC20 Token. You may also want to use the OpenZeppelin IERC20 interface. Note that you should only use OpenZeppelin code published in an official release, so you should include the version tag in your import when using Remix or you can take a look at ...


2

I think this behavior is due to the fact that you're passing struct between contract. As you might know they should be passed internally. That said you need to use getNameMain Here you'll find a similar discussion copy a struct from Contract A into a struct in Contract B using Contract C


2

It is not possible for a Smart Contract to trigger itself. However, you could use an external service like the Ethereum Alarm Clock which will trigger the Contract for you.


2

The transaction does not have a "to" so the EVM will try to deploy a new contract using the data field as bytecode. You are sending in the data field the following: 0xa9059cbb0000000000000000000000000764edccd0278ee60c421148b8bab812306d90d50000000000000000000000000000000000000000000000000de0b6b3a7640000 Now 0xa9 is not a valid opcode and the EVM will halt ...


2

Looking at the deployed byte code on Etherscan, it appears to be 18099 bytes long (36198 hexadecimal characters).


2

Your Bytecode isn't a hex number. Prepend a 0x. For example 0x606060405260018054600160a060020a031916... EDIT: Nevermind you already did that. Here is another try. Convert the string to hex. parseInt("0x6060604...", 16) Take note of the radix 16. Leave this value unchanged.


2

Run it again. More generally, run it inside a try/catch block until success. For your specific error, it is possible that the node is not synchronized with your account's current nonce, so you may want to add this to your options object: nonce: await web3.eth.getTransactionCount(0xYourAccountAddress) Since you may also encounter other types of errors, I ...


2

It does have a transfer function, you just don't see in the contract because the author has used the Upgradable Contract design-pattern, which (as implied by its name) allows him/her to upgrade the contract. Here are a few more examples of ERC20-Token contracts which were implemented the same way: BUSD Token AMPL Token USDC Token REP Token TUSD Token SNX ...


1

pragma solidity ^0.5.0; import 'https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/math/SafeMath.sol'; contract SubToken{ mapping(address => uint) balances; string symbol; string name; uint8 decimals; uint totalSupply; using SafeMath for uint; address contract_address; ...


1

Calling transferFrom triggers a Transfer event. If you use open zeppelin then it also triggers an Approval event. There is not a tranferFrom event in the ERC20 standard. Hope this helps.


1

Constructor argument shall be part of the data. A quick check to see if you have prepared the correct data is to check if the two addresses that you would pass to the constructor is part of var data = "0x608............"//from remix detail If you don't like the hex data, you could use the web3.eth.Contract.deploy method to pass constructor parameters as an ...


1

Depending on what you are trying to achieve exactly, there might be another method, using extcodecopy to copy a contract's code. This method would for example allow you to deploy one or several "template" smart contracts on their own, and then build and deploy a separate Deployer contract, which copies code from a template and uses it to deploy a copy. Here'...


1

You are conflating tooling and platform. Truffle is tooling. You don't deploy to truffle, but it can be handy to use truffle to deploy to dev/test and production platforms. Ganache is platform. Regardless of tooling (in your case, a React app), Ganache is a valid platform for dev/test both in terms of cost and in terms of developer productivity. Consider ...


1

Actually deploying a contract is not analogous to instantiating an object. Deploying a contract is like publishing your program for the world to see/use. So when you deploy your contract you create a version of it and publish it. The difference is that regular programs are typically available at the same "address" with a new version but deploying the same ...


1

To solve the error you need to pass the arguments of the constructor in your migration file. Based on your two params: // Untested // Deploy a single contract with constructor arguments deployer.deploy(towater, ["string_1", "string_2"], ["0x15458ef540ade6068dfe2f44e8fa733c", "0x15458ef540ade6068dfe2f44e8fa734c"] ); Check the Truffle docs.


Only top voted, non community-wiki answers of a minimum length are eligible