Skip to main content


Culture, team, and games amidst the World Cup

blockchain gaming

The World Cup is here and at Mighty Block we love football. As most of our team is Argentinian (me included) and we cannot help our fandom for our national team. We’ve been waiting and preparing for this event for months and we created a betting smart contract football game for it, exclusively for Mighty Block’s team facilitated by blockchain technology on the Polygon blockchain with a smart contract. How did this project came to be? Follow me on this adventure as I tell you the tale of this game and how company culture helps to build amazing things while having fun and being responsible.

The “prode”

During the World Cup it’s very traditional that every group of friends would have a ‘dealer’ that would organize what we call ‘Prode’. This is basically a betting game that consists in everybody submitting their guesses on match results and some type of point system is set up, for example:

  • 10 points if you guess winner and scores
  • 7 points if you guess winner and one of the scores
  • 5 points if you guess winner but not score
  • 2 points if you guess one score but not winner
  • 0 points otherwise

This same person gathers money (the same amount) from everybody. After all matches have been played, the group gathers, the ‘dealer’ shows the results and rewards the winners (usually first, second and third places) with all the money gathered.

This system is heavily dependent on the ‘dealer’ keeping everything orderly and transparent, usually this ends up with discussions about rules, points, how much money was gathered, if the dealer changed any result, etc. This leads naturally to:

  • Ban this type of betting in a professional setting (since it can create issues between the team) or change the dynamic of the game, where the company funds the reward and there’s not betting per sé.
  • Ban the ‘dealer’ from participating in the betting.
  • Even when all the above happen, there is still a sense of distrust in the dealer after the game ended.

As the World Cup was getting closer and closer and everybody at the office started gossiping about the players, the news (and even one of our coworkers went to Qatar himself!) a light bulb went on. What if we make this heavily centralized and ugly betting game into a trustless system facilitated by Blockchain and Smart Contracts? (A smart contract football game!)c.µ.

Just like that, our minds started running, we were thinking of ways to make this happen. How would it look? Where do we take the results from? Do we use an oracle? How do we split the reward? What would happen if there is a tie?. As programmers we could not help our anxiety in any other way than coding the damn thing. 

We spent 4 hours making this solidity Smart Contract in the dirtiest way possible, following no guidelines of clean, scalable and sustainable code. After all it was an MVP of a joke, we were not planning to really do this, right?

Ok, let’s back up. How did we end up here? Why on earth are we working on an MVP of a joke instead of working on our clients needs on company time?

Mighty blocks culture policies

At Mighty Block we take culture very seriously. A very important exercise was done approximately 6 months ago, were HR gathered ‘the most important thing that you value from a teammate’ and distilled a list of core values that we as an organization value.

At first sight, it doesn’t sound at all special. Just another set of empty words that nobody follows. Well, this is where Mighty Block makes the difference. 

You can read more about that process here, but TL;DR, the HR team listed the things that we REALLY value, not just a poster on a wall, these are the things that we want to keep and grow:

Quarterly face-to-face workshops

Mighty Block is a fully remote company, we have teammates all around the world yet once a quarter we try to meet face-to-face. Our HR team makes a great effort to make this week as productive, fun and fulfilling as possible. These meetings really help to spark inspiration and to show our new team members how we put into practice the core values. It’s not forced indoctrination, rather it’s simply making how we work transparent to the whole team and since our core values express that, the newcomers can sense and learn that.

What does all of this have to do with the ‘Prode’ project? Well, everything. Our ‘real’ project (the one our client was paying for) was under control and the client was happy with our productivity at the time. We were not crunching nor under a lot of pressure. On the other hand, we were sure that if the Prode project failed, nobody would tell us off, it would go against most core values and if we succeeded building the Prode and found ways to circumvent all the issues, Mighty Block would support us and facilitate all the resources needed to make it happen. 

It was a can’t lose type of situation

Only in that state of mind can you make progress in a relaxed, healthy, fun and productive manner. It was not only important, it was the key for being able to make this project a reality, otherwise it would have been a comment, a joke, a thought, but never a real thing.

The smart contract was just the beginning

