On July 13th, 2018, we released the Rate3 Locking Program, giving our Rate3 community members the opportunity to reserve their spot as Credit Nodes and receive great rewards at the same time.

Credit Nodes are non-institutional funds or financial institutions. They are typically community members who are more vested in the Rate3 ecosystem and want to play a greater role.

Hence, to allow for users to have an early priority registration for our Credit Nodes, we engineered a smart contract in Solidity to allow users to Stake and Lock their RTE tokens for interest and gain priority registration as a Credit Node in 2019.

The Rate3 Locking Program

We learned a great lot during the process and would love to share our learnings with the DApp community.

So, what is a DApp?

DApp is an abbreviated form for decentralized application.

Instead of having the backend code written and hosted on centralized servers, a DApp has its backend code running on a decentralized peer-to-peer network.

A DApp can have frontend code and user interfaces written in any language (just like an app) that can make calls to its backend.

What is our DApp about?

The Rate3 Vault Program

Users are allowed to stash and lock their RTE tokens for later, various rewards in the form of an additional annualized interest depending on how long it is locked for. It gives them the opportunity to gain priority access when Rate3 formally open up Credit Nodes registration in Q1 2019.

You check out our DApp at https://vault.rate3.network/

Tech Stack and General Architecture

For this project, we used the following stack:

Solidity Smart Contracts to communicate on the Ethereum blockchain.

Truffle and Ganache for our development and testing framework

MetaMask for our web3 provider in production

React / MobX / Material Design + Bootstrap for our front-end development. (P.S. You can check out how we set up our Front End projects at Rate here.)

Smart Contracts

The core functionality of the Rate3 Vault Program is only made possible by Ethereum’s smart contract functionality. We not only make frequent use of ERC20 methods such as approve and transferFrom , but also events which allows for responsiveness in our front-end whenever a transaction has been completed & verified.

From Investopedia,

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.

Truffle & Ganache

Truffle is a development environment, testing framework and asset pipeline for Ethereum, aiming to make life as an Ethereum developer easier. It is a great set of tools (written in Javascript) that makes deploying your Ethereum contracts much easier. We used it to compile and deploy our smart contracts to a local Ethereum server.

Ganache, part of the Truffle suite of Ethereum development tools, is your personal blockchain for Ethereum development. It ships with an internal Javascript implementation (EthereumJS) to simulate full client behavior and make developing Ethereum applications faster, easier, and safer. It also includes all popular RPC functions and features (like events) and can be run deterministically to make development a breeze.

Chai & Mocha was also used as our testing framework to test our smart contracts.

MetaMask

We require that users install MetaMask to interact with our smart contract on our website, for users who do not want to go through alternative flows such as using MyEtherWallet. Working with MetaMask was pretty straightforward, with a few exceptions:

Dealing with changes in user accounts for MetaMask state is not ideal. The recommended approach is to run an interval that repeatedly checks the current account. Fortunately for us, our interaction session is short (i.e. the user should be done within minutes), and hence this is not that much of an issue. From a UX standpoint, it was made sure that the user’s address is shown at all times. Bugs can happen all the time. For example, catching errors were broken on production for a few days (all DApps that rely on MetaMask would not be able to catch errors during then). Metamask can also hang indefinitely, an issue that is still currently live. Getting data from MetaMask requires a callback parameter, hence encouraging callback hell. Though, we did write a javascript function to overcome this. (We open-sourced it as well, read on!)

That said, MetaMask is a fantastic open source project, and the DApp ecosystem would be nowhere near what it is today without it.