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.
Hi @oxuw4
From the OpenZeppelin webpage:
OpenZeppelin.org
$4.5 BILLION worth of digital assets powered by OpenZeppelin smart contracts
From a recent article:
Bootstrapping a Developer Ecosystem with Zeppelin
Notably, OpenZeppelin has become the de-facto standard for secure smart contract development. More than 12% of the tokens built on Ethereum use this standard, and more than 3,500 repositories depend on it and OpenZeppelin has surpassed 500,000 cumulative downloads, growing at over 15,000 downloads per week.
Example code:
Coinbase and Circle’s USDC: https://github.com/centrehq/centre-tokens
I hope this helps.
When is your talk? Feel free to post a link.
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.
Hi @oxuw4 role based access control gives more flexibility than having a single owner.
I hope your talk goes well.
We all started as beginners, feel free to ask as many questions as you need.
It would be great if you could Introduce yourself here!
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?
Hi @oxuw4
Upgradability is hugely important consideration when developing smart contracts.
As you have looked at Centre, suggest starting with their article on Designing an upgradeable Ethereum contract and how they came to use ZeppelinOS Proxy patterns
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 truffle@5.0.2 and ganache-cli@6.3.0. 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.
Hope this clarifies things!
Referring to CardStack Token in terms of upgradeability of SmartContracts: https://github.com/cardstack/cardstack-token
They wrote about it here: https://medium.com/cardstack/cardstacks-upgradable-smart-contract-explained-dbf443888cfc (but to be honest, I have understood their approach in general but not completely)
And CPUCoin: https://github.com/cpu-coin/CPUcoin (blog post: https://medium.com/@CPUcoin/the-making-of-an-open-source-token-vesting-smart-contract-34274f9ea257)
I am not affiliated with both, but stumbled upon their blog posts recently and took a look into their code. I am not fine with every decision they have made but it looks less worse than others
Thank you so much!
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?
The OpenZeppelin Design Guidelines include the following:
D1 - Simple and Modular
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.
My recommendation would be to use OpenZeppelin.
List of repositories depending on OpenZeppelin: