Great stuff!! (Create upgradeable ERC20)
Very succinct and it has the proxy as well! Thank you!!!..in second thought, maybe an upgradeable token such as this wouldn’t require me to do much at all my other contracts over the short term?
1 Like
–I reset my truffle environment,
–removed all npm VsCode plugins
–disabled Solidity (vscode)
–installed NPM OpenZeppelin/openzeppelin-contracts-upgradeable
And the migration went through just fine after the compiler told me I spelled ‘istanbul’ incorrectly in the config lol!..Now I need to work on some sol logic that will allocate 10% to owner and remaining to the community…or perhaps I should just transfer the tokens to a community contract after deployment. but id prefer to take care of it during deployment though…do you have any suggestions about the best approach for that Andrew?..and thanks again for your time and help! I appreciate it very much!!
2_initial_migration.js
======================
Deploying 'DaFi_ERC20_Upgradeable'
----------------------------------
> transaction hash: 0x479513ae8bbb72d408610ebde900fbd83bcd660e3f916ed8641acbf517d186f4
> Blocks: 0 Seconds: 0
> contract address: 0xc4C7981BCB06B2bA19901037f975dacb3e92CB0A
> block number: 3
> block timestamp: 1608179317
> account: 0x88EE2eDbe38264Bd70C95AEc9e28De665bbFDe13
> balance: 99.97752238
> gas used: 927944 (0xe28c8)
> gas price: 20 gwei
> value sent: 0 ETH
> total cost: 0.01855888 ETH
Deploying 'ProxyAdmin'
----------------------
> transaction hash: 0x9867fc5f553f2dc9ff840dc850399fa9e709e009e8d2f0070336899b53ecc31c
> Blocks: 0 Seconds: 0
> contract address: 0xCCBe8EB837d0100D2ec05BB938C556B1b0c078f5
> block number: 4
> block timestamp: 1608179317
> account: 0x88EE2eDbe38264Bd70C95AEc9e28De665bbFDe13
> balance: 99.95992314
> gas used: 879962 (0xd6d5a)
> gas price: 20 gwei
> value sent: 0 ETH
> total cost: 0.01759924 ETH
Deploying 'AdminUpgradeabilityProxy'
------------------------------------
> transaction hash: 0x1931f247904ee4e7d6f90667cae57e94b82ebfe4601c239a2a915bdbed74cd11
> Blocks: 0 Seconds: 0
> contract address: 0x81F71B32b32038A3cBCac9F2bd9E9c745849480e
> block number: 5
> block timestamp: 1608179318
> account: 0x88EE2eDbe38264Bd70C95AEc9e28De665bbFDe13
> balance: 99.94513396
> gas used: 739459 (0xb4883)
> gas price: 20 gwei
> value sent: 0 ETH
> total cost: 0.01478918 ETH
> Saving migration to chain.
> Saving artifacts
-------------------------------------
> Total cost: 0.0509473 ETH
Summary
=======
> Total deployments: 3
> Final cost: 0.0509473 ETH
1 Like
Hi @rmourey26,
I am not sure what you mean?
You could mint the 10% to an Gnosis Safe multi-sig and 90% to a DAO or a Gnosis Safe multi-sig in the initializer. You could accept the addresses of the wallets to use as parameters of your initializer.
Thanks again Andrew!
Re: my comment about setting up an upgradeable contract for my token structure …I was thinking doing so would require me to alter 26 other contracts that I have tested and ready to deploy…would they have to be modified to align properly with the ERC20 Upgradeable?. In your opinion whats the most open ended token contract Oz affords users? In terms of possibly adding features at a later date.
I am going to try out those supply mechanisms shortly…
1 Like
Hey Andrew hows it going? Was the migration 2 deployer.js for the ERC20 Upgradeable contracts we discussed supposed to include an initial supply multiplier in order to accurately deploy the amount of tokens? I deployed 50,000 tokens with 18 decimal and it appears that about 0.000…5 (to the 10th decial place) tokens were actually deployed. Any thoughts on how this can be addressed? Am I able to ugprade the contract adding a minter who then mints the proper amount of tokens? Or would it be easier to just deploy a whole new set of contracts?
And just an FYI - I initially had issues with the deployment timing out at 750 seconds and then had issues where Truffle required a deployer balance of about 2.5 times the amount needed to complete the transaction. But I adusted the gas and and gas limit many times and found something that worked. You may have previously heard about the timeout issue here at Github
Hi @rmourey26,
Sorry for the delay, I was on vacation for the holidays and just catching up now with everything.
ERC20PresetMinterPauser includes minting and pausing, as well as burning.
Sorry to hear if you have only minted 50,000 token bits (so less than 1 token with 18 decimals).
If it wasn't for the current gas prices, it could be easier to deploy a whole new set of contracts.
I recommend deploying to public testnets first (as well as having thorough unit tests), this type of issue can then show up when looking at Etherscan.
You could upgrade to a new implementation, with a function to upgrade state, appropriately protected so it can only be called once, to additionally mint further tokens. Alternatively you could add a mint function with appropriate access control (to protect who can mint tokens).
I recommend unit tests for the new implementation contract as well as higher level tests for the upgrade. I also suggest doing this on a public testnet first.
If you haven't already, I recommend placing your configuration files under version control: https://docs.openzeppelin.com/upgrades-plugins/1.x/network-files#configuration-files-in-version-control
Thanks for the FYI 
An upgradeable contract deployment includes three contracts, the implementation contract, a ProxyAdmin contract (one per project and per network) and the proxy contract. (Truffle also deploys a Migrations contract and then sets state.)
Upgrades Plugins should recover from a timeout due to network congestion.
Gas prices are currently high at the moment unfortunately, so it can be a pain deploying multiple contracts.