Here’s what I learned after working for 2 ICOs as a Blockchain Engineer
So I just finished working for the second ICO and I want to share with you all the good and bad things I’ve learned. This is knowledge that you can only get from experience.
Let’s get right to it:
You are never too prepared
The first ICO was the hardest because I didn’t really understand how everything ties together internally. It seems simple:
- You create 2 smart contracts, the token and the Crowdsale contract that will be used to raise funds and distribute those tokens
- Then you publish the Crowdsale contract address on the website
- People see that address and send Ether to receive tokens back
Well, it’s never that simple.
First off, the complexity of the crowdsale contract tends to grow bigger as features are added. When I finished creating the first version of the crowdsale contract, we made external audits with different developers to find out any possible vulnerabilities.
There were several issues.
Those issues were small but important improvements. Things like:
- The fact that a single investor could potentially buy all of the tokens leaving thousands of potential investors empty-handed
- Set up a minimum investment to weed out tire-kickers that will want to be a part of the company without many tokens at stake, people that don’t believe in the project
- Making sure that the tokens were locked until the ICO is completed to stop people from selling the tokens too early
We only wanted the commited, trustworthy investors.
So I added those changes in a couple of days with several tests to make sure I wasn’t introducing new bugs. Needless to say, the complexity of the crowdsale grew bigger which complicated the entire process.
That was another issue. After creating and deploying the contracts several times with a specific set of steps to make sure the ICO contract is communicating properly with the token contract, the code was harder to maintain.
We conducted 2 audits and a public bug bounty to improve the code while rewarding the users that helped us do so.
Bug bounties and audits are very time consuming
Conducting a bug bounty is very time consuming. I spent about a week receiving and testing the assumptions from those bounty hunters that wanted a reward for finding bugs in the code.
It’s not easy to continually test the code while making small improvements in a big contract of 400+ lines of code. A bad line of code could lose millions of dollars.
The way we conducted the bug bounty was to reward the hackers based on the frequency and severity of the bug found. Turns out sometimes it’s hard to decide if a bug is a small issue or if it’s an extremely bad issue that could make us lose all the funds raised so far.
I wish I knew about the OWASP framework earlier for assessing the severity of each vulnerability. I would have saved hours in pointless discussions about each issue. Long emails going back and forth.
You have to simulate your ICO before the real one
This one is extremely important. We thought that everything was going to run smooth and that the ICO was going to be a success because we planned everything months in advance. Turns out we were wrong.
You must make sure your ICO runs smoothly way before the real one. Do “Fake ICOs” with your team to see how everyone responds to the complex situation to coordinate everyone at the right time.
Fail to do this, and you’ll potentially lose millions from investors that wanted to participate but couldn’t because you weren’t fully prepared to the ICO.
From my experience, the ICO website got DDOSed at the critical time. The developer in charge of displaying the final smart contract Crowdsale address, took about 20 minutes in doing so.
Which means that the 100 live visitors that wanted to participate in the ICO were shown a white 404 error screen.
The minimum ICO investment was 0.1 ETH but we somehow got confused about that and we said that the minimum investment was 0.01 ETH, making people lose their GAS because most of them wanted to test a small investment amount before the big one to see if the contract was working properly while receiving the tokens.
My recommendation after such bad situation is the following:
Make a simulation of your ICO. Deploy your contracts as if they were the real ones and tell your team to start a fake ICO just to see how all of you coordinate during that critical process. It will show you that some things aren’t as clear as they seem to be and that most people don’t know as much or as little as you think you know.
Explain all of them the process and make sure your investors 100% understand how to participate and the best way to do it while also understanding that its a complex process and that there’s always a risk associated with it.
Make video tutorial explaining the process from several different perspectives.
I’ve learned that most of the people even in your team, don’t know what you’re doing and how the ICO actually works. Be patient with them and walk them through the steps.
You probably won’t hit your funding goal
It’s not because you made some kind of mistake, it’s more about the fact that you are not reaching the top investors that will push the funding forward. Keep bringing people to the ICO to make them invest in your project and create something unique that’s helpful.
On the other hand, I see a lot of project that aren’t trying to push the blockchain technology forward. They are just creating alternative products of already existing solutions by duplicating the functionality and adding blockchain on top to raise funds. That’s not how it should be done.
However as long as people are getting value from the projects I’m all for it.
You see, to reach your funding goal you have to be able to reach the top of the ICO rating websites. You have to be better than 95% of the ICOs out there to reach your funding goals. Not just for the traffic but for the quality of your project. That will show that you are taking care of all the aspects of the project that you are creating.
The more content your provide, the more you work on providing value, the better your ICO will do.
Don’t get mad when you don’t reach your funding goal. You’ll get enough to develop the project fully and if not, you can always create a second ICO.
Another very important lesson was…
You’ll need more time than you think to create the ICO
Most ICOs are simple. They work on a project and they convince people to give them money to make that project a reality.
In my experience, it’s not that simple. Each ICO needs a few essential things that take a lot of time to get right:
- The website: It will take generally a month to complete a decent website. The content will gradually come until you have enough.
- The whitepaper: A good whitepaper has about 30 pages. That’s a lot of text. A small book about your ideas, research and goals. You’ll spend many days working on it.
- The technical whitepaper: I’ve worked on creating the technical whitepaper on both ICOs. It different in each case because you have to explain the project, how it will work and how the ICO will be conducted technically. Another small book that will take you days to complete.
- The video tutorials and articles: As the lead blockchain engineer I had to spend time making video tutorials to show people how to participate in the ICO while writing articles as detailed as possible to avoid any confusion. This is a very time consuming process.
- Marketing: It’s not a surprise to be involved in the marketing aspect as the developer. I had to help the teams get their message right because I was the one that fully knew how the entire ICO was going to develop.
In general I worked on all the areas of the ICO to make sure people were understanding the message. I spend months working on them. Way more than we initially expected. So remember that your ICO will take more than you even think.
I see projects that were created years ago as an idea and only now are being created because of the possibility of a successful ICO. Only the most committed will last.
As the lead developer I was the leader
This is more of a general issue but the fact that I was the lead developer meant that I was the one in charge of making sure the ICO was a success. It’s a big responsibility because there are lots of things to take care of.
I was the one in charge of making sure the investors had all the information they needed to participate in the ICO. Videos and articles were mostly on me, which is cool.
I had to make sure the contracts were completed, tested, audited and properly deployed for the real ICO.
The main lesson is that I had to see the ICO from up above to understand what could go wrong and what was missing to fix it before it was too late.
More like a Chief Technical Officer than a Lead Blockchain Developer. Keep in mind that you have most of the responsibility when you are the main developer.
Did you forget the lessons? Continue reading for a quick summary…
To recap
After working on 2 ICOs for months I’ve learned that:
- You are never too prepared
- Bug bounties and audits are very time consuming
- You have to simulate your ICO before the real one
- You probably won’t hit your funding goal
- You’ll need more time than you think to create the ICO
- As the lead developer I was the leader
That’s about it. If you think I missed something, let me know in the comments. Do you think something is wrong? You don’t agree with a particular thing I said? Be sure to tell me in the comments and I’ll do my best to give you my perspective.
If you hate spam, you can leave right here. Otherwise, if you want to learn more about the projects that I have going on, continue reading.
Look, I’ll be honest: I want you to buy my book. I spent time writing it from my experience and I truly believe it will change your life if you apply it as a novice or advanced developer. Can you imagine the power of being able to do your own ICOs, be an advisor, auditor or developer for groundbreaking Ethereum projects?
I didn’t spend years researching this stuff, I don’t know a whole lot about most cryptocurrencies or blockchains. But what I know for sure, is how to create Smart Contracts for whatever purpose and how to do my way so that it works.
That’s why I only write what I know, what I experienced first-hand. I believe that’s how most of the books have to be created. After living the experience.
Check out the book here to see what it contains and you’ll be able to even download it in PDF for all of your devices: https://merunas.org/book
If you’re looking for a big has-it-all book about Ethereum and Smart Contract development, then this is not your book. I focused on just the right information so that you can get started ASAP to be able to create your own Smart Contracts in an efficient way and get paid while doing so.
Let me know what do you think about this article and be sure to clap it if it was helpful or entertaining to you. Be sure to join our 200+ people facebook group to get your questions answered while being part of one of the most helpful communities here: https://www.facebook.com/groups/ethereumdevelopers/
If you want to help in anyway, check out this 5 minute survey that I made about ethereum developers to help you get the content you want: https://goo.gl/forms/Ck2dKVDE6K9xQChG3
