This article will show you how you can create and deploy a full-fledged ERC20 token in less than an hour.

In the last couple of years the ERC20 token specification has practically become the standard for Ethereum tokens. In fact most Ethereum tokens are ERC20-compliant.

There are several factors that make ERC20 so successful:

1. It is simple. Really simple. As we will soon find out.
2. It solves a real problem: blockchain marketplaces and crypto-wallets need a single set of commands to communicate with all of the tokens they manage, including interaction rules between tokens and token purchase rules
3. It was the first (well almost the first) specification to offer Ethereum token standardization.

As any other Ethereum token, ERC-20 tokens are implemented as smart contracts and are executed on the Ethereum Virtual Machine (EVM) in a decentralized manner.

Ethereum smart contracts are written in a language called Solidity (there are other options, but hardly anyone uses them). Solidity is somewhat similar to JavaScript. In fact, if you have some knowledge of JavaScript, Java or other C-like languages you will probably figure out what a Solidity piece of code does even before learning the language.

And now comes the fun part: creating a basic ERC20 contract. This is in fact a rather simple task. Simple enough that we will be able to write and deploy your first ERC20 token in no more than an hour.

Granted, the token we will be creating will be a bare bones implementation, but I have seen many bare bones tokens that do real well.

The Standard

What is this ERC20 anyway?

The ERC20 standard defines a short and basic set of functions to be implemented by all ERC20 compatible tokens so as to allow integration with other contracts, wallets, or marketplaces:

 function totalSupply() public view returns (uint256); function balanceOf(address tokenOwner) public view returns (uint); function allowance(address tokenOwner, address spender) public view returns (uint);

 function transfer(address to, uint tokens) public returns (bool); function approve(address spender, uint tokens)  public returns (bool); function transferFrom(address from, address to, uint tokens) public   returns (bool);

These functions will allow an external user, say a wallet, to find out a user’s balance and to perform safe and authorized fund transfers from one user to another.

Additionally, the contract defines two events:

event Approval(address indexed tokenOwner, address indexed spender,   uint tokens);event Transfer(address indexed from, address indexed to,   uint tokens);

These events will be invoked or emitted when another user has been granted the right to withdraw tokens from an account, and when tokens have actually been transferred.

Many tokens also add the following fields which have became de-facto part of the standard:

 string public constant name; string public constant symbol; uint8 public constant decimals;

Regarding the nomenclature:

• A public function can be accessed outside of the contract itself
• view basically means constant, i.e. the contract’s internal state will not be changed by the function
• An event is Solidity’s way of allowing clients e.g. your application frontend to be notified on specific occurrences within the contract

The rest of the language constructs should be clear if you’ve ever learned Java/JavaScript.

The Code

So far we’ve discussed the interface. Now let’s actually write some logic.

For this, we will need to define two mapping objects, which is the Solidity notion for an associative or key/value array:

 mapping(address => uint256) balances; mapping(address => mapping (address => uint256)) allowed;

The expression mapping(address => uint256) defines an associative array whose keys are of type address— a number used to denote account addresses, and whose values are of type uint256 — a 256-bit integer typically used to store token balances.

The first mapping object, balances, will hold the token balance of each owner account.

The second mapping object, allowed, will include all of the accounts approved to withdraw from a given account together with the withdrawal sum allowed for each.

As you can see, the value field of the allowed mapping is by itself a mapping plotting account address to its approved withdrawal sum.

These mappings together with all other contract fields will be stored in the blockchain and will be mined resulting in changes being propagated to all network user nodes.

Blockchain storage is expensive. It costs gas that users of your contract will need to pay for. Where possible, always try to minimize both storage size and writes into the blockchain.

Now that we have the required data structures set, let’s continue and actually write the ERC20 logic into the appropriate functions.

Get the total number of tokens

There are several approaches to setting the maximal number of an ICO tokens and, in fact, this issue might be worth a discussion by itself.

For our needs we will use the simplest approach, which is to set the total amount of tokens at contract creation time and initially assign all of them to the ‘contract owner’ account i.e. the account that deployed the contract:

