Knock, knock. Who’s there? Brush Fires. Brush Fires who? The Brush Fires you have to put out when coding your ICO Smart Contract.
Unless you’ve been hiding under a particularly large, hermetically sealed rock during the past year, the unprecedented drama concerning ICOs must have been painful to watch from behind that LCD screen.
While everyone is still getting worked up about China’s ban on them, South Korea’s desperate attempts to and the United States’ mixed messages, others are honestly worrying about the future.
Are we witnessing the birth of a new, world-changing concept or one that will be forgotten by the end of the next decade? Will regulation doom this revolution before it can begin? Of course, nobody truly knows, and that is what makes this whole affair so exciting and full of potential; nevertheless, many who are involved, from software developers to investors, would tell you otherwise if you were to ask them.
They’d say that ICOs — or rather the technology behind them — are just too precious and too useful just to lose and that the technology must be here to stay.
However, you may ask: What are they really talking about when they say that? What exactly is that technology?
The answer is smart contracts, people. Smart contracts: to most, the term sounds like a buzzword like ‘blockchain’ (and to most, it probably is), but there’s more to it than that, obviously. There is much more. Let me tell you the story of how I learned about smart contracts and of how I’m using one to vastly improve RadioYo.
First off, let’s make some things clear. What can a smart contract actually do for you? At its core, it only does one thing: It automates the process of mediating a contract negotiation. It determines whether or not conditions that both parties agree on are met and processes the contract accordingly without any human intervention. Of course, in the context of ICOs, this contract would be financial in nature, and that is by far the biggest use for these wonderful lines of code.
They’re wonderful if they are coded properly, that is.
This is where my story comes in. You see, if there’s one thing to learn about undertaking an ICO and having a smart contract coded, it’s getting everything right on the first try. You have to — once your smart contract is live, the merits and shortcomings of your design will reveal themselves, and there won’t really be an easy way to edit anything once that’s done. Sure, you can write a second smart contract to correct the errors, but that’s costly.
When I decided to go the ICO route for RadioYo, one of the biggest challenges I faced was making sure that the smart contract code was absolutely perfect before deciding to go live. I myself am no programmer. I couldn’t tell C++ from HTML to be honest, but you don’t have to when designing an ICO. It’s all very simple, really. It’s just Boolean thinking. That’s it.
If this, then that. Rinse and repeat for dozens of possible variables. Like I said, it’s simple. It’s too simple, actually, as it gets you to think there’s always something wrong with what you’ve thought up, or your smart contract is ‘too easy’ to finish. The developer you’re working with means a lot here.
The perfect candidate should be an absolute master, not just when it comes to coding, but also in the ways of your industry. He should be communicative and know how to express himself.
He should know what he’s doing and never feel the need to make compromises.
Those are a lot of boxes to check, but consider this: The demand for blockchain talent is great. That means there are many people out there to work for you, and many of them will be amateurs. They’re inexperienced, are probably looking for nothing more than quick cash, and have just started out with Solidity. Depending on your needs, that ‘just’ can encompass anything from a few months to years of experience. This means they’ll most likely have trouble bonding with the core philosophy of your business. Also, communication is going to be problematic at best. Something is not going to be quite right, and chances are you’ll only notice it during the auditing phase after this developer has already left with a big green bundle in his or her hands and a smile on his or her face.
How about an example from my own experience?
Due to a simple, at first innocent language barrier, the first blockchain developer I hired to code RadioYo’s smart contract ended up using code from a prior project of his instead of writing fresh code for RadioYo.
After we launched RadioYo’s ICO and our smart contract was live on Mainnet, we also found out that not all of our tokens were accounted for. Granted, we can fix that in the future with a second smart contract, but this could have been avoided if I had chosen a developer with whom I could properly communicate. Skype is OK, but a phone is better.
If it was a lesson for me, it can be one for you, too. Learn from it!
So, instead of going that route like me, you should look for the best of the best from the get-go.
Remember, one mistake could cost you the stability of your entire ICO and doom your project permanently. The vast majority of ICOs that are currently in circulation — and there are tons of them — contain at least some major security flaws, and the vast majority of these can be traced back to poor smart contract coding. The result of these flaws can destroy an ICO’s reputation, trustworthiness, and potential before any of those three things have had their chance to develop in the first place.
Speaking of security, nothing could be more important to the mainstream user. Think about it: What could possibly set your ICO apart from the hundreds of others already flooding the market? That it’s exclusive to your service or website? Oh, please. What users really want out of an ICO is dependability and maximum security. They’re entrusting your creation with their money, after all. Think about every single detail.
Not every flaw is tied to theft; there are other vulnerabilities too. What if your backend doesn’t scale too well? That can turn out to be critical if enough transactions occur at the same time. What if gas prices are too high? Users will not want to spend that much in extra fees on every transaction. What about phishing? How will you protect against that? The truth is that there’s an answer to all of these questions, and many more as well — if you know where to look. If a problem exists, someone, somewhere, has already thought of a fix, and if you’re lucky, a solution already exists. This hunt to squish all of the bugs and remove every imperfection can quickly devolve into the ultimate game of ‘Do you know a guy?’, but it doesn’t have to. Again, if your developer(s) is made of the right stuff, there’s nothing to worry about.
Once your ICO goes live, there are still many things to do though. Remember, you are effectively in charge of an entire market. It is a very tiny market with a specialized appeal, for sure, but it’s still a market. As such, you’ll need to gauge things like coin supply efficiently — do you want to burn some tokens to hike prices up and appeal to new investors? Do you want to set a soft cap on the supply at all? How about mining? Yay or nay?
These questions should, of course, be answered in the development phase, but post-release is where they and their answers actually become important. This is also the time where you won’t stop hearing certain jargon terms like KYC and whitelisting. My head has already shattered into thousands of pieces from hearing these too much, but believe me, yours will, too, at some point.
KYC, if you haven’t heard of it before, is short for ‘know your customer’. It’s a general business term not directly tied to smart contracts in particular. Basically, it’s what Google’s been doing for the past few years and what everyone has been deriding it for since it began. It is what the common man will casually call ‘spying’ in conversation. In other words, it’s collecting information about your users to make sure they can participate in your ICO. Your team, or at least someone in it, must possess the expertise to map out a strategy on this; otherwise, this whole ICO business could fail very quickly. If you don’t KYC or whitelist, you might as well not try to ICO.
One could write a whole book on what it takes to get a smart contract coded, but you know what? Let me keep myself a little short for once. Whenever I have screwed up, I have got back up again and learned from it. Does that mean you learn from your mistakes? If it doesn’t, then I don’t know what does. Does it mean you can only learn that way? I don’t think so. So, having said that, what are you waiting for? Go out there and get your smart contract done!
Your ICO won’t create itself! (However, I’m sure that, at some point, someone is going to program something like that.)
###
RadioYo is building an open source blockchain-based broadcasting and services platform where developers, consumers, listeners, podcasters, service providers and advertisers can openly collaborate, track ownership of content or be rewarding for their efforts. With the RAO, a new cryptocurrency at its center, RadioYo is building out a new model that enriches and transforms the relationship with consumers such that they consume more flavors of content across various media and enjoy more experiences in the presence of our brand in the real world.