Writing the smart contract was just the beginning of our adventure. After this rush of adrenaline and inspiration we had a rough, untested and dirty smart contract that did the thing. We had a Prode v0.1. After making sure that no big barrier would prevent us from making the World Cup Prode a reality, we pitched our smart contract football game idea with HR, they loved the project and we started thinking on what else we should add. Ideas started flowing, adrenaline went down and we planned our next steps.

How to make this work in a professional setting? The smart contract plays the ‘dealer’ role here, so that helps a lot but also Mighty Block funded the prize. So no betting, just a company game.

Uri and Boro coding

But interacting with a smart contract is a very annoying thing, we needed a frontend and that’s where the rest of the team comes to play. Most of the development of this project happened in the span of 5 days, during one of our quarterly workshops. While Ignacio and I were writing (and now testing and refactoring) the Smart Contract, the rest of the team heard our conversation and started asking questions, everybody was excited to try it!

Julian, our frontender, was one the excited coworkers, he offered to build a frontend for us. He had no experience making a dApp, so it was a learning experience for everybody involved. I helped to connect the frontend with the Smart contract while Ignacio was finishing tests and HR was deciding the proper prize.

During Julian’s process he had questions about UX, Constanza, our UXer, helped with that. 

Juli working on the Smart Contract Football game frontend

Overall it was a team project, a great experience not only for building the technology and then playing with the game we created on real time during the world cup, but also a bonding experience. Next time I have a question I’m more confident asking Constanza, Julian or Ignacio. The whole team sees this vibe of having fun and building stuff together, and wants to join in, the best example of this is our participation rate of 95%, almost the whole team played the game. This is a positive feedback loop that we need to nourish and nurture, that’s our philosophy, that’s why we have core values and that’s why we do what we do.

Follow us

Why Devcon is the most important event for web3 developers


Last month the sixth edition of Devcon was held in the city of Bogotá in Colombia. But first…

What is Devcon?

Devcon is a global conference for Ethereum developers that was created in 2014 and is held every year in different countries and continents:

  • Devcon 0: Berlin (2014)
  • Devcon 1: London (2015)
  • Devcon 2: Shanghai (2016)
  • Devcon 3: Cancun (2017)
  • Devcon 4: Prague (2018)
  • Devcon 5: Tokio (2019)
  • Devcon 6: Bogotá (2020)

2020? Well… It was planned for that year but you can guess what happened. Therefore, this edition was not just another edition: it also meant its definitive return. Because of this, people came from all over the world and that leads me to the next paragraph.

Devcon - The most important Conference
Devcon – The most important Conference

People from all over the world

The fact that it was the return to face-to-face was a great attraction for people from all over the world. Networking opportunities and meeting new people are for me the best things about attending this kind of conferences. You can have a coffee and also an interesting conversation with people who are not from your circle of acquaintances and may not even live on your continent. And there are also specific and funny spaces to generate new links and conversations…

Side events

These meetings are happening around the conference. Events can be from breakfast to after office and even rave parties. It is a great time to generate more informal and relaxed conversations, but it also provides opportunities to discuss technical details and do business. If you were busy watching presentations at the conference, side events are the right place to chat. Regarding presentations, if you were busy there it was because…

First class speakers

The best-known experts in the Ethereum world as Vitalik Buterin were on the grid of this conference. In addition to the technical content, it was very valuable to have the opportunity to approach a speaker and interact directly on the topic of the talk. This is clearly not an option in virtuality. Most of the experts have been present at events prior to the Devcon such as…

EthBogota and EthLatam

EthBogota is one of the hackathons organized by the Ethereum Foundation. It was the weekend before Devcon so the people could attend both events on the same trip. More than 1000 people participated in this competition with more than 500K USD in prizes. The day before the Devcon, a special event was held for the Latin American community that had already had an edition in the city of Buenos Aires: EthLatam. Both events added to the Devcon gave the opportunity to bring many experts closer to a region that seems to emerge as a point of interest…

Latam as a point of interest

Latin America is one of the regions with the highest adoption of cryptocurrencies and blockchain-based projects partially due to economic needs but mostly due to a high technical level and a great capacity to undertake. It is very interesting to see the projects that have come out of this region, such as OpenZeppelin. One of the remarkable progress was in digital identity, and one of the most interesting topics discussed in the conference was Zero Knowledge Proof…

ZK is the future