uint256 totalSupply_;   constructor(uint256 total) public {     totalSupply_ = total;    balances[msg.sender] = _totalSupply; }

A constructor is a special function automatically called by Ethereum right after the contract’s deployment. You would typically use it, as we do here, to initialize the token’s state using parameters passed by the contract’s deployer.

msg is a global variable declared and populated by Ethereum itself, and which contains important data for performing the contract’s duty. The field we are using here: msg.sender contains the Ethereum account executing the current contract function.

Since only the deploying account can ever enter a contract’s constructor, what this function does is, at the contract’s startup, it allocates all available tokens to the ‘contract owner’ account.

Get total token supply

function totalSupply() public view returns (uint256) {   return totalSupply_;}

This function will return the number of all tokens allocated by this contract regardless of who their owner is.

Get token balance of owner

function balanceOf(address tokenOwner) public view returns (uint) {   return balances[tokenOwner];}

balanceOf will return the current token balance of an account, identified by its owner’s address.

Transfer tokens to other account

function transfer(address receiver,                   uint numTokens) public returns (bool) {   require(numTokens <= balances[msg.sender]);   balances[msg.sender] = balances[msg.sender] — numTokens;   balances[receiver] = balances[receiver] + numTokens;   emit Transfer(msg.sender, receiver, numTokens);   return true;}

The transfer function does what its name implies, which is to move numTokens amount of tokens from the owner’s balance to that of another user receiver. Note that the transferring owner is msg.sender i.e. the one executing the function, which implies that only the owner of the tokens can transfer them to others.

require is Solidity’s way of asserting a predicate, in this case that the transferring account has enough balance to transfer. If a require statement fails, the transaction is immediately rolled back with no changes written into the blockchain.

Right before exiting, the function fires ERC20 event Transfer allowing registered listeners to react to its completion.

Allow delegate to withdraw tokens from my account

function approve(address delegate,                  uint numTokens) public returns (bool) {   allowed[msg.sender][delegate] = numTokens;   emit Approval(msg.sender, delegate, numTokens);   return true;}

This function is typically used in a token marketplace context. What it does is to allow an owner i.e. msg.sender to approve a delegate account — possibly the marketplace itself — to withdraw some tokens from his account and to transfer them to other accounts.

A typical use case for this scenario would be an owner offering tokens for sale in a marketplace without having to need his own approval before the actual transaction takes place. At the end of its execution this function fires an Approval event.

Get number of tokens approved for withdrawal

function allowance(address owner,                    address delegate) public view returns (uint) {   return allowed[owner][delegate];}

This function returns the current approved number of tokens by an owner to a specific delegate, as set in the approve function.

Transfer tokens by delegate:

function transferFrom(address owner, address buyer,                       uint numTokens) public returns (bool) {   require(numTokens <= balances[owner]);    require(numTokens <= allowed[owner][msg.sender]);

   balances[owner] = balances[owner] — numTokens;   allowed[owner][msg.sender] =          allowed[from][msg.sender] — numTokens;   balances[buyer] = balances[buyer] + numTokens;   Transfer(owner, buyer, numTokens);   return true;}

transferFrom is the peer of approve function we have already visited. It allows a delegate approved for withdrawal to actually transfer owner funds to a 3rd party account.

The two require statements at function start are to verify that the transaction is a legal one, i.e. that the owner has enough tokens to transfer and that the delegate has an allowance for at least numTokens to withdraw.

Other than moving numTokens amount from the owner to the buyer, this function also subtracts numTokens from the delegate’s allowance. This allows a delegate with a given allowance to break it into several withdrawals which is a typical marketplace behavior.

If fact, we could stop here and have a valid ERC20 implementation. But we are aiming higher: we want an industrial strength token, albeit a simple one. This requires us to make our code a bit more secure.

SafeMath is a Solidity library aimed at dealing with one way hackers have been known to break contracts: integer overflow attack. In such an attack, the hacker forces the contract to use incorrect numeric values by passing parameters that will take the relevant integers past their maximal values.

SafeMath protects against this by testing for overflow before performing the arithmetic action, thus removing the danger of overflow attack. It is also really small so that the impact on contract size is minimal, so let’s use it.

First we will add it to our code:

library SafeMath { // Only relevant functions

function sub(uint256 a, uint256 b) internal pure returns (uint256) {   assert(b <= a);   return a — b;} function add(uint256 a, uint256 b) internal pure returns (uint256)   {   uint256 c = a + b;   assert(c >= a);   return c; }}

SafeMath uses assert statements to verify the correctness of the passed parameters. When assert fails, the function execution is immediately stopped and all blockchain changes are rolled back.

Next let us add the following statement introducing the library to the Solidity compiler:

using SafeMath for uint256;

and finally, we’ll replace the naive arithmetics we used at the beginning with SafeMath functions:

 balances[msg.sender] = balances[msg.sender].sub(numTokens);

 balances[receiver] = balances[receiver].add(numTokens);   balances[buyer] = balances[buyer].add(numTokens);  balances[owner] = balances[owner].sub(numTokens);

Let us now pack it all together

In Solidity, the contract’s functions and events are wrapped into an entity called a contract which you can silently translate to a “blockchain class”. Below is the ERC20-compatible contract we have thus far created. The name and symbol fields can be changed at will. Most tokens keep the decimal value at 18. We will do the same here:

Contract Deployment

We will now deploy our contract into the blockchain. Once deployed, the contract will be transferred to all nodes participating in the network and all changes made to the contract will be propagated to all participating nodes.

Ethereum professionals usually work with deployment tools such as Truffle.
For our need, a simple online tool called Remix will suffice.

You will first need to have a MetaMask plugin installed on your browser (which I hope is Chrome..) and a Rinkeby (Ethereum test network) account with at least some Rinkeby Ether in it. These two pre requisites are out of our current scope and also rather simple to do.

If you do not have any of them, feel free to visit MetaMask and Rinkeby
to get clear installation and usage directions.

Assuming we have the prerequisites set we will now go to Remix and paste the code above including the pragma line and the SafeMath library into the online editor.

After this, we will move to the 2nd tab ‘Run’ on right panel and click ‘Deploy’. A MetaMask popup will appear asking us to confirm the transaction which we of course will.

• Green marker: Make sure you’re on Rinkeby network
• Blue marker: Set total token supply
• Red marker: Deploy!

Congrats! You have just deployed your first ERC20 token. It is simple yet fully functional, standard compliant, secure and ready to be purchased, paid with and transferred throughout the Blockchain network!

Is that all there is to it?

Not at all. Smart contracts can get way more complex depending on your business logic, your modeling of the user interaction, on whether or not you allow token minting and burning, on lifecycle changes you introduce into the contract, on the need for admin-level capabilities which usually comes with admin-authorized set of functions and… well you get the picture.

Still, what you have achieved here is a solid base to move on from when a more complex contract is needed.

Hopefully it was also just a bit fun.

The internet is going crazy about this new buzzword called “Blockchain.” I am sure you have heard about it too, from your friends, investors, users or team members. As a technology, blockchain is so new and popular that people don’t have a proper idea about it and its applications.

In this article, let me help you correct the ten misconceptions about blockchain on a superficial level.

1. Cryptocurrency is the only application of blockchain

Creating a cryptocurrency seems like the most popular and viable application of blockchain today. This is also an easy way of making money by launching an ICO (Initial Coin Offerings) where investors buy your virtual coins with fiat currency or other coins like ETH, BTC, and so on.

Starting an ICO and making money quickly definitely looks tempting and is one of the reasons why it became massively popular. Take a look at the top 99 cryptocurrencies in the market right now and their current value, 99coins.

On a side note, the ease of launching an ICO opened doors to many scams like the “Vietnamese Modern Tech” scam, where a fake company raised $658M by promising to build tech internet giants in the country.

But in reality, there are multiple real-world applications of blockchain, and cryptocurrency is just one of them. Here are a few of them:

