July 2, 2018 Blockchain, Blockchain Tutorials, Smart Contracts

Getting started with smart contracts on EOSIO

Overview of smart contract development

Getting started with smart contracts on EOSIO

Clone eosio from : https://github.com/EOSIO/eos with –recursive flag

Buid eosio: EOSIO community give an automated build script for select environments

1. Amazon 2017.09 and higher
2. Centos 7
3. Fedora 25 and higher (Fedora 27 recommended)
4. Mint 18
5. Ubuntu 16.04 (Ubuntu 16.10 recommended)
6. Ubuntu 18.04
7. MacOS Darwin 10.12 and higher (MacOS 10.13.x recommended)

Image for a successful build using eosio-build.sh..


Smart contracts for EOSIO are coded in c++, Usually (for most of the smart contracts) you have to specify a header file with the declaration of functions(that correspond to smart contract actions) and a .cpp source file with their definitions. A .abi file (Application Binary Interface) is also created that holds all the actions that the Smart contract has. This file is needed by external systems for executing the smart contract operations.


EOSIO provide a compilation tool called, eosiocpp and recommend it be used for the compilation of the smart contracts.

EOSIO ships with its standard c++ libraries, i.e When you clone the source, you will notice that a folder: {$PROJECT_ROOT}/contracts/libc++ ⇒ This directory has all the standard c++ library headers and this is where eosiocpp looks for the included standard header files.


A detour to .wasm

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications. It is meant to enable executing code nearly as fast as running native machine code. It was envisioned to complement JavaScript to speed up performance-critical parts of web applications and later on to enable web development in languages other than JavaScript.WebAssembly does not attempt to replace JavaScript, but to complement it.[4] It is developed at the World Wide Web Consortium (W3C) with engineers from Mozilla, Microsoft, Google and Apple.

More on wasm can be found here: https://webassembly.org/

Smart contract overview

Smart contracts are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network. Smart contracts permit trusted transactions and agreements to be carried out among disparate, anonymous parties without the need for a central authority, legal system, or external enforcement mechanism. They render transactions traceable, transparent, and irreversible.

Before we jump on the deploying our escrow smart contract, there are a couple of preliminary things that are needed to be carried on. The official documentation page for EOSIO has this in a very clear and precise manner: https://developers.eos.io/eosio-cpp/docs/introduction-to-smart-contracts

Assuming that you were able to execute the steps mentioned in the above link, let’s proceed further with our smart contract under discussion.


@breif: An escrow is basically a buffer where the token(currency) involved in the transaction is temporarily held until we know that the transaction can be completed without dispute. The operation under focus for this article is estransfer ( i.e escrow transfer); which is the operation used to transfer the fund from the sender to the escrow. This operation is complemented by esrelease which releases the funds from the escrow to the recipient.

First, define the class for your smart contract in the header file.

All the member functions corresponding to the actions, should be made public and they should be declared in the .abi file of the smart contracts.

Since our escrow smart contracts also issues the tokens needed for transactions it needs to have a table to store the data corresponding to the issued token and the balance for any account of that token. This is done using the multi_index container as provided by the EOSIO library (which is modelled after boost::multi_index_container) as follows:


The two tables defined are accounts and stat. The accounts table is made up of different account objects each holding the balance for a different token. The stat table is made up of currency_stats objects (defined by struct currency_stats) that holds a supply, a max_supply, and an issuer. Before continuing on, it is important to know that this contract will hold data into two different scopes. The accounts table is scoped to an EOSIO account, and the stat table is scoped to a token symbol name.

According to the ‘eosio::multi_index’ definitions, code is the name of the account which has write permission and the scope is the account where the data gets stored.

The scope is essentially a way to compartmentalize data in a contract so that it is only accessible within a defined space. In the token contract, each EOSIO account is used as the scope of the accounts table. The accounts table is a multi-index container which holds multiple account objects. Each account object is indexed by its token symbol and contains the token balance. When you query a users’ accounts table using their scope, a list of all the tokens that user has an existing balance for is returned.

This is our smart contract’s header file.

.cpp implementation

The actions are implemented in the .cpp source file

The definition of our estransfer action starts off with some assertion checks:

First, assert checks if the sender and receiver accounts are not same, then we check that the transaction has an authority of the sender, authority for a transaction can be specified by using -p <account_name> flag with cleos.

 Next, we fetch the table corresponding to the current token.

These lines notify the specified accounts after a successful transaction

This is followed by some more checks

Finally, we call the two most important utility functions, add_balance, and sub_balance, the former adds the tokens to a specified account and the later deducts it.

Let’s look at sub_balance in a little more detail:

First, we fetch the table of accounts objects, the account being that of the sender in estransfer. This is followed by a few checks, if all the checks pass, modify the account’s balance by subtracting the value to be transferred and if the number of tokens to be transferred are equal to the total available tokens in the accounts we essentially delete the entry for the sender account from the accounts table.

Here is our escrow.cpp file in entirety.

This is the structure of the ABI file that documents the actions of the smart contract.

Here is the escrow.abi file:

Working with our escrow smart contract using cleos (command line utility as provided by EOSIO)

First, we need to set the contract and create a token


Second, we can check at the moment if any account has some token balance for the token we just created, the result should not surprise you.


Once the escrow smart contract is set and the token balance has been created, we can push the action for issuing this token to some user “ned”


Now, when we check the account for “ned” we can see the token balance for this account


Now, we are in a situation to transfer funds from “ned” to “jon” (R+L=J)


We have used the account “escrow” with which we had deployed the smart contract as our Escrow for this transaction.

Then, we can check the balance for “escrow”


This is the final table structure after pushing the release action.




One stop developer’s doc: https://developers.eos.io/

Great resource for understanding token contract: https://medium.com/coinmonks/understanding-the-eosio-token-contract-87466b9fdca9

Resource for pushing actions using eosjs lib: https://steemit.com/devs/@eos-asia/eos-smart-contracts-part-1-getting-started-ping-equivalent-in-eos






Share this article!

Leave a comment