Something that surprised me was to see a lot of technical content on this topic. Undoubtedly, it is something that will be critical in the coming years and that all of the projects will adopt in one way or another. My recommendation if you are in the web3 industry: learn about Zero Knowledge Proof.

Personal opinion

Personally, it was a great satisfaction to attend the event, being face to face one more time with the community and of course meet new people. The technical content was outstanding, but I must confess that I have to rewatch a lot of the talks to get the most out of them (I think I should do it more often). If you haven’t had a chance to go, stay tuned for next year, and don’t forget to contact me for coffee and a chat there.

Upgradeable Contracts: An introductory guide

One of the first things we learn in Solidity/Ethereum is that contracts are immutable. If you upload a contract on the blockchain, you can’t change its source code and therefore you can’t change its logic.

We must be extremely careful with the code we use: if we make one simple mistake it could be extremely expensive. That’s why we consider alternatives as a way to avoid this limitation. Let’s see how we can use an upgradeable contracts.

Contracts Old School

The simplest thing we can do is upload a new version of the contract (and thus a new deploy and a new address). But this has its issues, for example let’s think about what it was like to have a shop a few years ago (before the internet). If we wanted to move to another address, we had no way of notifying all our clients and potential future clients of this change. The same thing happens in smart contracts, all users must know that the address has changed, but not having a user registry makes it very difficult.

Example no upgradeable contracts

Ways to create a upgradeable contracts

There are currently 4 ways to create an upgradeable contracts.

Using an interface / proxy

Taking advantage of inheritance and polymorphism, an interface with the contract structure can be exposed. So now we have two contracts: one with the contract definition (and external calls) and the other with the function’s implementation. The user interacts with the contract through the interface and if an update is required, the address of the contract is simply changed for the new version in a simple variable inside the contract.

Example upgradeable contracts

It is not possible to modify the contract’s structure since we MUST respect its interface, but its main disadvantage is that the stored values ​​will remain in the contract that has the logic, and if we want to update it with that of another contract, we will lose the storage state.

What is done to solve the storage issue is to have a “proxy” contract that has the same structure as the one with the logic, and it is accessed through the delegatecall instruction. It is SUPER IMPORTANT to keep the same variable structure in the contracts since we will be sharing the storage, and if both do not have the same variable structure, a collision could occur. A possible solution for this is that they both inherit from a base contract that sets the same variable-structure for all of the contract versions.

It seems to be a better alternative but in terms of gas it is expensive: we are always adding variables that we will most likely never use in every logic contract we implement. This can be improved if a third-party storage contract is used, for this, we can use solutions such as OpenZeppelin or combine it with an unstructured storage.

OpenZeppelin Transparent Proxy

If you are a user of the OpenZeppelin contracts you have noticed this plugin for sure. Inside, it uses a mechanism known as Transparent Proxy, which uses unstructured storage to avoid collisions (as long as we add the variables at the end and never at the beginning). This proxy is already integrated as a plugin and is compatible with Hardhat and Truffle.

Link here

Diamond Pattern

This is one of the most popular and most complex, since we have an intermediary contract, but instead of aiming for a single final contract, each function will be implemented in a different smart contract. In addition, each “Facet” contract (as they are called) will have a fixed memory space to avoid collisions. A major advantage is, a whole contract deployment is not required, just a contract with one function implementation. That’s cheaper than deploying a complete-structure contract with all of the functions and also as there is just one function per contract, the size limit is very hard to reach. It is undoubtedly the favoured solution for the complex scenarios that are created today and there is even an EIP that refers to it.

Link here

Syntethix Router Proxies

At ETH Latam event, Alejandro Santander (known as The Ethernaut) presented a solution called Router Proxies. It is quite similar to the Diamond Pattern, but simpler. I recommend watching this talk!

Link here

Video here

Metamorphosis Smart Contract

What? Well, we are not actually modifying the contract, but if we had the ability to remove the contract from storage, we could force a deployment to that same address, then replace one contract with another. And this is how this technique works. Through the selfdestruct() statement, it is possible to remove a contract from the blockchain storage, and using the create2 operation, a new version of the contract is deployed to THE SAME ADDRESS.

Link here

Ok, but… is it okay to modify a Smart Contract?