1. Healthcare: Blockchain can help us keep health records securely with proper timestamps, so they don’t get lost. The current health care systems have a massive amount of data, and they aren’t managed and connected to the internet properly.
2. Banking: Blockchain can help in cutting costs of settling transactions involving bonds or other financial instruments. It can help in sending money to countries where banking facilities aren’t a viable option.
3. Distributed Cloud Storage: Today, the photos and documents we upload to the cloud (Google Drive, iCloud, and so on.) are all centralized and, and everything is controlled by an organization. With blockchain, we can take full control of our data, encrypt and store them, and access them securely.

Tip: ? If you want to launch your own ICO in a few minutes without any coding, check out TokenLauncher, created by Sandeep and me.

2. The blockchain is the solution to all the problems under the sun!!

“If all you have is a hammer, everything looks like a nail.”

Just like the above quote, all the applications in the world needn’t involve blockchain. Blockchain comes with the concept of keeping the data or transactions decentralized. This means all your data is recorded forever in a network of computers. Data, once sent to a blockchain network, cannot be deleted or removed from all the systems. So, if you are thinking to build a decentralized network, think again!

3. Bitcoin is Blockchain

The blockchain is the technology that powers Bitcoin. Bitcoin is also one of the first applications of blockchain that went popular. Therefore, many people assume that Bitcoin is blockchain.

Bitcoin was initially created as an alternative, decentralized payment method. However, as the supply of Bitcoin is limited, the value has increased drastically in recent times. Today, Bitcoin is considered digital gold and people treat it as an asset rather than a mode of payment.

4. Smart contracts are legal documents!

No, they are not! The smart contract helps eliminate the need to pay intermediaries (Middlemen) and saves time and complexity. Think of them as self-executing code blocks that reside on the blockchain that no one can tamper with. However, smart contracts cannot be served as a legal document like Bonds, and so on.

5. Blockchains are always public

A public blockchain is open-source and accessible to all, and no one is in charge. Anyone can be part of the consensus in a public blockchain. However, all blockchains need not be public. You can make or create a private blockchain for your closed group of people.

In a private blockchain, the owner is a single entity or an enterprise and can delete/override commands on a blockchain, if needed. The private blockchain is also faster, cheaper, and requires less energy to operate.

6. Blockchains cannot be linked together

Most of us assume that blockchains cannot communicate with each other. Well, it’s not our fault. That’s how blockchain was implemented, initially.

However, it’s entirely possible to send data between blockchains. Cosmos, a company which is building the future Internet of Blockchain, is trying to bridge the gap between multiple blockchains by enabling them to exchange data easily.

7. Proof of work is the only way of achieving consensus

As a group of people/nodes run blockchain, they need a way to agree before committing a transaction in the network. In simple terms, the consensus is a dynamic way of reaching agreement in a group.

The most common form of consensus is “Proof of work,” where every miner has to solve a difficult problem. The reward is given to the first miner who solves each block problem. However, it’s extremely expensive and requires a lot of power to run. Hence, people invented other types of consensus. Read about various types of consensus protocols here.

Two popular alternatives to POW are:

• Proof of stake: a node/person can mine or validate block transactions according to how many coins they hold. Which means the more coins owned by a miner, the more mining power they have. Example: Neo
• Delegated Proof Of Stake: people in the blockchain vote for witnesses who are paid for their services. The top witnesses even earn a monthly salary. The amount of stake a person has determines the power of each vote. This means people who have more tokens will influence the network more than people who have very few tokens. Any witness who’s not doing their job is thrown out and replaced with another witness. Example: Steem, Lisk, and so on.

8. The Blockchain network can shut down if the creator is no longer interested

A public blockchain network cannot shut down easily. Since a blockchain is decentralized and no single authority controls it, it’s very difficult to shut it down unless all the participants in the network stop working. In most cases, it’s nearly to impossible to shut down a public blockchain.

9. Mentioning “Blockchain” in your pitch deck guarantees funding

Many people around the world want to jump into the hype train and make money out of it. We see this trend every year with new buzzwords. In 2016 and 2017, it was ML and AI. In 2018, it’s Blockchain. ?

If you are raising money without thinking deeper, the product is destined to die as the market stabilizes itself. So, beware! An investor wants a return! ?

