Hi, in order to list real live example code for ERC20-Token and Crowdsales at a talk about Smart Contracts I’m looking for such projects?
Who can recommend me the real GOOD examples out there (and not all these broken stuff that can be found with Google and/or GitHub from <= 2017 that also is mostly outdated and can’t get compiled any more with latest solidity compiler versions). They should also base on Openzeppelin.
Any examples are much appreciated! Thank you all in advance.
Wow, thank you. Centre is really great! But I’m curious why they put so many roles into its permissions? What could be the reason to have so many different roles like one dedicated Role for the Pauser, one for the Blacklister, one for adding Minters and so on. Couldn’t it be just reduced to the Owner?
My talk is internal within our (big) company, thanks for asking I’m just something like a beginner, and want to share my lessons with other colleagues that they can catch up faster.
Thank you so much! Great support here I will definitely talk about this too.
One special thing I want to put into my talk is the Upgradability of a smart contract. I came across this feature reading the source code of Centre-Contract. Can you please recommend any good Documentation or Tutorial about this?
To learn more about ZeppelinOS I suggest the following tutorials:
The ZeppelinOS documentation has easy to follow tutorials on deploying and then upgrading a smart contract.
(Please note, use versions email@example.com and firstname.lastname@example.org. Also when starting the zos session, use your second ganache account as the from)
@paulinablaszk wrote a great tutorial on upgrading to fix a vulnerability
@ylv-io wrote a tutorial on solidity hot reloading using ZepKit. Hot reloading is amazing to see in action.
Let us know if you have more questions or any issues running the tutorials (I have run through all of the above tutorials and found them really helpful)
Separating roles in this way follows the security principle of least privilege. For example, a company may have a fraud department that handles blacklisting, and you don't want to also give them access to minting!
As opposed to a simple ownership system, roles also allow you to have multiple accounts on the same role. For example, minting may be handled by a market maker smart contract, and for cases of emergency by a C-level multisig kept in cold storage.
Having multiple accounts with a role also allows you to easily parallelize a role across servers. If all the servers share the same account, not only is this bad key management practice, it also makes it hard to send transactions because the nonce needs to be sequential.
What is the reason that the Crowdsale-Contracts from OpenZeppelin are not commonly used? Everybody is base their code on top of ERC20, and put then every logic inside his token contract instead of splitting between token contract and crowd sale contract. What could be the reason for that?
Simpler code means easier audits, and better understanding of what each component does. We look for small files, small contracts, and small functions. If you can separate a contract into two independent functionalities you should probably do it.
The token functionality is generally ongoing whilst a crowd sale may be for a fixed or shorter period. Based on the OpenZeppelin Design guidelines, token functionality and crowd sale functionality should be in separate contracts.
Crowdsale contracts were added to OpenZeppelin in v1.1.0 (July 2017).
I don't know why projects would combine token and crowd sale functionality.