In centralized software, not only is this not a bad thing, it is a necessary thing. What happens in decentralized projects? Who should update the code? Is a DAO reliable enough? On the one hand, an immutable contract seems more reliable than an upgradeable contracts but it also makes it more vulnerable to attacks. In my opinion, it is good to consider all these alternatives and use them if the project requires a sophisticated architecture. Making a contract upgradeable makes its code much harder to understand and trace, but improves its resistance to attacks. If the strength of a project is its simplicity, I would not work on making the contract updatable, but I would do so in complex projects with multiple contracts.

Token Standards: ERC20 vs ERC721 vs ERC1155

Blockchain Technology is slowly taking over the world. People have finally started to understand the issues with centralization, and thus the importance of this one paper by the anonymous entity Satoshi Nakamoto, which started this revolution of cryptography and decentralization.

In 2015, with the Ethereum network going live, came a whole new world of possibilities in the decentralized space. The EVM machine which can execute smart contract was a game-changer. Consequently, the introduction of smart contracts made developers and experts all around, build platforms take on, probably the biggest “Ponzi scheme” of all times: The Traditional Financial System ( or fiat system ).


The rise of smart contracts, allowed users to create special contracts, which can act like currencies. A lot of these got released, and consequently, it was becoming hard to keep track of all these different standards of writing virtual currencies smart contracts on the network. Hence came in the proposal of ERC20 Standards:

This standardized how a token contract should look, resulting in the seamless integration of tokens in different protocols and crypto-wallets. This eventually gave birth to some amazing solutions in the decentralized finance or DeFi space like Uniswap, Aave, MakerDAO, etc. Today, billions of dollars worth of crypto are traded in this space.

So, what exactly do ERC20 Tokens represent?

ERC20 tokens are basically what we will call “Fungible Tokens”. Fungibility is the ability of a good or asset to be readily interchanged for another of like kind. Think of two 1 dollar notes. Both the notes are different, but their value is exactly the same. The same is the case in an ERC20 token. Each token is worth the exact same as the other tokens in value.

This consequently resulted in several applications of ERC20 tokens like stablecoins, governance tokens, but let’s not get into that in this post.


Ok, so the significance of ERC20 is clear, lets now get into ERC721.

So, what exactly does ERC721 represents?

Simple, an entity. It can be anything, which has its own value. An artwork, a music album, an agreement contract, etc. No two ERC721 tokens are the same when it comes to value.

ERC721 are what are called “Non-Fungible tokens”. Think of two ERC721 representing 2 soccer player:

First represents a high school student and one representing some popular figure like Cristiano Ronaldo. So now it’s clear that the card representing Cristiano would be worth way more than the card of the Highschool student.

But the big question, which stops a lot of people from getting into NFT is why even bother to buy a “digital entity” in the first place. The answer is pretty simple, think of it like this: Why does Mona Lisa cost so much and is considered so much valuable ?. The answer is as simple as that, people consider it to be a valuable piece of art that adds value to its existence.

The same is the case with NFTs. An NFT acts as proof of ownership over a piece of digital content or a digital asset.NFT’s are unique digital tokens that represent specific digital assets that can be bought, sold, and traded. The digital artists can ensure that the value of the art that they produce is maintained during its sale and also any future royalties that they may be owed.

“CryptoPunks” and “CryptoKitties” are two of the very first projects in this space. Some NFT art sites now allow the option of buying carbon offsets when making NFT purchases or contributing a percentage of revenue to offset programs

Check out for standard specifications.


ERC-1155 is what we will call the best of both worlds.

ERC-1155 allows you to create FungibleNon-Fungible, and Semi-Fungible in one single token standard. Both Fungible and Non-Fungible tokens can be created using the same standard.

So why ERC-1155?

Take, for example, Mona Lisa again. There is one Mona Lisa artwork, which is worth millions of dollars and can be represented by Non-Fungible ERC-1155. Now there can also be several other copies of the artwork, which can be sold as Fungible ERC1155. The ERC1155 gives accessibility, simplicity, and efficiency on the buyer side.

Another example use case can be games. You earn points and buy items using these points in a game. At the same time, you can exchange items too. The “items” can be represented by Non-Fungible ERC-1155 and “points” can be represented as Fungible ERC-1155.

Check out for the standard specifications.

Visit for more web3 news

Create an Ethereum token using open source contracts (open-zeppelin)