10. Only geeks and nerds can use Blockchain

Even my cat can use Blockchain!

You don’t have to be a nerd to use blockchain. For example, to send or receive Bitcoin, all you need is a wallet that supports Bitcoin transactions, a public address, and a private key! Make sure to keep your private key secret. It takes a few seconds to create a new Bitcoin wallet. Get your wallet here.

(Bonus)

Blockchain === DLT (Distributed Ledger Technology)

Many believe that blockchain and DLT are the same. However, this is not true. DLT is an umbrella term used to refer to technologies that distribute information among multiple nodes. By this logic, we can say blockchain is a fully functional Distributed Ledger Technology.

Other protocols such as HashGraph, Nano, IOTA (Tangle Network) and so on are also DLTs, but they are not blockchain.

So, blockchain and DLT may be synonymous, but they aren’t the same. Rather, blockchain is a type of DLT.

Conclusion

I hope I was able to clear any misconceptions you might have had about the blockchain. If I left any out, please leave your comments below.

PS: I am not associated with any blockchain products that I have mentioned in my article.

PPS: My team and I are building a friendly community for developers called Hashnode. More than half a million developers hang out and discuss programming every month. Make sure to follow popular crypto communities to stay in the loop.

What a great time to be in the tech industry! It’s never been easier to raise funds for a new startup. Well, maybe during the dot-com era, but most people of my generation — those born after 1985 — were too young at that time to build a company.

For those of us Millennials, it’s never been easier to raise funds for a new startup!

2017 has seen the rise of ICOs (Initial Coin Offerings). ICOs are a novel way for teams to raise funding in exchange for tokens that are (or will be) used to interact with the company’s product. Through the sale of tokens, startup teams can get the funding they need to further develop their products without having to give up control to investors. Instead, they get the funding by selling digital tokens that at some point should be useful within their platform, hopefully holding — or even increasing — their value.

The early days of ICOs were a success, and in most cases, they raised millions of dollars each in a matter of days or even hours. As these results started to make headlines, more people started jumping on the ICO bandwagon. It didn’t matter what the product was, or even if it made sense to build those products using Blockchain technology.

Eric Risley’s article, Tale of Two Worlds, shows that ICOs are failing to raise the funds they intended to raise as the months go by.

The chart he published goes from June to mid-September 2017, but given how exponentially this trend has evolved, I bet it has only gotten worse.

ICOs were bound to start missing their targets. There’s currently an over-saturation of ICOs, as can be evidenced by looking at the popular listing sites. Many of them spring out every day. And many of them are garbage or outright scams.

I’m not going to go over what makes an ICO potentially dangerous to invest in, as it is not the point of this article. But there are many telltale signs, such as ridiculous caps, non-existent MVPs, shady founders and unknown advisors. It is worrisome — but interesting to analyze — given how many of them still do manage to raise some money despite all the red flags.

Alongside these failed ICOs that miss their targets, there’s a new problem starting to manifest in this industry. Some ICOs successfully raise the funds, but either fail to fulfill their promise or directly vanish with the funds they raised.

