From a multi-Application Ecosystem to a fully integrated dApp Platform deployed on Ethereum Blockchain

Enkronos Apps is an environment where applications get the ability to integrate themselves with public resource of Enkronos Apps in order to solve custom required logic for individual business needs. Solving the needs however requires a concept of monetization, this is where we realized that by implementing a concept of a decentralized and public storage of both transactions and information about who created the transaction would benefit and ease the usage of Enkronos Apps.

To create such a thing, we had to solve the issue of first developing a system that works entirely on using Enkronos Credits in every procedure inside the Enkronos Apps environment. Such procedures are defined when calculating the required bill for each creator in the platform.

Example of these procedures:

• Communication with the Enkronos Apps API
• Customer usage on an Enkronos Application
• Storage

We started by creating three unique smart contracts and deployed them on the Ethereum Blockchain. Each contract solves an important part in the bigger picture of realizing a fully decentralized payment and important data ledger eco system inside our Enkronos Apps.

Before we created them, we defined a clear requirement for our second contract which is the one that created the ERC20 standard token. In order to prevent inflation and the devaluation of it we defined a limited number of Tokens, which we called ENK tokens. This specific amount of 500 million will be the only pool of tokens that will be tradable with Enkronos Credits inside Enkronos Apps.

The third contract was where we met some difficulties. We wanted to create a dynamic and living crowdsale which would reflect the current scenario of the stage of the ICO and to communicate with both ETH and ENK tokens. The ICO itself has 6 unique stages to it. All of these stages have to be in the same crowdsale contract and are required to belong to the same soft cap of 2500 ETH. Each stage has a different bonus rate of how many Enkronos tokens each Ether can purchase and at the same time we defined two possible minimum buys in to the contract. For the duration of the first and second stage, which are named as Private and PRE, the minimum buy of the ETH amount of 10 while at the public stages which are the other four has 0.1 ETH. After clearly defining the stages we also created a restriction and the ability to have Whitelisting functionalities in both of the first two stages. To make it secure for our clients participating in the ICO we also wanted to add a refund policy if the soft cap in all of its stages was not reached.

Searching the market for possible solutions we quickly realized that obtaining smart contracts that do exactly what we wanted was impossible. However, finding close solutions to this was easy when we studied the framework of reusable smart contracts for Ethereum called Open Zeppelin. Using their “battle-tested” contracts helped us defining the broad issues on things such as Whitelisting, Soft cap refunding and other general procedures that a basic crowdsale should have such as the ability to receive and store ERC 20 tokens.

The Enkronos Crowdsale was built on top of both, the Whitelisted Crowdsale smart contract that inherits the general Crowdsale contract with the majority of the functionalities regarding obtaining and transferring ERC20 tokens and the Ownable smart contract that defines the ownership of the creator which links the public address of the wallet to the owner and holder of all ENK tokens. Since in Open Zeppelin inheritance comes already predefined for both Whitelist Contract and Refund Contract we had modify the original Enkronos Crowdsale with all the possible functionalities of the Refund Contract. Those define the ability to specific a goal as in a soft cap and the ability to store all transferred, pre-finalized, Ether transaction in a vault that is neutral to both the owners of the ICO smart contract and the people participating to it with sending Ether.

With those changes we strictly defined the robust environment of the ICO:

• Whitelist functionalities
• Soft cap
• Refund functionalities
• Vault storing
• Ownership
• Sending and receiving Ether as Enkronos Crowdsale

The next step was to configure dynamic changes that have to occur in the Crowdsale contract depending on the stage of the ICO. We added simple methods to the main Enkronos Crowdsale that change the scenarios of the rate of purchase, minimum buy and whitelisting toggling. While the rate changes and minimum buy was an easy implementation, the whitelisting however had to override the original method from the Whitelist Crowdsale contract and implement now the new changes that check also the possibility of the Whitelisting functionality being toggled to false.

Example of the override on isWhitelisted method:

modifier isWhitelisted(address _beneficiary) {
     if(isWhitelistOn)
            require(whitelist[_beneficiary]);
      _;
}

Now we have a fully changeable crowdsale smart contract that can bend and change to the needs of our ICO.

Going back to the three contracts that we pushed we skipped the first one. The first contract is the default contract of migration that comes with the Truffle framework. We developed the Enkronos crowdsale and the automated tests that go with it in Truffle, because the framework is well defined and was able to offer everything that was needed. This not only gave us a simple solution of publishing smart contracts to the main net of Ethereum blockchain. However, it also gave us a clear and comprehendible environment in where our next, so called fourth, smart contract will be created.

In the near future, as seen from our timeline that is defined on our website, we plan on developing the next but not last smart contract that will define the abilities of trade between the current Enkronos Apps application platform and the ERC20 ENK token from the second smart contract. This will give our clients the needed transparency and decentralization of all purchases being made in Enkronos Apps. This specific smart contract will allow us to create DAPPs that will inherit all functionalities of Loyalty Venue, Contest Dream, Swee, Your Gamify and all other future products we have planned in our development cycles.

For more questions that can reflect on how our Smart Contracts in Enkronos function you can always contact us on our social channels or me directly on LinkedIn.

Jure Veler

CTO in Enkronos d.o.o.