Mighty Block
Create an Ethereum token using open source contracts (open-zeppelin)

I want to show you that creating a best practice token is a simple process. To be honest, we are going to be doing some coding, but it won’t be much.

We’ll be using Solidity to create our Ethereum token. But don’t worry, there are a lot of open source libraries and contracts to help us in the process.

What we want is an ERC-20 compliant token. What that means is that the Ethereum developers have decided a set of functionalities that is necessary for your most common token usages today. There are other types of ERC standards, but we wont dive into it.


  • Github
  • Terminal
  • NodeJS
  • NPM
  • Metamask (For initial Account Creation)

Alright let’s start coding! The first thing we want to do is download truffleglobally. You can visit their repo at truffle and here’s the following snippet to install:

npm install -g truffle

Note: make sure you have the latest version of truffle if you installed this prior

Truffle will handle the smart contract compilation, linking, and deployment for us. It’s a library that will make our lives easier for this demonstration.

Now we need to create a directory where our project will live. In my case I called it ethereum_token_tutorial.

So we have two options here. Either you can clone the repo I have created by following this:

git clone -b initial_step

Or you can do this in your terminal inside of your new directory:

truffle init

If you followed the second option of doing truffle init. The directory should look like this:

etherem_token_tutorial|___contracts| |_____ConvertLib.sol| |_____MetaCoin.sol| |_____Migrations.sol|___migrations| |_____1_initial_migrations.js| |_____2_deploy_contracts.js|___test| |_____TestMetacoin.sol| |_____metacoin.js|___truffle.js

Go ahead and delete ConvertLib.sol , MetaCoin.sol , TestMetacoin.sol , metacoin.js.

So your directory should look like this now:

etherem_token_tutorial|___contracts| |_____Migrations.sol|___migrations| |_____1_initial_migrations.js| |_____2_deploy_contracts.js|___test|___truffle.js

Great. Now we’re moving. Truffle helps us compile smart contracts and deploy them. But we deleted our smart contract files other than the migrating helper. Don’t worry, this is where Open-Zeppelin comes in.

Open-Zeppelin is an open source repo where you can find smart contracts with generally best practices, good test coverage, and most likely audited*.

  • Audit is when you have professional developers review your smart contracts looking for any leaks, bugs, or possibilities of malicious attacks.

Here’s a link if you’re interested in smart contract attacks: Link

For us to use any Open-Zeppelin contracts we need to install it into our repository:

npm init -ynpm install -E zeppelin-solidity

We initialized a package.json with npm init -y. We also installed the package for using the Open-Zeppelin contracts.

Okay, we’re going to write some Solidity. I did mention in the article earlier that this will not be much code and I wasn’t joking!

Create a new file in the contracts folder. In my case I named it TestToken.sol

Now your directory should look like this:

etherem_token_tutorial|___contracts| |_____Migrations.sol| |_____TestToken.sol***(this one is new)|___migrations| |_____1_initial_migrations.js| |_____2_deploy_contracts.js|___test|___truffle.js

In TestToken.sol we need to have the following code:

// TestToken.solpragma solidity ^0.4.18;
import "zeppelin-solidity/contracts/token/ERC20/MintableToken.sol";
contract TestToken is MintableToken {    string public constant name = "Test Token";    string public constant symbol = "TT";    uint8 public constant decimals = 18;}

Let’s break this down since it’s quite a bit , even though it’s only a few lines of code.

pragma solidity ^0.4.18;

It is required at the top of the file because it specifies the version of Solidity we’re using.

import "zeppelin-solidity/contracts/token/ERC20/MintableToken.sol";

The above code snippet is why Open-Zeppelin is so useful. If you know how inheritance works, our contract is inheriting from MintableToken. If you don’t know how inheritance works, MintableToken has a lot of functionalities saved in inMintableToken.sol. We can use these functionalities to create our token. If you visit this MintableToken you’ll notice a ton of functions and even more inheritance. It can be a bit of a rabbit hole, but for this demonstration purpose, I want us to release a token into the testnet.

For us, Mintable let’s us create as many tokens as we want, so we won’t be starting with an initial supply. In my next article, we’ll create a nodejs service that will create new tokens, and handle other ERC-20 standard functionalities.

The next bit of code:

contract TestToken is MintableToken {    string public constant name = "Test Token";    string public constant symbol = "TT";    uint8 public constant decimals = 18;}

This is where we can customize the token. In my case, I named mine “Test Token”, with the symbol “TT”, and decimals of 18. But why 18 decimals?

Decimals of 18 is fairly standard in the community. So if we have one test token it can potentially look like this 1.111111111111111111.

Whelp. That’s all the Solidity coding we need to do for this token. We inherit all the main functionalities for a standardized ERC 20 token from Open-Zeppelin. After that we need to set our constants for the name, symbol, and decimals.

Before we forget, we should create a Metamask account and get it funded with testnet ethereum.

Go ahead and search MetaMask extension for Chrome, or follow this link

Metamask Extension for Google Chrome

After you install MetaMask you should see a series of steps. You can read through like terms of service. Eventually you’ll reach:

Metamask Password Screen

Input your password and confirm that password. On clicking create, you will see another screen.

Metamask secret

Make sure to save your seed words or copy them down into a text file. We will need those seed words to deploy the token onto the testnet.

Also more important is to change your test from Mainnet Test Net to Ropsten Test net. It’s on the top left of your MetaMask tab. Here is the drop down:

Testnet list

The reason we’re using Ropsten Test Network is because it’s the closest testnet/implementation of the Main Ethereum Network.

Next you will need to copy your address to clipboard from the ... menu like so:

Metamask Account Screen

You should have an address similar to this one copied to your clipboard:

address: 0x8EeF4Fe428F8E56d2202170A0bEf62AAc93989dE

This is the address from which we’re going to deploy our token contract. Now one thing you need to know about deploying contracts is that they cost Ethereum, to be specific Gas. We’re going to need to get some testnet Ethereum into our accounts.

Now that you have your address go to this Ropsten faucet link:

Ethernet Faucet

Copy and paste your address and soon you should have 1 Ethereum in your MetaMask wallet for your address.

Account with 1 ethereum

Just one more thing before we start coding our deployment process! We’re going to use a free API called

Infura — Scalable Blockchain Infrastructure
Secure, reliable, and scalable access to Ethereum APIs and IPFS

Sign up for their services. You should get an email from them or be redirected to a site with your API Key. The one we want specifically is from the Ropsten Network.

Test Ethereum Network (Ropsten)

Copy your API_KEY.

Almost there! Now let’s start working on our deployment. Let’s head back in our code.

First things first, let’s talk about security. Create a new file in your root directory called .env. Your file structure should now look like this:

etherem_token_tutorial|___contracts| |_____Migrations.sol| |_____TestToken.sol|___migrations| |_____1_initial_migrations.js| |_____2_deploy_contracts.js|___test|___truffle.js|___.env**(new file)

Inside your .env file lets add some environmental variables (these are variables that you can access anywhere in your code directory)


First add your API_KEY you copied into the file.

Remember the Mneomic(seed words) from initializing Metamask chrome extension? We’re going to need that now to deploy the contracts from. If you downloaded or wrote down your Mneomic, now write them down in your .env file MNENOMIC=SOME KEY PHRASE YOU DONT WANT THE PUBLIC TO KNOW.


We added a .env file!!! We need to add a .gitignore file now to avoid adding the .env to a public repository if you ever decide to make the code public!

Create a .gitignore file in the same directory as your .env. Now it should look like this:

etherem_token_tutorial|___contracts| |_____Migrations.sol| |_____TestToken.sol|___migrations| |_____1_initial_migrations.js| |_____2_deploy_contracts.js|___test|___truffle.js|___.env|___.gitignore**(newfile)

Inside your .gitignore file:

// .gitignorenode_modules/build/.env

We want to ignore node_modules/ because when we do npm install it will download packages from our package.json. We want to ignore buildbecause later on when we run a script, it will create that directory for us automatically. We also want to ignore .env because it has private information we don’t want to release to the public.

Great! Over in our terminal we need to add two more modules.

npm install --save dotenv truffle-hdwallet-provider

Since we’re putting in private information, we need a way to access those variables from .env, and the dotenv package will help us.

The second package, truffle-hdwallet-provider is a wallet enabled provider. Without this, we would need to download all the blocks or use a light wallet to make new transactions in the Ethereum network. With the wallet provider and Infura API. We can deploy instantly, also bypassing painful processes.