_Photo by [Unsplash](https://unsplash.com/photos/ZbZ5KP7D9z8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Patrick Tomasso on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

The most recent case is Confido. In November 2017 they managed to raise almost $400,000 through an Initial Coin Offering and simply vanished with the money. They took down the site, deleted their profiles from social networks, and ran away with the funds they had collected. ? ? ?

If the number of scams and failed ICOs keeps increasing, it’s going to take a toll on the Ethereum community and make it harder for honest founders to access this method of funding.

So, what can we do, as honest founders, to reassure potential contributors/investors of our good intentions?

Currently, most ICOs have outrageous hard caps — typically 10 or more times the funds that any company would need to build a tech product. We are raising tens of millions of dollars to launch products that could be accomplished with a few hundred thousands.

I know, ICOs might soon be dead or the bar might be raised so high that it’s impossible for smaller teams to raise any funding at all. So, better to seize the moment and ask for as much as you can, right? It’s not like you are giving more control of your company by asking for 10 times the money you need.

Well, I firmly believe that at some point we won’t be able to raise funds as easily as we can now. We will be asked for more accountability. The market will accommodate, and we will need to up our game in order to be able to do successful ICOs. One of the first things I believe we will be asked to do is to restrict our access to the funds to prevent hit-and-run Confido-like outcomes.

You want to raise 100 million dollars? Perfect, go ahead. But you will only get $500k right after the ICO.

Need more? Show us some progress.

Haven’t shown some considerable progress for months? We’ll take what’s left of our money back.

Building a Milestone-based Vault for ICOs

_Photo by [Unsplash](https://unsplash.com/photos/FqaybX9ZiOU?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">James Sutton on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

The complete, fully-commented, code can be found on my Github repository. Please refer to the README.md file for detailed usage instructions.

The MilestoneVault is a smart contract implementation of a vault that stores the crowdsale’s contributions and releases the funds as project milestones get completed.

Once the crowdsale has finished, the funds are stored in this vault. At any moment, the team can request a portion of those funds — as previously defined — and the original contributors can cast their vote against that request. If the majority rejects the request, the funds are not made available.
If the founding team makes several requests and they keep getting rejected, the project gets cancelled and contributors can get a refund on the money that hasn’t yet been withdrawn on previous milestones.

As I started working on this project, I realized there was not just one right solution. There are many ways this can be achieved depending on how the founding team wants to handle it, and what the community is willing to tolerate. For example:

Initial contributors VS token holders

My current implementation allows the ICO contributors, instead of the token holders, to vote.

A person’s investment in a project is represented by the tokens they got in exchange for their contribution. But I don’t think that, after the ICO, the token holders should have a say on the future of the project. After the ICO, owning tokens don’t necessarily make someone an investor or a supporter of the project. I could have the tokens for mere speculation and not care about the project at all.

On the other hand, as an early contributor to the ICO, I might have already sold my tokens along the way and couldn’t care less about the current and future state of the project.

There could be a third option that takes into account only the votes from early backers that still have all, any, or some portion of the tokens. But I felt this would over-complicate the smart contract.

One person, one vote VS weighted votes

My current implementation is based on weighted votes.

This means that the size of the original investment is taken into account when voting. If I invested 3 ether, my vote will matter more than the vote of someone who invested only 1 ether.

Approval voting VS disapproval voting

My current implementation is based on disapproval voting.

When the team initiates a request for funds, a voting period is started. During that voting period, contributors to the ICO can vote against the request for withdrawal for the current milestone. If the majority votes against, then the request is rejected.

This could be changed so that the request is not approved by default, and the team has to get enough positive votes in order to unlock the next milestone.

Again, I don’t feel that this is a case where one-solution-fits-all applies, and I’m not claiming to know how these choices would affect the project in the long run. Depending on the nature of the project, the composition of its community and contributor base, and many other variables, the voting system could be modified to better represent all parties and prevent issues.

What about disputes?

_Photo by [Unsplash](https://unsplash.com/photos/DCtwjzQ9uVE?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">CloudVisual on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

There’s one final topic I’d like to discuss. My inspiration for looking into this subject and thinking about ways to make ICOs a bit more transparent was this post by Federico Ast, one of the founders of Kleros.

In his article, Federico writes how he thinks ICOs should work:

During the crowdsale, backers from all over the world send payments into a smart contract which will release payments to the team as some predefined milestones are met. For example: “Next payment will be done when the team releases a new version of the software with substantial improvements”.

When the team claims a milestone is reached, token holders have some period of time to dispute it. If a sufficient amount of token holders reject the milestone completion claim, a dispute arises between the team and the token holders (Was the milestone met? Should the money be released?). Kleros is the dispute resolution mechanism.

As it stands today, the solution I propose could be subject to some abuse from the contributors. They have the final say in whether or not the project gets further funding, and there’s no way to refute their voting. They could even collude to cut off the project’s funds and get their money back if, for example, the tokens are worth much less than the money they put in.

As Federico writes, a dispute resolution mechanism could be put in place so that each time the contributors decide to withhold the funds (or right before deeming the project cancelled), the team can initiate a dispute, present their evidence, and get objective third parties to decide what to do.

I believe that ICOs are a great fundraising mechanism that will enable awesome companies to be born and thrive, but we must do our best effort to use this great tool consciously.

What other mechanisms do you think could be put in place to provide more security for ICO investors?

I hope you enjoyed reading this article as much as I enjoyed writing it. I’m currently taking consultancy jobs related to smart contracts development. If you are planning on raising funds through an ICO or building a Blockchain-based product, feel free to get in touch with me.

If you still don’t get what the heck a Smart Contract is…

Ok, you know a bit about Bitcoin (see: Explain Bitcoin Like I’m Five). You’ve been seeing the blockchain on the news.

But what’s this new Ethereum thing? Apparently it’s this crypto-currency you can use to build “smart contracts”. Sounds impressive. So, uh… what are they again? (Spoiler: They’re not that smart. And they’re not really contracts!)

Instead of a one line definition, let’s try to get an intuition. First, we’ll revisit the blockchain and the word “trust”. Then, we’ll talk about the word “contract”. Understanding both words is the secret.

Part I: What we mean by “Trust(less)”

Most of the time, when we think Bitcoin (or Ethereum), we have a mental image of, well…coins.

Aren’t these crypto-currencies after all? Isn’t that the whole point? In our minds we see objects — digital gold, or silver (or tulips for the skeptics).

Because these images are easy to understand, we forget a bit about that thing that’s underneath it all. So, I say we start thinking about this in a different way.

Digital Stone

Ugh, really? Digital rocks? Actually, rocks are pretty useful.

We have this idiom in the english language that goes something like this: “set it in stone.”

“I’ve reviewed the contract Bob. Looks good. Let’s set this in stone!”

“Don’t get too excited Alice, nothing’s in stone yet.”

“This is God. I’ve written my 10 commandments on these two stone tablets. You know. Just in case ya'll start getting any funny ideas.”

This metaphor continues to have meaning in a modern world because in the physical (ancient) world, stone had some interesting properties:

1. When you carve something on stone there is a physical finality and permanence to it. You can’t make changes just like that.
2. If you try to “erase” something later on, it’ll be obvious. Any changes you make to it are quite transparent and tamper proof (provable).
3. These rules apply equally to all. Stone is neutral. It obeys the laws of physics, not men. It doesn’t care if you’re a powerful king or a peasant — it behaves exactly the same for everyone.

Because of all these properties, we have a pretty high level of trust in stone.

I mean — there’s a reason why we never say “let’s set this agreement in sand.” Stone is the kind of thing I can point to in the future for evidence. Stone equals solid proof — not just any material will do!

_[The Economist](http://www.economist.com/news/leaders/21677198-technology-behind-bitcoin-could-transform-how-economy-works-trust-machine" rel="noopener" target="blank" title=") agrees!

When it comes down to it, a blockchain is really just the above: a kind of material that, through a special mix of cryptography and decentralization, has the properties of permanence, transparency, and neutrality — whatever you put on it.

Whether it’s a list of how many apples you sent to Joe. Or the words “I love Jenny.” It doesn’t matter. When you put it on a blockchain — it’s on.

Setting something on a blockchain is like setting something in stone. It makes trust easier.

Except now we can do it digitally. And that’s pretty special.

Thinking about a blockchain as a piece of stone you can write things on (instead of a piece of currency) also helps us understand its broad potential. Which leads us to…contracts!

Part II: What we mean by “Contracts”

The word “contract” has a lot of baggage. We start thinking: legal documents and lawyers.

The go-to description used in the news is a bit better: things that self-execute or execute automatically. That seems vaguely familiar though. After all, there’s really nothing new about automation or execution.

The great grandfather of smart contracts

Take your good ol’ office vending machine for example. It’s a “stupid” machine that does what it’s told, and executes things automatically. It’s been around for decades!

Behold, the magical machine that spits out high-fructose sustenance.

Let’s pretend one afternoon you find yourself in front of this machine. It says: “If you give me $2.50, and press this button, you will get a Diet Coke.”

It might not actually say those words anywhere. But that’s the promise of this little interaction. One might even call this a kind of simple agreement. (You can guess where this is going.)

You feed in the money. Press the button. Presto! Bottle in hand, you forget this meaningless event in your life 2 seconds later and start worrying again about those darn TPS reports you forgot to do.

Well, you didn’t notice, but this whole thing was actually a small program(“contract”) coded(“written”) into the machine beforehand that ran when you hit the button(“signed off on it”). Something like:

> if money received == $2.50 >     && the button pressed is "Diet Coke"> then release Diet__Coke

Computer code, as you see, is kind of like a contract.

It’s making statements and declarations. There are terms (if you do this…then…). And just like someone you trust — it even fulfills its end of the bargain!

Voila. Contracts are just code. But unlike a “contract” in English, this is something both humans and machines can read. Extra fun!

Ok, but…

Now you’re more confused about this smart contract business. As we said, this is nothing special. In fact, as the vending machine demonstrates, this kind of code is already everywhere in our daily lives. If a smart contract is just “if…then” code (or any code for that matter), then what’s the hoopla? What’s actually new?

Vending Machines 2.0

One sunny day, you spot a vending machine sitting on the corner. You’ve never seen this one before!

You walk over and take a look. This machine says: “If you put in $1,000 this machine will give you $5,000.”

Whoa! Whoever put this machine together must be very rich and generous.(Or insanely stupid…). Either way. 1k for 5k? No brainer — that’s a deal you’ll take any day! Right?

This is exactly like our good old Diet Coke machine. Same logic. Same if-then process.

Except now the stakes are different. You reach for your pocket but suddenly, you feel hesitant. Who the hell put this machine together anyway? And what if it eats your money? $1,000 isn’t a small amount — you were saving that for months. You didn’t think twice about that Diet Coke. But now? Now you realize that maybe vending machines aren’t that simple.

You start thinking about trust.

How do we know it has enough funds to spit out the promised $5,000?

How do we know the code is going to run?

Is there any way to publicly and transparently verify this code?

Conclusion

The $5,000 vending machine is an extreme, theoretical example but it does hint at the problem with scaling trust. In an expanding, digital world where people can connect anonymously — trust becomes a tricky thing. We usually rely on third-parties and other middle men for that reason. We have to. Especially if we’re moving things way more valuable than Diet Cokes. You know, like newfangled financial stuff. Or the very idea of “value” and “ownership” itself.

Hmmm. If only you could marry the automation of traditional programming and the trust-worthy properties of digital stone….

Well, that is exactly what a smart contract is! It’s just code — with a very special kind of backing.

Keep in mind, we’ve had both computation and execution before. But never one that was finalized in a neutral, provable, trustable way on (digital) stone.

How about the real world? A few ideas.

Online Gaming: Fight fraud on gambling sites. Are the odds of that dice roll you just did actually 1 in 6? How do we know they’re going to pay out? Well, why not “set the code in stone” and prove it? A live example.

Supply Chains: Maybe track and verify where and how things are made?

Voting: Maybe a tamper proof voting process?

Decentralized and Autonomous Companies: Sci-fi time.

Throughout history, automation has always been applied to the bottom of companies. The assembly line. The factory worker. But if the rules of a corporation are just a kind of operational logic— then isn’t it possible to flip the pyramid and instead automate the top?

These are only a few examples of what you could code on a blockchain using Ethereum’s Turing complete programming language. We’re only at the beginning. If you dream it, you might be able to code it.

And in many ways, that’s what makes this whole thing exciting. We have some guesses, but honestly — we have no idea what will be built in the years and decades to come.

All we know is that the building blocks are here. And it is open to all. The rest is up to you.

Ready to go down the rabbit hole?

• A Beginner’s Guide to Ethereum
• Crypto-Tokens: A Breakthrough in Open Network Design (Chris Dixon)
• The Idea of Smart Contracts (Nick Szabo, 1997)
• The Other Side of the Coin: A different perspective on cryptocurrencies