Over in the truffle.js in our root directory, we need to modify some configurations.

// truffle.jsrequire('dotenv').config();const HDWalletProvider = require("truffle-hdwallet-provider");
module.exports = {  networks: {    development: {      host: "localhost",      port: 7545,      gas: 6500000,      network_id: "5777"    },    ropsten: {        provider: new HDWalletProvider(process.env.MNENOMIC, "" + process.env.INFURA_API_KEY),        network_id: 3,        gas: 4500000    },  }};

The first line indicates we want to use the .env variables in this repo. Generally in most apps, you only need to require this once in the starting config file.

Most of this is boilerplate. Main section we want to focus on is the ropsten network.

ropsten: {        provider: new HDWalletProvider(process.env.MNENOMIC, "" + process.env.INFURA_API_KEY),        network_id: 3,        gas: 4500000    },

The provider is our network. In our case, we want to deploy our token into the Ropsten network. Using the HDWalletProvider we pass in two arguments, process.env.MNENOMIC, "" + process.env.INFURA_API_KEY. We access our .env variables by referencing process.env.VARIABLE_NAME_IN_ENV.

We set the network_id: 3 because that represents Ropsten. 1 is the main Ethereum net and 2 is an old testnet.

Lastly, we set gas: 4500000, which is why we needed the Ethereum originally. We use gas/ethereum any time we need to modify/add something in the Ethereum Network.

Alright, onto the last step before deployment!

Over in our migrations/2_deploy_contract.js, we need to make some modifications for our contract.

// 2_deploy_contract.js
const TestToken = artifacts.require("./TestToken.sol");
module.exports = function(deployer) {  deployer.deploy(TestToken);};

If you named your token contract file something else. You need to replace the TestToken.sol to whatever file you named it.

truffle compile

This should create a new folder in your directory:

etherem_token_tutorial|___build| |_____contracts|    |_____BasicToken.json|    |_____ERC20.json|    |_____ERC20Basic.json|    |_____Migrations.json|    |_____MintableToken.json|    |_____Ownable.json|    |_____SafeMath.json|    |_____StandardToken.json|    |_____TestToken.json|___contracts| |_____Migrations.sol| |_____TestToken.sol|___migrations| |_____1_initial_migrations.js| |_____2_deploy_contracts.js|___test|___truffle.js|___.env|___.gitignore**(newfile)

In our build folder, we have a bunch of contracts we inherited from the Open-Zeppelin library. If you’d like to know more about ERC-20 standards I’d check out the wiki. If there’s enough people asking for it I can make another blog post on it. For now here’s the link to the wiki.

Here comes the moment of truth. Now we need to deploy the contracts into the Ropsten network. Enter the following line in your terminal:

truffle migrate --network ropsten

You should get a series of lines in your terminal like:

Using network 'ropsten'.
Running migration: 1_initial_migration.js  Deploying Migrations...  ... 0x7494ee96ad7db4a560b6f3169e0666c3938f9f54208f7972ab902feb049a7f68  Migrations: 0x254466c5b09f141ce1f93689db6257b92133f51aSaving successful migration to network...  ... 0xd6bc06b3bce3d15dee4b733e5d4b09f0adb8f93f75ad980bad078484641d36e5Saving artifacts...Running migration: 2_deploy_contracts.js  Deploying TestToken...  ... 0x7e5c1b37f1e509aea59cd297417efe93eb49fdab2c72fa5c37dd2c63a3ba67b7  TestToken: 0x02ec6cbd89d3a435f8805e60e2703ef6d3147f96Saving successful migration to network...  ... 0x2fd6d699295d371ffd24aed815a13c5a44e01b62ca7dc6c9c24e2014b088a34eSaving artifacts...

This will take some time. Once it’s fully deployed copy the last txid. In my case:


This will have an address to your token contract. Here is a link to my txid:

Ropsten Transaction 0x2fd6d699295d371ffd24aed815a13c5a44e01b62ca7dc6c9c24e2014b088a34e
Ropsten (ETH) detailed transaction info for

Which has an address to the contract itself:

Ropsten Accounts, Address and Contracts
The Ethereum BlockChain Explorer, API and Analytics

You can get the completed GitHub repo here.

Visit for more web3 news