With the current rise of cryptocurrencies, blockchain is creating a buzz in the technology world. This technology has attracted so much attention mainly because of its ability to guarantee security, enforce decentralization, and quicken processes to several industries—especially to the financial industry.

Essentially, a blockchain is a public database that irreversibly documents and authenticates the possession and transmission of digital assets. Digital currencies, like Bitcoin and Ethereum, are based on this concept. Blockchain is an exciting technology that you can use to transform the capabilities of your applications.

Of late, we’ve been seeing governments, organizations, and individuals using the blockchain technology to create their own cryptocurrencies—and avoid being left behind. Notably, when Facebook proposed its own cryptocurrency, called Libra, the announcement stirred many waters across the world.

What if you could also follow suit and create your own version of a cryptocurrency?

I thought about this and decided to develop an algorithm that creates a crypto.

I decided to call the cryptocurrency fccCoin.

In this tutorial, I’m going to illustrate the step-by-step process I used to build the digital currency (I used the object-oriented concepts of the Python programming language).

Here is the basic blueprint of the blockchain algorithm for creating the fccCoin:

class Block:

    def __init__():

    #first block class

        pass

    def calculate_hash():

    #calculates the cryptographic hash of every block


class BlockChain:

    def __init__(self):
     # constructor method
    pass

    def construct_genesis(self):
        # constructs the initial block
        pass

    def construct_block(self, proof_no, prev_hash):
        # constructs a new block and adds it to the chain
        pass

    @staticmethod
    def check_validity():
        # checks whether the blockchain is valid
        pass

    def new_data(self, sender, recipient, quantity):
        # adds a new transaction to the data of the transactions
        pass

    @staticmethod
    def construct_proof_of_work(prev_proof):
        # protects the blockchain from attack
        pass

    @property
    def last_block(self):
        # returns the last block in the chain
        return self.chain[-1]

Now, let me explain what is taking place…

1. Building the first Block class

A blockchain comprises of several blocks that are joined to each other (that sounds familiar, right?).

The chaining of blocks takes place such that if one block is tampered with, the rest of the chain becomes invalid.

In applying the above concept, I created the following initial block class:

import hashlib
import time

class Block:

    def __init__(self, index, proof_no, prev_hash, data, timestamp=None):
        self.index = index
        self.proof_no = proof_no
        self.prev_hash = prev_hash
        self.data = data
        self.timestamp = timestamp or time.time()

    @property
    def calculate_hash(self):
        block_of_string = "{}{}{}{}{}".format(self.index, self.proof_no,
                                              self.prev_hash, self.data,
                                              self.timestamp)

        return hashlib.sha256(block_of_string.encode()).hexdigest()

    def __repr__(self):
        return "{} - {} - {} - {} - {}".format(self.index, self.proof_no,
                                               self.prev_hash, self.data,
                                               self.timestamp)

As you can see from the code above, I defined the init() function, which will be executed when the Block class is being initiated, just like in any other Python class.

I provided the following parameters to the initiation function:

• self—this refers to the instance of the Block class, making it possible to access the methods and attributes associated with the class;
• index—this keeps track of the position of the block within the blockchain;
• proof_no—this is the number produced during the creation of a new block (called mining);
• prev_hash—this refers to the hash of the previous block within the chain;
• data—this gives a record of all transactions completed, such as the quantity bought;
• timestamp—this places a timestamp for the transactions.

The second method in the class, calculate_hash, will generate the hash of the blocks using the above values. The SHA-256 module is imported into the project to assist in obtaining the hashes of the blocks.

After the values have been inputted into the cryptographic hash algorithm, the function will return a 256-bit string representing the contents of the block.

This is how security is achieved in blockchains—every block will have a hash and that hash will rely on the hash of the previous block.

As such, if someone tries to compromise any block in the chain, the other blocks will have invalid hashes, leading to disruption of the entire blockchain network.

Ultimately, a block will look like this:

{
    "index": 2,
    "proof": 21,
    "prev_hash": "6e27587e8a27d6fe376d4fd9b4edc96c8890346579e5cbf558252b24a8257823",
    "transactions": [
        {'sender': '0', 'recipient': 'Quincy Larson', 'quantity': 1}
    ],
    "timestamp": 1521646442.4096143
}

2. Building the Blockchain class

The main idea of a blockchain, just as the name implies, involves “chaining” several blocks to one another.

Therefore, I’m going to construct a Blockchain class that will be useful in managing the workings of the whole chain. This is where most of the action is going to take place.

The Blockchain class will have various helper methods for completing various tasks in the blockchain.

Let me explain the role of each of the methods in the class.

a. Constructor method

This method ensures the blockchain is instantiated.

class BlockChain:

    def __init__(self):
        self.chain = []
        self.current_data = []
        self.nodes = set()
        self.construct_genesis()

Here are the roles of its attributes:

• self.chain—this variable keeps all blocks;
• self.current_data—this variable keeps all the completed transactions in the block;
• self.construct_genesis()—this method will take care of constructing the initial block.

b. Constructing the genesis block

The blockchain requires a _construct_genesis_ method to build the initial block in the chain. In the blockchain convention, this block is special because it symbolizes the start of the blockchain.

In this case, let’s construct it by simply passing some default values to the _construct_block_ method.

I gave both _proof_no and prev_hash_ a value of zero, although you can provide any value you want.

def construct_genesis(self):
    self.construct_block(proof_no=0, prev_hash=0)


def construct_block(self, proof_no, prev_hash):
    block = Block(
        index=len(self.chain),
        proof_no=proof_no,
        prev_hash=prev_hash,
        data=self.current_data)
    self.current_data = []

    self.chain.append(block)
    return block

c. Constructing new blocks

The _constructblock method is used for creating new blocks in the blockchain.

Here is what is taking place with the various attributes of this method:

• index—this represents the length of the blockchain;
• proof_nor & prev_hash—the caller method passes them;
• data—this contains a record of all the transactions that are not included in any block on the node;
• self.current_data—this is used to reset the transaction list on the node. If a block has been constructed and the transactions allocated to it, the list is reset to ensure that future transactions are added into this list. And, this process will take place continuously;
• self.chain.append()—this method joins newly constructed blocks to the chain;
• return—lastly, a constructed block object is returned.

d. Checking validity

The _check_validity_ method is important in assessing the integrity of the blockchain and ensuring anomalies are absent.

As mentioned earlier, hashes are essential for the security of the blockchain as even the slightest change in the object will lead to the generation of a completely new hash.

Therefore, this _checkvalidity method uses if statements to check whether the hash of every block is correct.

It also verifies if every block points to the right previous block, through comparing the value of their hashes. If everything is correct, it returns true; otherwise, it returns false.

@staticmethod
def check_validity(block, prev_block):
    if prev_block.index + 1 != block.index:
        return False

    elif prev_block.calculate_hash != block.prev_hash:
        return False

    elif not BlockChain.verifying_proof(block.proof_no, prev_block.proof_no):
        return False

    elif block.timestamp <= prev_block.timestamp:
        return False

    return True

e. Adding data of transactions

The _new_data method is used for adding the data of transactions to a block. It’s a very simple method: it accepts three parameters (sender’s details, receiver’s details, and quantity) and append the transaction data to self.current_data_ list.

Anytime a new block is created, this list is allocated to that block and reset once more as explained in the _construct_block_ method.

Once the transaction data has been added to the list, the index of the next block to be created is returned.

This index is calculated by adding 1 to the index of the current block (which is the last in the blockchain). The data will assist a user in submitting the transaction in future.

def new_data(self, sender, recipient, quantity):
    self.current_data.append({
        'sender': sender,
        'recipient': recipient,
        'quantity': quantity
    })
    return True

f. Adding proof of work

Proof of work is a concept that prevents the blockchain from abuse. Simply, its objective is to identify a number that solves a problem after a certain amount of computing work is done.

If the difficulty level of identifying the number is high, it discourages spamming and tampering with the blockchain.

In this case, we’ll use a simple algorithm that discourages people from mining blocks or creating blocks easily.

@staticmethod
def proof_of_work(last_proof):
    '''this simple algorithm identifies a number f' such that hash(ff') contain 4 leading zeroes
         f is the previous f'
         f' is the new proof
        '''
    proof_no = 0
    while BlockChain.verifying_proof(proof_no, last_proof) is False:
        proof_no += 1

    return proof_no


@staticmethod
def verifying_proof(last_proof, proof):
    #verifying the proof: does hash(last_proof, proof) contain 4 leading zeroes?

    guess = f'{last_proof}{proof}'.encode()
    guess_hash = hashlib.sha256(guess).hexdigest()
    return guess_hash[:4] == "0000"

g. Getting the last block

Lastly, the _latestblock method is a helper method that assists in obtaining the last block in the blockchain. Remember that the last block is actually the current block in the chain.

@property
    def latest_block(self):
        return self.chain[-1]

Let’s sum everything together

Here is the entire code for creating the fccCoin cryptocurrency.

You can also get the code on this GitHub repository.

import hashlib
import time


class Block:

    def __init__(self, index, proof_no, prev_hash, data, timestamp=None):
        self.index = index
        self.proof_no = proof_no
        self.prev_hash = prev_hash
        self.data = data
        self.timestamp = timestamp or time.time()

    @property
    def calculate_hash(self):
        block_of_string = "{}{}{}{}{}".format(self.index, self.proof_no,
                                              self.prev_hash, self.data,
                                              self.timestamp)

        return hashlib.sha256(block_of_string.encode()).hexdigest()

    def __repr__(self):
        return "{} - {} - {} - {} - {}".format(self.index, self.proof_no,
                                               self.prev_hash, self.data,
                                               self.timestamp)


class BlockChain:

    def __init__(self):
        self.chain = []
        self.current_data = []
        self.nodes = set()
        self.construct_genesis()

    def construct_genesis(self):
        self.construct_block(proof_no=0, prev_hash=0)

    def construct_block(self, proof_no, prev_hash):
        block = Block(
            index=len(self.chain),
            proof_no=proof_no,
            prev_hash=prev_hash,
            data=self.current_data)
        self.current_data = []

        self.chain.append(block)
        return block

    @staticmethod
    def check_validity(block, prev_block):
        if prev_block.index + 1 != block.index:
            return False

        elif prev_block.calculate_hash != block.prev_hash:
            return False

        elif not BlockChain.verifying_proof(block.proof_no,
                                            prev_block.proof_no):
            return False

        elif block.timestamp <= prev_block.timestamp:
            return False

        return True

    def new_data(self, sender, recipient, quantity):
        self.current_data.append({
            'sender': sender,
            'recipient': recipient,
            'quantity': quantity
        })
        return True

    @staticmethod
    def proof_of_work(last_proof):
        '''this simple algorithm identifies a number f' such that hash(ff') contain 4 leading zeroes
         f is the previous f'
         f' is the new proof
        '''
        proof_no = 0
        while BlockChain.verifying_proof(proof_no, last_proof) is False:
            proof_no += 1

        return proof_no

    @staticmethod
    def verifying_proof(last_proof, proof):
        #verifying the proof: does hash(last_proof, proof) contain 4 leading zeroes?

        guess = f'{last_proof}{proof}'.encode()
        guess_hash = hashlib.sha256(guess).hexdigest()
        return guess_hash[:4] == "0000"

    @property
    def latest_block(self):
        return self.chain[-1]

    def block_mining(self, details_miner):

        self.new_data(
            sender="0",  #it implies that this node has created a new block
            receiver=details_miner,
            quantity=
            1,  #creating a new block (or identifying the proof number) is awarded with 1
        )

        last_block = self.latest_block

        last_proof_no = last_block.proof_no
        proof_no = self.proof_of_work(last_proof_no)

        last_hash = last_block.calculate_hash
        block = self.construct_block(proof_no, last_hash)

        return vars(block)

    def create_node(self, address):
        self.nodes.add(address)
        return True

    @staticmethod
    def obtain_block_object(block_data):
        #obtains block object from the block data

        return Block(
            block_data['index'],
            block_data['proof_no'],
            block_data['prev_hash'],
            block_data['data'],
            timestamp=block_data['timestamp'])

Now, let’s test our code to see if it works.

blockchain = BlockChain()

print("***Mining fccCoin about to start***")
print(blockchain.chain)

last_block = blockchain.latest_block
last_proof_no = last_block.proof_no
proof_no = blockchain.proof_of_work(last_proof_no)

blockchain.new_data(
    sender="0",  #it implies that this node has created a new block
    recipient="Quincy Larson",  #let's send Quincy some coins!
    quantity=
    1,  #creating a new block (or identifying the proof number) is awarded with 1
)

last_hash = last_block.calculate_hash
block = blockchain.construct_block(proof_no, last_hash)

print("***Mining fccCoin has been successful***")
print(blockchain.chain)

It worked!

Here is the output of the mining process:

***Mining fccCoin about to start***
[0 - 0 - 0 - [] - 1566930640.2707076]
***Mining fccCoin has been successful***
[0 - 0 - 0 - [] - 1566930640.2707076, 1 - 88914 - a8d45cb77cddeac750a9439d629f394da442672e56edfe05827b5e41f4ba0138 - [{'sender': '0', 'recipient': 'Quincy Larson', 'quantity': 1}] - 1566930640.5363243]

Conclusion

There you have it!

That’s how you could create your own blockchain using Python.

Let me say that this tutorial just demonstrates the basic concepts for getting your feet wet in the innovative blockchain technology.

If this coin were deployed as-is, it could not meet the present market demands for a stable, secure, and easy-to-use cryptocurrency.

Therefore, it can still be improved by adding additional features to enhance its capabilities for mining and sending financial transactions.

Nonetheless, it’s a good starting point if you decide to make your name known in the amazing world of cryptos.

If you have any comments or questions, please post them below.

Happy (crypto) coding!

TL;DR Check this back end and front end solutions for delegated transactions. It is universal for any token which supports the delegation of its functions. Read more below.

This mostly technical article provides a universal framework and a working solution for Ethereum tokens and applications that eliminates the need to pay fees in Ether, a problem that is practically killing the user experience of many blockchain applications.

Imagine spending dollars and then being asked to also hand over some Hryvnias as a transaction fee. That's how Ethereum tokens work so far.

In other words, for example, to transfer any Ethereum token (like Tether, DAI, BAT, DREAM, etc.), the user has to also spend some Ether (internal Ethereum platform currency). This introduces a big inconvenience that prevents the mass adoption of DApps: users have to purchase multiple currencies instead of just one to interact with the blockchain network.

The Problem

Tokens, as we imagine them today are just fuel for applications and services on top of blockchain networks. Organizations create their own tokens (using ICOs, IEOs, etc) and run services/applications that utilize them, introducing their own micro-economy (widely known as a token economy). But almost every token turns out to be quite a complex currency itself. By design of how blockchain networks work, in order to do something with your tokens, you also need another currency — often Ether (for Ethereum) to be able to transfer tokens.

To illustrate the problem, let's look into how users come to use different blockchain-powered services and applications like:

• Trickle - where you create secure, hourly-based contracts with an untrusted party in any token
• Loom - where you use Loom tokens to create sidechains in Loom Network
• Cryptokitties.co - where you breed, trade and transfer kitties (ERC721 tokens)
• Others (there are a lot!)

All these applications use tokens, as well as they require you to purchase Ether. The complexity of using crypto tokens as we know them today is one of the biggest reasons why 99% of crypto startups fail (or avoid adopting real crypto, for example, by replacing it with virtual coins).

As you may already know, the harder it is to use the application, the fewer users it will get right from the beginning. This is something known as The User Onboarding Funnel, which is still a big pain for blockchain-powered applications and services:

The typical user onboarding funnel of a decentralized, blockchain-based application

To understand why I put 0.001% of users prior to the service use, let's see what exactly purchasing some Ether means:

• Creating a crypto wallet
• Registering on Exchange (and learning all the exchange rules, including country policies!)
• Passing KYC (though it's getting easier, still, many countries have limited access to exchanges)
• Purchasing a minimum allowed amount of Ether (usually, it's whopping $50 while you need just nearly $0.05 to perform one or two transactions)
• Withdrawing Ether to your wallet
• Not to mention reading lengthy guides on how to perform all these steps properly

Instead of just:

• Creating a crypto wallet

Of course, it highly depends on how the application or service is made. But, so far, there was no better simplification of the onboarding flow as just cutting crypto tokens from there, or making them fake, "virtual" currency with deposit and withdrawal function. Unfortunately, the latter approach is now the common one across all startups and companies adopting crypto, for many good reasons. Another reason could be a monetization strategy, but this is another big story worth a dedicated article (Interested? Comment out!).

Getting back to the transaction fees problem, we can state the following, which is hard to argue with.

It is natural for the user to purchase only the cryptocurrency they really need (for instance, tokens: Tether, DAI, BAT, DREAM, etc.), and they would normally expect to pay any transaction fees in this cryptocurrency.

So why not just allow them to do so? Because it's quite complex indeed. Let's see why, and how this has just got easier with our open-sourced solution (at least for Ethereum).

Existing Approaches

From the very beginning of blockchain existence, there were a couple of solutions that could simplify the user onboarding flow to the flow depicted below, avoiding the step of purchasing an intermediate currency like Ether. Still, creating a blockchain wallet is not an easy step, but some users who do understand the value of the application/service go through this step quite well.

The user onboarding funnel with delegated transactions

The solution which allows to avoid using intermediate currencies (Ether for Ethereum) is called "delegated transactions", or "meta transactions".

In short, delegated transaction, or "meta transaction" in blockchain is the type of transaction which performs an intended action on one account's behalf, while it is conducted (published) by another account (delegate), who actually pays fees for the transaction.

There are multiple approaches around the internet of the generalized concept of delegated transactions I am presenting in this article. But it seems that none of them are still widely adopted, as these approaches are quite complex by its nature, very specific as for the implementation, as well as some of them are quite complex to standardize. To be more constructive, existing approaches can be divided into 3-4 groups: those which use proxy smart contracts, those which embed delegation into a smart contract itself and, theoretically, there is an opportunity for the blockchain-native implementation (say, Ethereum 2.0).

1. Delegated transactions approaches which use proxy-contracts

Proxy contracts, or, in this context, identity contracts are tiny contracts deployed to replace the user account which wants to avoid paying fees. This smart contract is programmed to act as a wallet, as well as a "caller" (sender) of other smart contract's functions. The key is that it is a delegate account that triggers all the actions, while the true "owner" of this smart contract is another user. The user just generates correct signatures in order to control their funds stored on a smart contract address (= in their wallet).

A visualization of how identity contracts look like

Pros of this approach:

• It works with any tokens and contracts which are already deployed to the network

Cons of this approach:

• Users don't see tokens in their wallet, because they are physically on an identity smart contract
• As a result, a need to develop custom UIs and custom tools/wallets
• Identity smart contract deployment and assignment initial fees, as opposed to no fees at all
• Requires a comprehensive standard to be widely adopted

2. Semi-delegated transactions via "Operator" pattern (ERC777)

There is a token standard that describes this approach — ERC777. In short, any token holder can authorize any other account to freely manage their tokens. I won't call it delegated transactions but nevertheless, I need to mention that, as here we somewhat delegate control over your tokens to other accounts.

A visualization of ERC777 standard's "operator" pattern

Pros of this approach:

• Standardized

Cons of this approach:

• Highly centralized around the "operator" accounts
• Weak security due to operators have 100% control over your tokens
• Initial fees for approval transaction
• Requires additional UIs/tools development

3. Delegated transactions embedded directly into a (token) smart contract

Just the same as it is possible to implement custom fees in a proxy smart contract, paying fees in tokens can be implemented directly in a token smart contract. For example, using the approach I described in my previous article, it is possible to implement a function in a smart contract, which will transfer tokens accepting the user's signature, instead of requiring the user to call this function directly. We have implemented this approach in our DREAM Token, which is used on our dreamteam.gg platform.

A visualization of how embedding delegation into the token contract looks like

As you may notice, in contrast to the previous approach there is no identity contract anymore, and there is an optional way to call other smart contracts directly from the token contract.

Pros of this approach:

• Users see their tokens as usual on their wallet's balance
• No initial fees for account initialization
• May not even require a standard (continue reading)

Cons of this approach:

• If you have a (token) smart contract that is already deployed to the network, you cannot apply this approach to it directly. While you can always deploy a new token and, for example, a "migration" utility, which will allow other users to swap tokens (burn the old token and mint a new one)
• Because a standard for this approach is yet not well-defined, implementation can drastically vary
• A need to develop custom UI/tools for delegated transactions (continue reading — solved!)

4. Delegated transactions on the (blockchain) platform level

This is far the best one of all the described approaches above but also the one which is not implemented anywhere yet (by anywhere I mean the most popular blockchain platforms). There is a hope that its support comes with Ethereum 2.0 release, or at least I've heard from Vitalik that they are in progress with something cool there.

Theoretically, we can imagine this approach as being able to make an "offline" signature of two transactions at a time: one which does something useful for the signing account which wants to avoid paying fees (for example, transferring tokens) and another one which does something useful for the delegate (for example, paying fee in tokens to the account which executes these two transactions).

A visualization of how platform-native delegated transactions could look like

But the problem is, regarding Ethereum 2.0, this feature has a chance to land only in 2022 or even later. I also suppose that this feature will still require a dedicated back end (similar to the one which is introduced within this article), as it is hard to imagine how miners will accept fees in tokens. Simply put, if some of them refuse to accept fees in tokens than it makes little sense to do it on a "mining" level at all, not to mention how much would it take to track all token prices and volumes across exchanges, in a decentralized manner.

Pros of this approach:

• No need to change smart contracts that were already deployed
• No initial fees for account initialization
• May not even require a custom UI/tools if standardized

Cons of this approach:

• Most likely, will still require a centralized back end (the "delegate")
• Not yet implemented on a platform level (as of 2019)

The Solution

From the four approaches above, except for the platform-level approach which is yet to be implemented and standardized in 2022+, the most appealing one is the third approach, where we embed delegated functions directly to the token smart contract. Thus, we save the standard token paradigm allowing wallets to normally work with the smart contract and have no need to wait until delegated transactions will land natively in one of the top blockchain platforms. We will stick to this approach and make it universal just below.

Delegated transactions support programmed right in the token smart contract is awesome. But how to deal with its cons? In fact, the only problem which is tough to deal with (as you cannot modify existing smart contracts), you will need to deploy a new token smart contract if you have already deployed it without delegated functions (for instance, standard ERC20 or ERC721 tokens). The next step, in this case, would be adding a way to migrate tokens from one smart contract to another. For example, you can decide to implement one more function in the new smart contract that will allow token holders to migrate their assets from the old smart contract.

Token migration function implementation can vary, starting from implementing receiveApproval in the new token, if the previous token supports approveAndCall, or ending with utilizing approve + transferFrom framework if you have just a bare minimal ERC20 (the user _approve_s tokens to the new token contract address and then calls a function in the new contract which burns old tokens and mints new ones — but this requires a standard fee for the user for the approval transaction). Actually, there is more: you can decide not to burn old tokens but to "lock" them on a new token smart contract, minting new tokens — this opens an opportunity to implement two-sided token migration, which is awesome — you won't need to list the "new" token on the exchange, while the users will still be able to send the old token to exchanges without fees in Ether! If you are interested, please fill the issue here if you want to know more details on how to do it, because this approach is worth a whole new article.

In my previous article, I provided an example of the token smart contract which supports delegation of such functions like transfer, transferFrom, approve and approveAndCall. Exactly these "delegated" functions allow users to pay fees in tokens, instead of Ether.

How delegation works in Ethereum, in short. Read more in this article.

But that wasn't enough to start the mass adoption. In this article, I am providing a complete universal back end solution (Transaction Publisher in the picture above), as well as a configurable widget (check it here), which allows you to replace Ether fees for token fees today.

Some key points before we dive in:

• This delegated transactions back end is made to be universal, or standard-free, meaning that you can have any implementation of delegated functions and use any signature standard(s) in your token. From the back end standpoint, you just need to write a manifest file for your token, describing its usage.
• Currently, converting collected fees in tokens back to Ether is a manual action on exchanges. But it could be a potential improvement for automation in the future (if needed).

The Concept Behind the Universal Solution

What does it mean that the token supports delegated transactions? Let's look at it using the ERC20 standard token as an example.

Smart Contract

As for the token smart contract, the approach is quite straightforward. In addition to every method like transfer(to, value) which we want to be "delegatable", we add a companion function which, instead of inspecting msg.sender, accepts the signature of a user and does the same what the original function meant to do by validating this signature inside the smart contract. Thus, for example, for transfer(to, value) function we can add transferViaSignature(to, value, ...aditionalParams) function. As you know from public-key cryptography, no one can create a valid signature except private key owner, so that's why this approach is as secure as Ethereum itself.

And the coolest part is that the delegated function implementation, as well as its signature doesn't matter much, from the delegate back end standpoint. You can even decide to implement one "call by signature" function for all other functions that the smart contract supports. Delegate back end just need to know how to call this function, which is solved by providing an off-chain contract manifest for the delegate back end. For example, the argument additionalParams in transferViaSignature can vary and can include anything from this list, if not more: fee, fee recipient address, expiration timestamp, a signature standard used, a signature itself, nonce number or any other unique delegated transaction ID and so on. Regarding the smart contract design, in order to understand why exactly these arguments, read my previous article.

We also want to allow "delegates" to earn something in order to cover their Ether spending, as well as to be profitable. Thus, we have to add a fee, but a much more natural fee than Ether: a fee in the token itself. So that, for example, if you need to transfer 100 tokens, you pay 3 more tokens to the delegate depending on its price and network conditions to perform a transfer, and this should be preserved in a smart contract logic.

Back End

All right, now we have a token that allows transferring someone else's tokens by using their signature. Now, the crucial part is to automate the process of requesting and publishing such transactions. And here where our open-sourced back end (and a front end) kicks in.

Below is the sequence diagram describing how front end (client) communicates with the back end from the delegated transaction request to its publishing to the network:

1. (hidden on the diagram) The client requests information from the delegated back end to understand which contracts does it support, as well as which functions can it delegate.
2. The client requests a particular smart contract's function to be delegated. Most importantly, the back end returns the fees it charges and a data to be signed by the client.
3. The client signs the data in their wallet. Signing is a free operation, unlike publishing transaction to the network.
4. The client sends their signature back, thus confirming their intent to perform this particular delegated transaction. The back end validates this transaction against the current network.
5. Finally, the back end publishes a transaction to the network.
6. (hidden on the diagram) The client constantly polls the back end for the delegated request status until it receives a mined status. Note: it is important to poll the back end instead of using a transaction hash to understand when the transaction is mined. It is a very common case when the gas price suddenly increases, and, in order for the transaction to be mined quickly, the back end may republish it with a higher gas price. Though it is currently not implemented, it is very likely to be implemented soon.

Sequence diagram representing the simplified flow of how delegated transaction is delivered to the network

This approach is universal, and only requires the manifest file for the back end to understand how to calculate fees and which signature standard to use on the client side. Here is another visualization of the components of the system and their interaction sequence:

Component diagram

We've provided a comprehensive documentation for this solution. You can check how the back end API is structured, as well as find the token manifest file which describes how to work with a particular token contract. We encourage you to contribute your own tokens there!

And you don't need much setup: it's already there with the universal front end!

Front End

Open-sourced front end part of the delegated transactions is the user interface which is set up for every token: just run your delegated transactions back end and you are ready to go!

What it looks like

It is made to be an embeddable widget, which will guide the user through the procedure of sending tokens. You can plug any back end, token or call any token function with it by utilizing additional URL parameters you can specify.

Using this widget, and by implementing something similar to widely used, but not standardized approveAndCall function in your token smart contract, you will be able to call other smart contracts with arbitrary data by paying fees in tokens!

Here is a quick guide for you if you want to play with this UI yourself:

1. Access the widget via this link.
2. It will ask you to switch to the Kovan test network.
3. Get some test Ether using any available Kovan faucet.
4. Use test Ether to mint some test tokens: call mintTokens function in a token smart contract which will give you 10 test tokens.
5. Now, get back to the widget and try to transfer these tokens!

If you open up the browser's developer tools, you may notice that there are a couple of back ends connected by default — they provide the front end with all required information to make a delegated request according to given widget URL parameters. All backends are requested during the widget load and, if any of them can provide a delegation for a particular contract's function, then the widget requests additional information: fees, supported signatures, etc. If there are multiple back ends which can delegate the same contract function, all of them are requested and the back end which provides the best fee will be used for the transaction.

Transaction mining time is seemingly fixed, but it can vary because of the network conditions. The back end uses an actual network fee when calculating the token fee, however, it may change before the user decides to execute the transaction. Thus, the "underpriced" transaction is submitted to the network and can be pending for a while. While the back end is currently not programmed to deal with this case, it might be implemented in future — transactions will be republished with higher gas fees in case of the network fee increases. But, we will also need to count this into the token fee.

Signature Standards

The last question which you may be wondering is — which signature standard to use for your token. There are several available: _ethsign (deprecated), _ethpersonalSign (note that old Trezor and Ledger produce a different signatures because of ambiguity in a standard, so you may want to include both), _ethsignTypedData (deprecated), _eth_signTypedDatav3 and so on. I would recommend supporting at least two: ageless _ethpersonalSign and new _eth_signTypedDatav3 (as of 2019).

Signature standards comparison — what the user sees

The front end is programmed to always prefer the user-readable standard like eth_signTypedData_v3 to any others eth_personalSign. So if your token supports many signature standards, and you added all of them to the manifest file of your token, it will display eth_signTypedData_v3 prompt first.

Conclusion

Delegated transactions are great: they solve one of the biggest problems of blockchain application adoption, which eases the mass adoption of crypto overall. I will put a couple of thesis in a Q&A format here for you to answer the last questions that you may still have after reading this article:

• Our open-source solution is free to use and production-ready, feel free to apply it to your applications or tokens!
• The described approach does not compromise security nor centralization. Think this way: the centralized back end is only a helper for someone who wants to transfer tokens without fee in Ether. If the back end is hacked, or it is just unavailable, there's no problem to interact with the network just as it was before, by paying fees in Ether. As well as the back end cannot harm or trick the user to steal their tokens when a proper signature standard is used (it's up to your token implementation).
• There is a way to support delegated transactions for existing, already-deployed tokens. However, it requires the additional Ether-consuming step to migrate existing tokens to a new token contract. And, by programming a new token contract properly, as well as designing your application to work with both tokens you can even avoid a need to list a new token on exchanges.
• By using the existing tokens as an example, which is available in delegated transactions back end and front end repositories, you can produce your own manifest for your own token.
• Read the instructions on how to set up your own back end for a token, and then add it to the URL of your widget (or commit to the open-source repository).
• Have a token which already supports delegated transactions? Plug it into our UI with these three quite simple steps: (1) create a manifest for your token and put your token abi file while setting up the delegate back end, (2) run this back end, exposing a public API URL and (3) use URL parameters in a widget to reference your back end or commit it directly to our open-source repository. Read more about it in GitHub's readme file.

I hope that was a really helpful piece of information for all the searchers of incredible. Feel free to contact me or fill the issue here if I missed something. Have fun, let the token economy be simple!

In a silly (and PG-rated) rap battle, Hamilton and Satoshi argue the merits behind centralized and decentralized currencies.

Alexander Hamilton is one of America's Founding Fathers and served as our first Secretary of Treasury under George Washington. He was a lawyer, banker, and advocate of centralized control of fiscal and monetary policy.

And yes - he's the same Hamilton from the Broadway play.

Hamilton is played by EpicLloyd (of Epic Rap Battles of History fame.)

Satoshi Nakamoto is the creator of the Blockchain and of the Bitcoin cryptocurrency. Nobody knows what he looks like - or whether he's even a real person. (And yes - this is addressed in the rap battle).

Satoshi Nakamoto's Programmer Playing Card.

Nakamoto is portrayed by an unmasked TimothyDeLaGhetto.

In the 6-minute video, the rappers trade ideological blows with one another.

Hamilton brings up issues with Bitcoin's high transaction costs, scalability issues, and energy consumption.

Nakamoto raps about how untraceable cash can facilitate crime, and how the existence of giant banks can necessitate taxpayer bailouts.

Here's the full video:

And here are the full lyrics in case you don't want to be seen at your desk watching Alexander Hamilton rap with a musket in hand. (But really - you should watch it.)

[Alexander Hamilton]
Before we begin, everyone do me a favor,
And read a little thing I wrote called the Federalist Papers.
I explain how a nation’s unlikely to survive
Without a strong central government to keep it alive,
When I launched the central bank, Jefferson called me ill,
Now you have my face to thank on every ten dollar-bill.
When America was cash-strapped, I pushed past that,
Now some sicko makes crypto and our nation backtracks?

[Satoshi Nakamoto]
Decentralized currency. Yes, I invented it.
I’m sure many governments wish they had prevented it
Their national cash is how they keep control,
But freedom to the people was my ultimate goal.
Am I a pseudonym? A group of men? It doesn’t even matter.
I invented Bitcoin cause fiat is a disaster.
A man from Japan or a damn hologram?
I’m the reason open season on crypto began.

[Alexander Hamilton]
Does anybody know what this crypto-thing means?
To me, sounds like the new Get Broke Quick scheme,
A bunch of fools from across the land
Investing in something they don’t even understand,
Buying Litecoin, Dash, Bitcoin Cash,
It’s all gonna crash, and be gone in a flash.
All this unsupported money’s an irrational prank,
And I’ll be laughing all the way to my National Bank.

[Satoshi Nakamoto]
Hahahahahah, yeah dude, super funny,
As if banks these days still helped people make money.
The rich get richer and we follow like we’re all sheep,
The banks serve Wall Street, crypto serves all streets,
The interest in crypto’s on rapid ascent
What’s your current interest? Half a percent?
I’m sorry, the bank’s gone past its peak
But I want info encrypted, not hacked and leaked.

[Alexander Hamilton]
If this crypto system will be our salvation,
It needs to be centralized, needs regulation.
If our central database gets… how you say, “hacked?”
Insurance will just make a case to get your money back.
‘Cause in fact, it’s tracked, and the money leaves a trail.
Central currency is strong, cryptocurrency is frail.
Untraceable money — wow, so clever.
One typo in your address? Now it’s gone forever.

[Satoshi Nakamoto]
Crypto is frail? That’s the essence of your lesson?
Your money leaves a trail? Yeah, a trail to a recession.
A buncha rich white guys made this system.
Why would they ever change this, when It’s made them rich men!
Movie moguls fought hard against the VCR.
Horse and buggy manufacturers all hated the car.
So why would I take my advice from the banks?
I don’t need a bailout to survive. Thanks.

[Satoshi Nakamoto's backup singer]
The system is so broken.
We need that crypto token.

[Alexander Hamilton's backup singer]
The system isn’t broken.
Can we trust crypto tokens?

[Alexander Hamilton]
It’s gotta be centralized!

[Satoshi Nakamoto]
Decentralized!

[Alexander Hamilton]
Centralized!

[Satoshi Nakamoto]
Decentralized!

[Alexander Hamilton]
We need control!

[Satoshi Nakamoto]
Free enterprise!

[Debate moderator]
Bring me the facts.
Please testify.

[Satoshi Nakamoto]
Fiat's the way a government controls the populace.

[Alexander Hamilton]
Government protects its people. All of this is obvious.
They keep the peace, and so they keep control.
You want us ruled by crypto-miners no one even knows.

[Satoshi Nakamoto]
Oh, it’s that "Strong Central Government" bit again.
They protect people, but only their citizens.
Crypto has no borders, it's a true global currency.
And censorship resistance for those who need it urgently.

[Alexander Hamilton]
Banks earn trust by assuming liability.
You know a key, we know the customer explicitly.
Will the real Satoshi please stand up?
Nope, you’ll still be hiding when crypto busts.

[Satoshi Nakamoto]
You don’t need to trust the people, you just need to trust the code.
Every record’s in the network, you’re just one node.
And when you find a flaw, there’s a software update.
Now try updating cash. Go ahead, I’ll wait.

[Alexander Hamilton]
Wait? Cash works! You immediately pay.
Crypto's a far worse medium of exchange.
Can’t bitcoin the dentist, can’t bitcoin my breakfast.
Can’t even use bitcoin at bitcoin conventions.

[Satoshi Nakamoto]
No currency starts with universal adoption.
It takes time for places to make it an option.
Plus billions of people don’t have bank accounts.
No savings, no interest, no checks to bounce.

[Alexander Hamilton]
You’re saving the world? But what’s the price you’re paying?
The only change you’re creating is climate change.
Power grids spiking all across the land.
Overheated, no one needs it, hope it all is banned.

[Satoshi Nakamoto]
From the king of paper currency, the hypocrisy!
For bills and forms in triplicates, you’re killing all the trees.
Don’t like my power usage? Stop targeting my rights.
I own my purchased power and the market sets the price.

[Alexander Hamilton]
It’s gonna get real dark if this is crypto’s night.
They use your currency for crimes, that’s your kryptonite.

[Satoshi Nakamoto]
Most crime is done with Benjamins, not the blockchain.
There’s a reason most dollars carry traces of cocaine.

[Alexander Hamilton]
Where’s your proof of work? That’s pure speculation.
Those darknet black markets need more regulation.

[Satoshi Nakamoto]
The world’s fulla currencies. And this one makes it worse?
1 hundred eighty now, Bitcoin’s a hundred-eighty-first.

[Alexander Hamilton]
It’s not the currency itself, it’s the method, man.
You can’t build things that last without a central plan.

[Satoshi Nakamoto]
Crypto is a balance to the centralized model.
Cause things fall apart. The center cannot hodl.

[Alexander Hamilton]
If you end up having problems, I’ll feel bad for you, son.

[Satoshi Nakamoto]
I’ve got 99 problems but a bit ain’t one.

In this article, I'm going to tell you about the Brave Browser and show how it works.

I'll also help you decide whether it's worth registering your website or YouTube channel as a Brave publisher.

And if you want to register so you can get paid, I'll show you how to do that, too.

Every transfer freeCodeCamp.org has gotten from Brave since we signed up as a publisher (1 BAT = US $0.20)

But first, I want to temper your expectations. Unless you have a huge audience, Brave is unlikely to be a significant proportion of your income.

For some perspective:

1. freeCodeCamp.org is one of the top 2,000 most-visited websites
2. And our audience is mostly developers, who are much more likely to use the Brave Browser than a less-technical audience

In other words, your mileage may vary.

A quick note on my objectivity

Before anyone accuses me of using my influence to drive up the value of Brave's Basic Attention Token (BAT) cryptocurrency: we sold all of freeCodeCamp's BAT before publishing this.

We transferred it into freeCodeCamp's bank account, where it will help us cover this month's server costs.

By the way, if you want to support freeCodeCamp, I recommend you donate to us directly. This is where a vast majority of our nonprofit's budget comes from. The resources we get from Brave certainly help, but they don't even begin to cover the costs of running a nonprofit like ours.

What exactly is the Brave Browser?

Brave is an open source browser with a built-in ad blocker.

Brave was created by Brendan Eich - that same developer who created the JavaScript programming language back in 1995.

The big idea behind Brave is that instead of supporting websites by viewing their banner ads, you can pay them directly through your browser.

Here's how it works:

1. You use money to buy Brave's Basic Attention Token (BAT) cryptocurrency, and that BAT goes into your Brave wallet.
2. Brave will keep track of how much time you spend on each website or YouTube channel.
3. Then Brave will divide up your BAT and pay websites and YouTube channels each month based on how much time you spent using them.

This means instead of making a bunch of small individual donations to the dozens of websites and YouTube channels you use each month, you can just load money into Brave. Brave will then passively distribute that money for you.

Brave also has a manual "tipping" feature.

How do you make money from Brave?

First, you have to register your website or YouTube channel as a publisher. You can register as a Brave publisher here.

Then each month, if people are using Brave to browse your website or watch your videos, Brave will send you their Basic Attention Token (BAT) cryptocurrency through a service called Uphold.

In order to actually withdraw that BAT from Uphold (and convert it into another currency), you have to first create an Uphold account.

Note that this involves filling out forms and sharing a lot of sensitive information, such as your bank information, social security number, your ID, and your photo.

How can you can try out the Brave Browser itself?

Brave is free and open source. You don't have to pay money to use it.

But if you do put money into your Brave wallet, Brave will share 95% of that with the websites you visit. (Brave keeps 5% of it as a transaction fee).

If you install Brave using this link, Brave says they'll donate $5 to freeCodeCamp. Brave says - rather vaguely - that you have to "use the browser (minimally) over a 30 day period" in order for freeCodeCamp.org to get the $5. So I guess try to use it at least a little each day.

There are some other interesting aspects of Brave, too. For example, you can voluntarily view Brave's own ads - which are more anonymized than traditional ad network ads. Brave will then pay you a small amount of Basic Attention Token in exchange for your attention.

Brave's approach of replacing more intrusive ads on websites with more privacy-minded ads of their own is still a controversial one. But it could eventually pressure some of the worst actors in the "ad tech" space to become less intrusive themselves.

Does Brave have a bright future?

Over the past 2 years, aside from a few spikes, the value of Brave's BAT cryptocurrency has been around US $0.20 per token:

I don't know anyone working at Brave, and I don't have any information about their company that isn't already public.

According to Crunchbase, Brave hasn't raised any money since June of 2017, when they had one of the only successful ICOs in history, selling $35 million worth of BAT in less than 30 seconds.

It's possible they may not need to raise additional funding if they are making enough money through BAT and their operations.

If anything, Brave seems well-poised to grow. Google plans to essentially kill ad-blocker Chrome extensions. This may cause more people to switch over to a browsers with built-in ad blockers, like Brave.

How are your Brave earnings so far?

If you've been a Brave publisher for a while, I encourage you to share your numbers. How much have you all made from Brave so far?

I hope this guide has been a helpful resource for you. Happy coding.

I attended a talk on Ethereum sometime back and was fascinated by the possibilities it provided and started exploring the ecosystem. It is a pretty nascent ecosystem that is catching up fast among the developer community. In this post I will explain the technology behind Ethereum so that we can get started with developing with Ethereum. This assumes you have technology background and basic understanding of blockchain so that we can discuss the Ethereum implementation.

First things first

Blockchain provides a de-centralized, peer to peer network where digital assets can be transferred from one peer to another. The major problem we face in a de-centralized network is who will verify the validity of all the transactions taking place? The short answer is everyone.

Imagine a document with some information . Each person in the network keeps a copy of the same document. If there is an update in the document, it is propagated across the network and everyone updates their own copy of the document. Lets say a new person comes with different content in the document, then all the others can verify their copy and detect that the new person is lying and kick him out of the network. This is basically how a blockchain works.

First we need to understand few basic terms to get started.

Hash

We can use a cryptographic hash function(SHA256) to convert any string to its equivalent hash. The hash has two unique properties:

1. The hash produced has one to one mapping with the input string. The same input always produces the same unique hash and no other input can have the same hash.
2. Even a small change in the input string will lead to a large change in the output hash and thus the input can be easily validated.

Transaction

The process by which assets are moved from one party to another in the network is known as Transaction. All transactions are recorded and permanently stored.Lets say A wants to transfer 5 Ether to B. Then this is a transaction in the network.

Block

Many transactions are combined together to form a block. Each block consists a unique hash which identifies it in the network. A block is chained to previous block using the hash of the previous block.

Genesis Block

The initial block or state of the blockchain that is agreed upon by all the nodes in the network.

Blockchain

As the transactions are added many blocks are created and then they are chained together using their hashes into blockchain network.

Proof of work

A proof of work is a piece of data which is difficult (costly, time-consuming) to produce but easy for others to verify and which satisfies certain requirements. When there is a transaction in the network, any node that tries to process the transaction should solve a cryptographic puzzle for it to be accepted to the block. This is known as proof of work. The work that is to be performed can be done only by trial and error and this has to be performed for any valid transaction in the network before it can become part of the blockchain.

Mining

The process of processing a transaction and adding it to the block by carrying out the proof of work is known as mining. The miners(nodes) get the rewards of the transaction once the transaction is accepted as part of the blockchain.

Merkle Tree

A Merkle tree is a tree in which every non-leaf node is labelled with the hash of the labels of its child nodes. We can verify that the data blocks received from other nodes are received undamaged and unaltered, and even to check that the other nodes do not lie and send fake blocks.

Working

We can now move on to basic working of a blockchain.

1. Each node starts with genesis block and builds its way up to the “current state” of the blockchain. When it receives a new block each node verifies its hash and thus validates if its a valid block or not and keeps building the chain.
2. Once there is a transaction in the network, the miner mines it by generating the required proof of work. Then the miner adds it to his copy of the network and propagates the change to the nearby nodes.
3. All the nodes which receives it will validate the proof of work and then add it to their respective copies. If it is not valid, then the block is not added to the chain.
4. When there is a conflict in the network , then the “longest chain rule” is applied to resolve it. Lets say two miners claim the same block and both have valid proof of work. Then the longest chain rule is applied which is whichever miner has the longest chain of blocks will be taken as the winner and that is added to the blockchain.

Ethereum

Now that you have got a grasp of blockchain lets move ahead with Ethereum. Ethereum is a decentralized platform that allows us to write applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference. It consists of Ethereum Virtual Machine(EVM) which provides the container in which all the smart contracts can be executed.

Smart contracts

Ethereum allows us to write applications on the blockchain and this applications are known as smart contracts. These smart contracts reside on the blockchain and they are immutable in nature, ie. the code cannot be deleted or modified in the blockchain once it is deployed. This can be written using Solidity or other languages, but the most preferred is solidity. It is a turing complete language.

Ether

Ether is the cryptocurrency used in the Ethereum blockchain.

Accounts

In Ethereum, the state is made up of objects called “accounts”, with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. There are two types of accounts in Ethereum:

• Externally owned accounts : These accounts are owned by users, controlled by private keys. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction.
• Contract accounts: These accounts are owned by contract code. In a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.

Gas

As smart contracts are turing complete any infinity loop or other code can be written and the blockchain can be crashed. To prevent from such attacks Ethereum uses a concept called gas. Gas is nothing but some transaction cost which is paid to execute the transaction using Ether(basic currency in Ethereum chain). Each instruction requires some gas to be executed and the gas is sent along with any call that needs to modify the blockchain.

DAPPS

These are distributed apps that can be built using the smart contracts and providing an interface for the users(accounts). Different kinds of applications can be developed which will interact with smart contracts residing in the blockchain.

Basic Workflow using Ethereum

We can discuss a basic workflow in Ethereum network for better understanding of how all these concepts work together in unison.

1. We can write smart contracts and deploy it to Ethereum network. Once deployed these contracts cannot be changed.
2. Any account or another smart contract in the network can execute these smart contracts functions through transactions.
3. The smart contracts can be called and executed by sending transactions to the contract. These transactions cost gas and a certain gas should also be sent along with the transaction.
4. Sometimes we just need to know the state of some contract without modifying the blockchain. These are known as calls and they do not cost any gas.
5. We can build various Dapps by executing the smart contracts using transactions and calls , thus allowing the user to directly interact the smart contract in different ways.

I believe this post provides basic understanding of the blockchain and Ethereum. In my next post I will provide a detailed guide to getting started with building Dapps using Ethereum.

If you liked this story, feel free to reach out to me at https://kaizencoder.com/

Kriptofolio app series — Part 5

These days almost every Android app connects to internet to get/send data. You should definitely learn how to handle RESTful Web Services, as their correct implementation is the core knowledge while creating modern apps.

This part is going to be complicated. We are going to combine multiple libraries at once to get a working result. I am not going to talk about the native Android way to handle internet requests, because in the real world nobody uses it. Every good app does not try to reinvent the wheel but instead uses the most popular third party libraries to solve common problems. It would be too complicated to recreate the functionality that these well-made libraries have to offer.

Series content

• Introduction: A roadmap to build a modern Android app in 2018–2019
• Part 1: An introduction to the SOLID principles
• Part 2: How to start building your Android app: creating Mockups, UI, and XML layouts
• Part 3: All about that Architecture: exploring different architecture patterns and how to use them in your app
• Part 4: How to implement Dependency Injection in your app with Dagger 2
• Part 5: Handle RESTful Web Services using Retrofit, OkHttp, Gson, Glide and Coroutines (you’re here)

What is Retrofit, OkHttp and Gson?

Retrofit is a REST Client for Java and Android. This library, in my opinion, is the most important one to learn, as it will do the main job. It makes it relatively easy to retrieve and upload JSON (or other structured data) via a REST based webservice.

In Retrofit you configure which converter is used for the data serialization. Typically to serialize and deserialize objects to and from JSON you use an open-source Java library — Gson. Also if you need, you can add custom converters to Retrofit to process XML or other protocols.

For making HTTP requests Retrofit uses the OkHttp library. OkHttp is a pure HTTP/SPDY client responsible for any low-level network operations, caching, requests and responses manipulation. In contrast, Retrofit is a high-level REST abstraction build on top of OkHttp. Retrofit is strongly coupled with OkHttp and makes intensive use of it.

Now that you know that everything is closely related, we are going to use all these 3 libraries at once. Our first goal is to get all the cryptocurrencies list using Retrofit from the Internet. We will use a special OkHttp interceptor class for CoinMarketCap API authentication when making a call to the server. We will get back a JSON data result and then convert it using the Gson library.

Quick setup for Retrofit 2 just to try it first

When learning something new, I like to try it out in practice as soon as I can. We will apply a similar approach with Retrofit 2 for you to understand it better more quickly. Don’t worry right now about code quality or any programming principles or optimizations — we’ll just write some code to make Retrofit 2 work in our project and discuss what it does.

Follow these steps to set up Retrofit 2 on My Crypto Coins app project:

First, give INTERNET permission for the app

We are going to execute HTTP requests on a server accessible via the Internet. Give this permission by adding these lines to your Manifest file:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.baruckis.mycryptocoins">

    <uses-permission android:name="android.permission.INTERNET" />
    ...
</manifest>

Then you should add library dependencies

Find the latest Retrofit version. Also you should know that Retrofit doesn’t ship with an integrated JSON converter. Since we will get responses in JSON format, we need to include the converter manually in the dependencies too. We are going to use latest Google’s JSON converter Gson version. Let’s add these lines to your gradle file:

// 3rd party
// HTTP client - Retrofit with OkHttp
implementation "com.squareup.retrofit2:retrofit:$versions.retrofit"
// JSON converter Gson for JSON to Java object mapping
implementation "com.squareup.retrofit2:converter-gson:$versions.retrofit"

As you noticed from my comment, the OkHttp dependency is already shipped with the Retrofit 2 dependency. Versions is just a separate gradle file for convenience:

def versions = [:]

versions.retrofit = "2.4.0"

ext.versions = versions

Next set up the Retrofit interface

It’s an interface that declares our requests and their types. Here we define the API on the client side.

/**
 * REST API access points.
 */
interface ApiService {

    // The @GET annotation tells retrofit that this request is a get type request.
    // The string value tells retrofit that the path of this request is
    // baseUrl + v1/cryptocurrency/listings/latest + query parameter.
    @GET("v1/cryptocurrency/listings/latest")
    // Annotation @Query is used to define query parameter for request. Finally the request url will
    // look like that https://sandbox-api.coinmarketcap.com/v1/cryptocurrency/listings/latest?convert=EUR.
    fun getAllCryptocurrencies(@Query("convert") currency: String): Call<CryptocurrenciesLatest>
    // The return type for this function is Call with its type CryptocurrenciesLatest.
}

And set up the data class

Data classes are POJOs (Plain Old Java Objects) that represent the responses of the API calls we’re going to make.

/**
 * Data class to handle the response from the server.
 */
data class CryptocurrenciesLatest(
        val status: Status,
        val data: List<Data>
) {

    data class Data(
            val id: Int,
            val name: String,
            val symbol: String,
            val slug: String,
            // The annotation to a model property lets you pass the serialized and deserialized
            // name as a string. This is useful if you don't want your model class and the JSON
            // to have identical naming.
            @SerializedName("circulating_supply")
            val circulatingSupply: Double,
            @SerializedName("total_supply")
            val totalSupply: Double,
            @SerializedName("max_supply")
            val maxSupply: Double,
            @SerializedName("date_added")
            val dateAdded: String,
            @SerializedName("num_market_pairs")
            val numMarketPairs: Int,
            @SerializedName("cmc_rank")
            val cmcRank: Int,
            @SerializedName("last_updated")
            val lastUpdated: String,
            val quote: Quote
    ) {

        data class Quote(
                // For additional option during deserialization you can specify value or alternative
                // values. Gson will check the JSON for all names we specify and try to find one to
                // map it to the annotated property.
                @SerializedName(value = "USD", alternate = ["AUD", "BRL", "CAD", "CHF", "CLP",
                    "CNY", "CZK", "DKK", "EUR", "GBP", "HKD", "HUF", "IDR", "ILS", "INR", "JPY",
                    "KRW", "MXN", "MYR", "NOK", "NZD", "PHP", "PKR", "PLN", "RUB", "SEK", "SGD",
                    "THB", "TRY", "TWD", "ZAR"])
                val currency: Currency
        ) {

            data class Currency(
                    val price: Double,
                    @SerializedName("volume_24h")
                    val volume24h: Double,
                    @SerializedName("percent_change_1h")
                    val percentChange1h: Double,
                    @SerializedName("percent_change_24h")
                    val percentChange24h: Double,
                    @SerializedName("percent_change_7d")
                    val percentChange7d: Double,
                    @SerializedName("market_cap")
                    val marketCap: Double,
                    @SerializedName("last_updated")
                    val lastUpdated: String
            )
        }
    }

    data class Status(
            val timestamp: String,
            @SerializedName("error_code")
            val errorCode: Int,
            @SerializedName("error_message")
            val errorMessage: String,
            val elapsed: Int,
            @SerializedName("credit_count")
            val creditCount: Int
    )
}

Create a special interceptor class for authentication when making a call to the server

This is the case particular for any API that requires authentication to get a successful response. Interceptors are a powerful way to customize your requests. We are going to intercept the actual request and to add individual request headers, which will validate the call with an API Key provided by CoinMarketCap Professional API Developer Portal. To get yours, you need to register there.

/**
 * Interceptor used to intercept the actual request and
 * to supply your API Key in REST API calls via a custom header.
 */
class AuthenticationInterceptor : Interceptor {

    override fun intercept(chain: Interceptor.Chain): Response {

        val newRequest = chain.request().newBuilder()
                // TODO: Use your API Key provided by CoinMarketCap Professional API Developer Portal.
                .addHeader("X-CMC_PRO_API_KEY", "CMC_PRO_API_KEY")
                .build()

        return chain.proceed(newRequest)
    }
}

Finally, add this code to our activity to see Retrofit working

I wanted to get your hands dirty as soon as possible, so I put everything in one place. This is not the correct way, but it’s the fastest instead just to see a visual result quickly.

class AddSearchActivity : AppCompatActivity(), Injectable {

    private lateinit var listView: ListView
    private lateinit var listAdapter: AddSearchListAdapter

    ...

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        ...

        // Later we will setup Retrofit correctly, but for now we do all in one place just for quick start.
        setupRetrofitTemporarily()
    }

    ...

    private fun setupRetrofitTemporarily() {

        // We need to prepare a custom OkHttp client because need to use our custom call interceptor.
        // to be able to authenticate our requests.
        val builder = OkHttpClient.Builder()
        // We add the interceptor to OkHttpClient.
        // It will add authentication headers to every call we make.
        builder.interceptors().add(AuthenticationInterceptor())
        val client = builder.build()


        val api = Retrofit.Builder() // Create retrofit builder.
                .baseUrl("https://sandbox-api.coinmarketcap.com/") // Base url for the api has to end with a slash.
                .addConverterFactory(GsonConverterFactory.create()) // Use GSON converter for JSON to POJO object mapping.
                .client(client) // Here we set the custom OkHttp client we just created.
                .build().create(ApiService::class.java) // We create an API using the interface we defined.


        val adapterData: MutableList<Cryptocurrency> = ArrayList<Cryptocurrency>()

        val currentFiatCurrencyCode = "EUR"

        // Let's make asynchronous network request to get all latest cryptocurrencies from the server.
        // For query parameter we pass "EUR" as we want to get prices in euros.
        val call = api.getAllCryptocurrencies("EUR")
        val result = call.enqueue(object : Callback<CryptocurrenciesLatest> {

            // You will always get a response even if something wrong went from the server.
            override fun onFailure(call: Call<CryptocurrenciesLatest>, t: Throwable) {

                Snackbar.make(findViewById(android.R.id.content),
                        // Throwable will let us find the error if the call failed.
                        "Call failed! " + t.localizedMessage,
                        Snackbar.LENGTH_INDEFINITE).show()
            }

            override fun onResponse(call: Call<CryptocurrenciesLatest>, response: Response<CryptocurrenciesLatest>) {

                // Check if the response is successful, which means the request was successfully
                // received, understood, accepted and returned code in range [200..300).
                if (response.isSuccessful) {

                    // If everything is OK, let the user know that.
                    Toast.makeText(this@AddSearchActivity, "Call OK.", Toast.LENGTH_LONG).show();

                    // Than quickly map server response data to the ListView adapter.
                    val cryptocurrenciesLatest: CryptocurrenciesLatest? = response.body()
                    cryptocurrenciesLatest!!.data.forEach {
                        val cryptocurrency = Cryptocurrency(it.name, it.cmcRank.toShort(),
                                0.0, it.symbol, currentFiatCurrencyCode, it.quote.currency.price,
                                0.0, it.quote.currency.percentChange1h,
                                it.quote.currency.percentChange7d, it.quote.currency.percentChange24h,
                                0.0)
                        adapterData.add(cryptocurrency)
                    }

                    listView.visibility = View.VISIBLE
                    listAdapter.setData(adapterData)

                }
                // Else if the response is unsuccessful it will be defined by some special HTTP
                // error code, which we can show for the user.
                else Snackbar.make(findViewById(android.R.id.content),
                        "Call error with HTTP status code " + response.code() + "!",
                        Snackbar.LENGTH_INDEFINITE).show()

            }

        })

    }

   ...
}

You can explore the code here. Remember this is only an initial simplified implementation version for you to get the idea better.

Final correct setup for Retrofit 2 with OkHttp 3 and Gson

Ok after a quick experiment, it is time to bring this Retrofit implementation to the next level. We already got the data successfully but not correctly. We are missing the states like loading, error and success. Our code is mixed without separation of concerns. It’s a common mistake to write all your code in an activity or a fragment. Our activity class is UI based and should only contain logic that handles UI and operating system interactions.

Actually, after this quick setup, I worked a lot and made many changes. There is no point to put all the code that was changed in the article. Better instead you should browse the final Part 5 code repo here. I have commented everything very well and my code should be clear for you to understand. But I am going to talk about most important things I have done and why I did them.

The first step to improve was to start using Dependency Injection. Remember from the previous part we already have Dagger 2 implemented inside the project correctly. So I used it for the Retrofit setup.

/**
 * AppModule will provide app-wide dependencies for a part of the application.
 * It should initialize objects used across our application, such as Room database, Retrofit, Shared Preference, etc.
 */
@Module(includes = [ViewModelsModule::class])
class AppModule() {
    ...

    @Provides
    @Singleton
    fun provideHttpClient(): OkHttpClient {
        // We need to prepare a custom OkHttp client because need to use our custom call interceptor.
        // to be able to authenticate our requests.
        val builder = OkHttpClient.Builder()
        // We add the interceptor to OkHttpClient.
        // It will add authentication headers to every call we make.
        builder.interceptors().add(AuthenticationInterceptor())

        // Configure this client not to retry when a connectivity problem is encountered.
        builder.retryOnConnectionFailure(false)

        // Log requests and responses.
        // Add logging as the last interceptor, because this will also log the information which
        // you added or manipulated with previous interceptors to your request.
        builder.interceptors().add(HttpLoggingInterceptor().apply {
            // For production environment to enhance apps performance we will be skipping any
            // logging operation. We will show logs just for debug builds.
            level = if (BuildConfig.DEBUG) HttpLoggingInterceptor.Level.BODY else HttpLoggingInterceptor.Level.NONE
        })
        return builder.build()
    }

    @Provides
    @Singleton
    fun provideApiService(httpClient: OkHttpClient): ApiService {
        return Retrofit.Builder() // Create retrofit builder.
                .baseUrl(API_SERVICE_BASE_URL) // Base url for the api has to end with a slash.
                .addConverterFactory(GsonConverterFactory.create()) // Use GSON converter for JSON to POJO object mapping.
                .addCallAdapterFactory(LiveDataCallAdapterFactory())
                .client(httpClient) // Here we set the custom OkHttp client we just created.
                .build().create(ApiService::class.java) // We create an API using the interface we defined.
    }

    ...
}

Now as you see, Retrofit is separated from the activity class as it should be. It will be initialized only once and used app-wide.

As you may have noticed while creating the Retrofit builder instance, we added a special Retrofit calls adapter using addCallAdapterFactory. By default, Retrofit returns a Call<T>, but for our project we require it to return a LiveData<T> type. In order to do that we need to add LiveDataCallAdapter by using LiveDataCallAdapterFactory.

/**
 * A Retrofit adapter that converts the Call into a LiveData of ApiResponse.
 * @param <R>
</R> */
class LiveDataCallAdapter<R>(private val responseType: Type) :
        CallAdapter<R, LiveData<ApiResponse<R>>> {

    override fun responseType() = responseType

    override fun adapt(call: Call<R>): LiveData<ApiResponse<R>> {
        return object : LiveData<ApiResponse<R>>() {
            private var started = AtomicBoolean(false)
            override fun onActive() {
                super.onActive()
                if (started.compareAndSet(false, true)) {
                    call.enqueue(object : Callback<R> {
                        override fun onResponse(call: Call<R>, response: Response<R>) {
                            postValue(ApiResponse.create(response))
                        }

                        override fun onFailure(call: Call<R>, throwable: Throwable) {
                            postValue(ApiResponse.create(throwable))
                        }
                    })
                }
            }
        }
    }
}

class LiveDataCallAdapterFactory : CallAdapter.Factory() {
    override fun get(
            returnType: Type,
            annotations: Array<Annotation>,
            retrofit: Retrofit
    ): CallAdapter<*, *>? {
        if (CallAdapter.Factory.getRawType(returnType) != LiveData::class.java) {
            return null
        }
        val observableType = CallAdapter.Factory.getParameterUpperBound(0, returnType as ParameterizedType)
        val rawObservableType = CallAdapter.Factory.getRawType(observableType)
        if (rawObservableType != ApiResponse::class.java) {
            throw IllegalArgumentException("type must be a resource")
        }
        if (observableType !is ParameterizedType) {
            throw IllegalArgumentException("resource must be parameterized")
        }
        val bodyType = CallAdapter.Factory.getParameterUpperBound(0, observableType)
        return LiveDataCallAdapter<Any>(bodyType)
    }
}

Now we will get LiveData<T> instead of Call<T> as the return type from Retrofit service methods defined in the ApiService interface.

Another important step to make is to start using the Repository pattern. I have talked about it in Part 3. Check out our MVVM architecture schema from that post to remember where it goes.

As you see in the picture, Repository is a separate layer for the data. It’s our single source of contact for getting or sending data. When we use Repository, we are following the separation of concerns principle. We can have different data sources (like in our case persistent data from an SQLite database and data from web services), but Repository is always going to be single source of truth for all app data.

Instead of communicating with our Retrofit implementation directly, we are going to use Repository for that. For each kind of entity, we are going to have a separate Repository.

/**
 * The class for managing multiple data sources.
 */
@Singleton
class CryptocurrencyRepository @Inject constructor(
        private val context: Context,
        private val appExecutors: AppExecutors,
        private val myCryptocurrencyDao: MyCryptocurrencyDao,
        private val cryptocurrencyDao: CryptocurrencyDao,
        private val api: ApiService,
        private val sharedPreferences: SharedPreferences
) {

    // Just a simple helper variable to store selected fiat currency code during app lifecycle.
    // It is needed for main screen currency spinner. We set it to be same as in shared preferences.
    var selectedFiatCurrencyCode: String = getCurrentFiatCurrencyCode()


    ...


    // The Resource wrapping of LiveData is useful to update the UI based upon the state.
    fun getAllCryptocurrencyLiveDataResourceList(fiatCurrencyCode: String, shouldFetch: Boolean = false, callDelay: Long = 0): LiveData<Resource<List<Cryptocurrency>>> {
        return object : NetworkBoundResource<List<Cryptocurrency>, CoinMarketCap<List<CryptocurrencyLatest>>>(appExecutors) {

            // Here we save the data fetched from web-service.
            override fun saveCallResult(item: CoinMarketCap<List<CryptocurrencyLatest>>) {

                val list = getCryptocurrencyListFromResponse(fiatCurrencyCode, item.data, item.status?.timestamp)

                cryptocurrencyDao.reloadCryptocurrencyList(list)
                myCryptocurrencyDao.reloadMyCryptocurrencyList(list)
            }

            // Returns boolean indicating if to fetch data from web or not, true means fetch the data from web.
            override fun shouldFetch(data: List<Cryptocurrency>?): Boolean {
                return data == null || shouldFetch
            }

            override fun fetchDelayMillis(): Long {
                return callDelay
            }

            // Contains the logic to get data from the Room database.
            override fun loadFromDb(): LiveData<List<Cryptocurrency>> {

                return Transformations.switchMap(cryptocurrencyDao.getAllCryptocurrencyLiveDataList()) { data ->
                    if (data.isEmpty()) {
                        AbsentLiveData.create()
                    } else {
                        cryptocurrencyDao.getAllCryptocurrencyLiveDataList()
                    }
                }
            }

            // Contains the logic to get data from web-service using Retrofit.
            override fun createCall(): LiveData<ApiResponse<CoinMarketCap<List<CryptocurrencyLatest>>>> = api.getAllCryptocurrencies(fiatCurrencyCode)

        }.asLiveData()
    }


    ...


    fun getCurrentFiatCurrencyCode(): String {
        return sharedPreferences.getString(context.resources.getString(R.string.pref_fiat_currency_key), context.resources.getString(R.string.pref_default_fiat_currency_value))
                ?: context.resources.getString(R.string.pref_default_fiat_currency_value)
    }


    ...


    private fun getCryptocurrencyListFromResponse(fiatCurrencyCode: String, responseList: List<CryptocurrencyLatest>?, timestamp: Date?): ArrayList<Cryptocurrency> {

        val cryptocurrencyList: MutableList<Cryptocurrency> = ArrayList()

        responseList?.forEach {
            val cryptocurrency = Cryptocurrency(it.id, it.name, it.cmcRank.toShort(),
                    it.symbol, fiatCurrencyCode, it.quote.currency.price,
                    it.quote.currency.percentChange1h,
                    it.quote.currency.percentChange7d, it.quote.currency.percentChange24h, timestamp)
            cryptocurrencyList.add(cryptocurrency)
        }

        return cryptocurrencyList as ArrayList<Cryptocurrency>
    }

}

As you notice in the CryptocurrencyRepository class code, I am using the NetworkBoundResource abstract class. What is it and why do we need it?

NetworkBoundResource is a small but very important helper class that will allow us to maintain a synchronization between the local database and the web service. Our goal is to build a modern application that will work smoothly even when our device is offline. Also with the help of this class we will be able to present different network states like errors or loading for the user visually.

NetworkBoundResource starts by observing the database for the resource. When the entry is loaded from the database for the first time, it checks whether the result is good enough to be dispatched or if it should be re-fetched from the network. Note that both of these situations can happen at the same time, given that you probably want to show cached data while updating it from the network.

If the network call completes successfully, it saves the response into the database and re-initializes the stream. If the network request fails, the NetworkBoundResource dispatches a failure directly.

/**
 * A generic class that can provide a resource backed by both the sqlite database and the network.
 *
 *
 * You can read more about it in the [Architecture
 * Guide](https://developer.android.com/arch).
 * @param <ResultType> - Type for the Resource data.
 * @param <RequestType> - Type for the API response.
</RequestType></ResultType> */

// It defines two type parameters, ResultType and RequestType,
// because the data type returned from the API might not match the data type used locally.
abstract class NetworkBoundResource<ResultType, RequestType>
@MainThread constructor(private val appExecutors: AppExecutors) {

    // The final result LiveData.
    private val result = MediatorLiveData<Resource<ResultType>>()

    init {
        // Send loading state to UI.
        result.value = Resource.loading(null)
        @Suppress("LeakingThis")
        val dbSource = loadFromDb()
        result.addSource(dbSource) { data ->
            result.removeSource(dbSource)
            if (shouldFetch(data)) {
                fetchFromNetwork(dbSource)
            } else {
                result.addSource(dbSource) { newData ->
                    setValue(Resource.successDb(newData))
                }
            }
        }
    }

    @MainThread
    private fun setValue(newValue: Resource<ResultType>) {
        if (result.value != newValue) {
            result.value = newValue
        }
    }

    // Fetch the data from network and persist into DB and then send it back to UI.
    private fun fetchFromNetwork(dbSource: LiveData<ResultType>) {
        val apiResponse = createCall()
        // We re-attach dbSource as a new source, it will dispatch its latest value quickly.
        result.addSource(dbSource) { newData ->
            setValue(Resource.loading(newData))
        }

        // Create inner function as we want to delay it.
        fun fetch() {
            result.addSource(apiResponse) { response ->
                result.removeSource(apiResponse)
                result.removeSource(dbSource)
                when (response) {
                    is ApiSuccessResponse -> {
                        appExecutors.diskIO().execute {
                            saveCallResult(processResponse(response))
                            appExecutors.mainThread().execute {
                                // We specially request a new live data,
                                // otherwise we will get immediately last cached value,
                                // which may not be updated with latest results received from network.
                                result.addSource(loadFromDb()) { newData ->
                                    setValue(Resource.successNetwork(newData))
                                }
                            }
                        }
                    }
                    is ApiEmptyResponse -> {
                        appExecutors.mainThread().execute {
                            // reload from disk whatever we had
                            result.addSource(loadFromDb()) { newData ->
                                setValue(Resource.successDb(newData))
                            }
                        }
                    }
                    is ApiErrorResponse -> {
                        onFetchFailed()
                        result.addSource(dbSource) { newData ->
                            setValue(Resource.error(response.errorMessage, newData))
                        }
                    }
                }
            }
        }

        // Add delay before call if needed.
        val delay = fetchDelayMillis()
        if (delay > 0) {
            Handler().postDelayed({ fetch() }, delay)
        } else fetch()

    }

    // Called when the fetch fails. The child class may want to reset components
    // like rate limiter.
    protected open fun onFetchFailed() {}

    // Returns a LiveData object that represents the resource that's implemented
    // in the base class.
    fun asLiveData() = result as LiveData<Resource<ResultType>>

    @WorkerThread
    protected open fun processResponse(response: ApiSuccessResponse<RequestType>) = response.body

    // Called to save the result of the API response into the database.
    @WorkerThread
    protected abstract fun saveCallResult(item: RequestType)

    // Called with the data in the database to decide whether to fetch
    // potentially updated data from the network.
    @MainThread
    protected abstract fun shouldFetch(data: ResultType?): Boolean

    // Make a call to the server after some delay for better user experience.
    protected open fun fetchDelayMillis(): Long = 0

    // Called to get the cached data from the database.
    @MainThread
    protected abstract fun loadFromDb(): LiveData<ResultType>

    // Called to create the API call.
    @MainThread
    protected abstract fun createCall(): LiveData<ApiResponse<RequestType>>
}

Under the hood, the NetworkBoundResource class is made by using MediatorLiveData and its ability to observe multiple LiveData sources at once. Here we have two LiveData sources: the database and the network call response. Both of those LiveData are wrapped into one MediatorLiveData which is exposed by NetworkBoundResource.

NetworkBoundResource

Let’s take a closer look how the NetworkBoundResource will work in our app. Imagine the user will launch the app and click on a floating action button on the bottom right corner. The app will launch the add crypto coins screen. Now we can analyze NetworkBoundResource's usage inside it.

If the app is freshly installed and it is its first launch, then there will not be any data stored inside the local database. Because there is no data to show, a loading progress bar UI will be shown. Meanwhile the app is going to make a request call to the server via a web service to get all the cryptocurrencies list.

If the response is unsuccessful then the error message UI will be shown with the ability to retry a call by pressing a button. When a request call is successful at last, then the response data will be saved to a local SQLite database.

If we come back to the same screen the next time, the app will load data from the database instead of making a call to the internet again. But the user can ask for a new data update by implementing pull-to-refresh functionality. Old data information will be shown whilst the network call is happening. All this is done with the help of NetworkBoundResource.

Another class used in our Repository and LiveDataCallAdapter where all the "magic" happens is ApiResponse. Actually ApiResponse is just a simple common wrapper around the Retrofit2.Response class that converts each response to an instance of LiveData.

/**
 * Common class used by API responses. ApiResponse is a simple wrapper around the Retrofit2.Call
 * class that convert responses to instances of LiveData.
 * @param <CoinMarketCapType> the type of the response object
</T> */
@Suppress("unused") // T is used in extending classes
sealed class ApiResponse<CoinMarketCapType> {
    companion object {
        fun <CoinMarketCapType> create(error: Throwable): ApiErrorResponse<CoinMarketCapType> {
            return ApiErrorResponse(error.message ?: "Unknown error.")
        }

        fun <CoinMarketCapType> create(response: Response<CoinMarketCapType>): ApiResponse<CoinMarketCapType> {
            return if (response.isSuccessful) {
                val body = response.body()
                if (body == null || response.code() == 204) {
                    ApiEmptyResponse()
                } else {
                    ApiSuccessResponse(body = body)
                }
            } else {

                // Convert error response to JSON object.
                val gson = Gson()
                val type = object : TypeToken<CoinMarketCap<CoinMarketCapType>>() {}.type
                val errorResponse: CoinMarketCap<CoinMarketCapType> = gson.fromJson(response.errorBody()!!.charStream(), type)

                val msg = errorResponse.status?.errorMessage ?: errorResponse.message
                val errorMsg = if (msg.isNullOrEmpty()) {
                    response.message()
                } else {
                    msg
                }
                ApiErrorResponse(errorMsg ?: "Unknown error.")
            }
        }
    }
}

/**
 * Separate class for HTTP 204 resposes so that we can make ApiSuccessResponse's body non-null.
 */
class ApiEmptyResponse<CoinMarketCapType> : ApiResponse<CoinMarketCapType>()

data class ApiSuccessResponse<CoinMarketCapType>(val body: CoinMarketCapType) : ApiResponse<CoinMarketCapType>()

data class ApiErrorResponse<CoinMarketCapType>(val errorMessage: String) : ApiResponse<CoinMarketCapType>()

Inside this wrapper class, if our response has an error, we use the Gson library to convert the error to a JSON object. However, if the response was successful, then the Gson converter for JSON to POJO object mapping is used. We already added it when creating the retrofit builder instance with GsonConverterFactory inside the Dagger AppModule function provideApiService.

Glide for image loading

What is Glide? From the docs:

Glide is a fast and efficient open source media management and image loading framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface.

Glide’s primary focus is on making scrolling any kind of a list of images as smooth and fast as possible, but it is also effective for almost any case where you need to fetch, resize, and display a remote image.

Sounds like a complicated library which offers many useful features that you would not want to develop all by yourself. In My Crypto Coins app, we have several list screens where we need to show multiple cryptocurrency logos — pictures taken from the internet all at once — and still ensure a smooth scrolling experience for the user. So this library fits our needs perfectly. Also this library is very popular among Android developers.

Steps to setup Glide on My Crypto Coins app project:

Declare dependencies

Get the latest Glide version. Again versions is a separate file versions.gradle for the project.

// Glide
implementation "com.github.bumptech.glide:glide:$versions.glide"
kapt "com.github.bumptech.glide:compiler:$versions.glide"
// Glide's OkHttp3 integration.
implementation "com.github.bumptech.glide:okhttp3-integration:$versions.glide"+"@aar"

Because we want to use the networking library OkHttp in our project for all network operations, we need to include the specific Glide integration for it instead of the default one. Also since Glide is going to perform a network request to load images via the internet, we need to include the permission INTERNET in our AndroidManifest.xml file — but we already did that with the Retrofit setup.

Create AppGlideModule

Glide v4, which we will be using, offers a generated API for Applications. It will use an annotation processor to generate an API that allows applications to extend Glide’s API and include components provided by integration libraries. For any app to access the generated Glide API we need to include an appropriately annotated AppGlideModule implementation. There can be only a single implementation of the generated API and only one AppGlideModule per application.

Let’s create a class extending AppGlideModule somewhere in your app project:

/**
 * Glide v4 uses an annotation processor to generate an API that allows applications to access all
 * options in RequestBuilder, RequestOptions and any included integration libraries in a single
 * fluent API.
 *
 * The generated API serves two purposes:
 * Integration libraries can extend Glide’s API with custom options.
 * Applications can extend Glide’s API by adding methods that bundle commonly used options.
 *
 * Although both of these tasks can be accomplished by hand by writing custom subclasses of
 * RequestOptions, doing so is challenging and produces a less fluent API.
 */
@GlideModule
class AppGlideModule : AppGlideModule()

Even if our application is not changing any additional settings or implementing any methods in AppGlideModule, we still need to have its implementation to use Glide. You're not required to implement any of the methods in AppGlideModule for the API to be generated. You can leave the class blank as long as it extends AppGlideModule and is annotated with @GlideModule.

Use Glide-generated API

When using AppGlideModule, applications can use the API by starting all loads with GlideApp.with(). This is the code that shows how I have used Glide to load and show cryptocurrency logos in the add crypto coins screen all cryptocurrencies list.

class AddSearchListAdapter(val context: Context, private val cryptocurrencyClickCallback: ((Cryptocurrency) -> Unit)?) : BaseAdapter() {

    ...

    override fun getView(position: Int, convertView: View?, parent: ViewGroup?): View {
        ...

        val itemBinding: ActivityAddSearchListItemBinding

        ...

        // We make an Uri of image that we need to load. Every image unique name is its id.
        val imageUri = Uri.parse(CRYPTOCURRENCY_IMAGE_URL).buildUpon()
                .appendPath(CRYPTOCURRENCY_IMAGE_SIZE_PX)
                .appendPath(cryptocurrency.id.toString() + CRYPTOCURRENCY_IMAGE_FILE)
                .build()

        // Glide generated API from AppGlideModule.
        GlideApp
                // We need to provide context to make a call.
                .with(itemBinding.root)
                // Here you specify which image should be loaded by providing Uri.
                .load(imageUri)
                // The way you combine and execute multiple transformations.
                // WhiteBackground is our own implemented custom transformation.
                // CircleCrop is default transformation that Glide ships with.
                .transform(MultiTransformation(WhiteBackground(), CircleCrop()))
                // The target ImageView your image is supposed to get displayed in.
                .into(itemBinding.itemImageIcon.imageview_front)

        ...

        return itemBinding.root
    }

    ...

}

As you see, you can start using Glide with just few lines of code and let it do all the hard work for you. It is pretty straightforward.

Kotlin Coroutines

While building this app, we are going to face situations when we will run time consuming tasks such as writing data to a database or reading from it, fetching data from the network and other. All these common tasks take longer to complete than allowed by the Android framework’s main thread.

The main thread is a single thread that handles all updates to the UI. Developers are required not to block it to avoid the app freezing or even crashing with an Application Not Responding dialog. Kotlin coroutines is going to solve this problem for us by introducing main thread safety. It is the last missing piece that we want to add for My Crypto Coins app.

Coroutines are a Kotlin feature that convert async callbacks for long-running tasks, such as database or network access, into sequential code. With coroutines, you can write asynchronous code, which was traditionally written using the Callback pattern, using a synchronous style. The return value of a function will provide the result of the asynchronous call. Code written sequentially is typically easier to read, and can even use language features such as exceptions.

So we are going to use coroutines everywhere in this app where we need to wait until a result is available from a long-running task and than continue execution. Let’s see one exact implementation for our ViewModel where we will retry getting the latest data from the server for our cryptocurrencies presented on the main screen.

First add coroutines to the project:

// Coroutines support libraries for Kotlin.

// Dependencies for coroutines.
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:$versions.coroutines"

// Dependency is for the special UI context that can be passed to coroutine builders that use
// the main thread dispatcher to dispatch events on the main thread.
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$versions.coroutines"

Then we will create abstract class which will become the base class to be used for any ViewModel that needs to have common functionality like coroutines in our case:

abstract class BaseViewModel : ViewModel() {

    // In Kotlin, all coroutines run inside a CoroutineScope.
    // A scope controls the lifetime of coroutines through its job.
    private val viewModelJob = Job()
    // Since uiScope has a default dispatcher of Dispatchers.Main, this coroutine will be launched
    // in the main thread.
    val uiScope = CoroutineScope(Dispatchers.Main + viewModelJob)


    // onCleared is called when the ViewModel is no longer used and will be destroyed.
    // This typically happens when the user navigates away from the Activity or Fragment that was
    // using the ViewModel.
    override fun onCleared() {
        super.onCleared()
        // When you cancel the job of a scope, it cancels all coroutines started in that scope.
        // It's important to cancel any coroutines that are no longer required to avoid unnecessary
        // work and memory leaks.
        viewModelJob.cancel()
    }
}

Here we create specific coroutine scope, which will control the lifetime of coroutines through its job. As you see, scope allows you to specify a default dispatcher that controls which thread runs a coroutine. When the ViewModel is no longer used, we cancel viewModelJob and with that every coroutine started by uiScope will be cancelled as well.

Finally, implement the retry functionality:

/**
 * The ViewModel class is designed to store and manage UI-related data in a lifecycle conscious way.
 * The ViewModel class allows data to survive configuration changes such as screen rotations.
 */

// ViewModel will require a CryptocurrencyRepository so we add @Inject code into ViewModel constructor.
class MainViewModel @Inject constructor(val context: Context, val cryptocurrencyRepository: CryptocurrencyRepository) : BaseViewModel() {

    ...

    val mediatorLiveDataMyCryptocurrencyResourceList = MediatorLiveData<Resource<List<MyCryptocurrency>>>()
    private var liveDataMyCryptocurrencyResourceList: LiveData<Resource<List<MyCryptocurrency>>>
    private val liveDataMyCryptocurrencyList: LiveData<List<MyCryptocurrency>>

    ...

    // This is additional helper variable to deal correctly with currency spinner and preference.
    // It is kept inside viewmodel not to be lost because of fragment/activity recreation.
    var newSelectedFiatCurrencyCode: String? = null

    // Helper variable to store state of swipe refresh layout.
    var isSwipeRefreshing: Boolean = false


    init {
        ...

        // Set a resource value for a list of cryptocurrencies that user owns.
        liveDataMyCryptocurrencyResourceList = cryptocurrencyRepository.getMyCryptocurrencyLiveDataResourceList(cryptocurrencyRepository.getCurrentFiatCurrencyCode())


        // Declare additional variable to be able to reload data on demand.
        mediatorLiveDataMyCryptocurrencyResourceList.addSource(liveDataMyCryptocurrencyResourceList) {
            mediatorLiveDataMyCryptocurrencyResourceList.value = it
        }

        ...
    }

   ...

    /**
     * On retry we need to run sequential code. First we need to get owned crypto coins ids from
     * local database, wait for response and only after it use these ids to make a call with
     * retrofit to get updated owned crypto values. This can be done using Kotlin Coroutines.
     */
    fun retry(newFiatCurrencyCode: String? = null) {

        // Here we store new selected currency as additional variable or reset it.
        // Later if call to server is unsuccessful we will reuse it for retry functionality.
        newSelectedFiatCurrencyCode = newFiatCurrencyCode

        // Launch a coroutine in uiScope.
        uiScope.launch {
            // Make a call to the server after some delay for better user experience.
            updateMyCryptocurrencyList(newFiatCurrencyCode, SERVER_CALL_DELAY_MILLISECONDS)
        }
    }

    // Refresh the data from local database.
    fun refreshMyCryptocurrencyResourceList() {
        refreshMyCryptocurrencyResourceList(cryptocurrencyRepository.getMyCryptocurrencyLiveDataResourceList(cryptocurrencyRepository.getCurrentFiatCurrencyCode()))
    }

    // To implement a manual refresh without modifying your existing LiveData logic.
    private fun refreshMyCryptocurrencyResourceList(liveData: LiveData<Resource<List<MyCryptocurrency>>>) {
        mediatorLiveDataMyCryptocurrencyResourceList.removeSource(liveDataMyCryptocurrencyResourceList)
        liveDataMyCryptocurrencyResourceList = liveData
        mediatorLiveDataMyCryptocurrencyResourceList.addSource(liveDataMyCryptocurrencyResourceList)
        { mediatorLiveDataMyCryptocurrencyResourceList.value = it }
    }

    private suspend fun updateMyCryptocurrencyList(newFiatCurrencyCode: String? = null, callDelay: Long = 0) {

        val fiatCurrencyCode: String = newFiatCurrencyCode
                ?: cryptocurrencyRepository.getCurrentFiatCurrencyCode()

        isSwipeRefreshing = true

        // The function withContext is a suspend function. The withContext immediately shifts
        // execution of the block into different thread inside the block, and back when it
        // completes. IO dispatcher is suitable for execution the network requests in IO thread.
        val myCryptocurrencyIds = withContext(Dispatchers.IO) {
            // Suspend until getMyCryptocurrencyIds() returns a result.
            cryptocurrencyRepository.getMyCryptocurrencyIds()
        }

        // Here we come back to main worker thread. As soon as myCryptocurrencyIds has a result
        // and main looper is available, coroutine resumes on main thread, and
        // [getMyCryptocurrencyLiveDataResourceList] is called.
        // We wait for background operations to complete, without blocking the original thread.
        refreshMyCryptocurrencyResourceList(
                cryptocurrencyRepository.getMyCryptocurrencyLiveDataResourceList
                (fiatCurrencyCode, true, myCryptocurrencyIds, callDelay))
    }

    ...
}

Here we call a function marked with a special Kotlin keyword suspend for coroutines. This means that the function suspends execution until the result is ready, then it resumes where it left off with the result. While it is suspended waiting for a result, it unblocks the thread that it is running on.

Also, in one suspend function we can call another suspend function. As you see we do that by calling new suspend function marked withContext that is executed on different thread.

The idea of all this code is that we can combine multiple calls to form nice-looking sequential code. First we request to get the ids of the cryptocurrencies we own from the local database and wait for the response. Only after we get it do we use the response ids to make a new call with Retrofit to get those updated cryptocurrency values. That is our retry functionality.

We made it! Final thoughts, repository, app & presentation

Congratulations, I am happy if you managed to reach to the end. All the most significant points for creating this app have been covered. There was plenty of new stuff done in this part and a lot of that is not covered by this article, but I commented my code everywhere very well so you should not get lost in it. Check out final code for this part 5 here on GitHub:

View Source On GitHub.

The biggest challenge for me personally was not to learn new technologies, not to develop the app, but to write all these articles. Actually I am very happy with myself that I completed this challenge. Learning and developing is easy compared to teaching others, but that is where you can understand the topic even better. My advice if you are looking for the best way to learn new things is to start creating something yourself immediately. I promise you will learn a lot and quickly.

All these articles are based on version 1.0.0 of “Kriptofolio” (previously “My Crypto Coins”) app which you can download as a separate APK file here. But I will be very happy if you install and rate the latest app version from the store directly:

Get It On Google Play

Also please feel free to visit this simple presentation website that I made for this project:

Kriptofolio.app

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on May 11, 2019.

Meet Sato the Cryptobot, who is able to fetch any cryptocurrency price from an external API!

Chatbots have an incredible potential. Yet, for bots to be efficient, they must integrate and exchange data with existing services and processes.

The ability to fetch data from external API allows for more complex use case that a simple Q&A logic. Moreover, this ability combined with NLP offers even more opportunities.

For instance, Sato — the cryptobot we’ll be building today — is able to recognize all cryptocurrencies, even those not even listed yet. I won’t have to do anything for him to be able to process queries on crypto appearing even years from now, because Sato, deep-down, understood what a cryptocurrency symbol is (after being fed with thousands of them).

What are we building today?

By the end of this tutorial, we will have a bot able to fetch data from a third party API depending on what our users input, and reply to them with the value fetched. Here’s the end-result of what we’ll build today: a cryptobot aka a chatbot able to fetch any cryptocurrency price.

What you’ll have by the end of this tutorial

In a rush? Here is all you need to build your own:

• A chatbot created with SAP Conversational AI. Sign up here, it’s totally free!
• The GitHub repo

Need to see it to believe it? That’s wise! Click here!

Or if you would rather understand how it was made, go through with the tutorial.

1. Build the base of your chatbot: choose your path

The goal today is to build bot able to recognize a question about pricing on any cryptocurrency. Let your imagination flow, it could be really anything there is involving data available on third party APIs.

Before we dive in the tutorial, let me give you some information on how Sato works.

Meet Sato, the cryptobot

Sato is a bot made to answer basic questions about cryptocurrencies and fetch their prices. Here’s an overview of what he can do:

1. Fetch cryptocurrencies prices (what we’ll build today): Sato recognizes cryptocurrencies symbol (“ETH”, “BTC”) and fetch their price on cryptocompare API to finally return BTC and USD value to the user.
2. Answer the users’ questions about wallets — online wallets, exchange wallets, cold wallets and hardware wallets.
3. Address questions about private and public keys as well as the security of cryptocurrencies.
4. Briefly present the main cryptocurrencies, currently BTC, ETH, BCH and LTC.

Inside Sato

Today, we’ll focus on the skill fetching the crypto prices, as it requires an external API call. Essentially, Sato needs three things to be able to detect a question about crypto price and return the value asked:

Firstly, he needs an intent (@crypto_price) with diverse expressions and cryptocurrencies mentioned, so he can efficiently recognize these questions. Here are some of the expressions used to define the @crypto_price intent:

_A sample of the expressions used to define the @cryptoprice intent

Secondly, for Sato to be able to recognize all cryptocurrencies, he’ll need the biggest list you can find. I found 1200+ on CoinMarketCap which is good enough to begin with. I created a gazette of the crypto names to improve its understanding.

Thirdly, we’ll need to build a skill which triggers when the @ask_price intent or #crypto_name entity is recognized:

_Sato — Cryptobot / cryptomain skill triggers

You can also add #crypto_name as a requirements, to make sure no API called is fired without parameters:

_Sato — Cryptobot / cryptomain skill requirements

This skill must also call your webhook that we’ll setup below:

_Sato — Cryptobot / cryptomain skill actions

Don’t forget to add a memory reset after the webhook trigger, it’s required to clean the memory after each answer.

Finally, we’ll test our bot straight in Messenger, so you’ll need to create a page and an app and connect it. Everything is documented in the CONNECT tab and in the getting started tutorial.

To keep it concise, this tutorial will not detail the creation of a bot. We’ll start from a functioning bot already.

To meet me there, you have two options:

• Option A: build your own bot (who doesn’t have to be a cryptobot) by following the getting started tutorial and creating an account on SAP Conversational AI.
• Option B: fork Sato and start from here. That’s why SAP Conversational AI is a collaborative chatbot platform. It works pretty much like GitHub!

Forking a bot on SAP Conversational AI

2. Basic server code and requirements

Since we want to interact with our bot, we’ll need a server to be able to receive the results of the NLP made by SAP Conversational AI and send our responses back.

On the bot builder, go to the CODE tab to find an example of base code required to start your API. We give examples in Node.JS, PHP, Python and Ruby. This tutorial will be Python only.

Here’s the base code for Python:

from flask import Flask, request, jsonify import json app = Flask(__name__) port = '5000' @app.route('/', methods=['POST']) def index():   print(json.loads(request.get_data()))   return jsonify(     status=200,     replies=[{       'type': 'text',       'content': 'Roger that',     }]  )  @app.route('/errors', methods=['POST']) def errors():   print(json.loads(request.get_data()))   return jsonify(status=200)  app.run(port=port)

Take some time to look at the code to get a better understanding of what we’ll be doing: we’ll build on this code during this tutorial. You can save it in your favorite text editor for now.

Requirements

As you can see, the server script uses the Flask as a web framework, so we’ll need it.

For the API call, we’ll also use Requests. Let’s go ahead and install both:

pip install Flaskpip install requests

3. Test the server: NGROK

Now that we have the base server, let’s make it run and test it. It will allow us to be more incremental in the process so the debugging (if any) is simplified.

To expose our local server to the internet, we’ll need ngrok.

_Note: If you are using Windows like me, there is awesome package manager, Chocolatey which works pretty much like apt-get on UNIX. With it, you’ll be able to install ngrok in one line choco install ngrok_portable. Moreover, Chocolatey adds ngrok to your PATH, allowing you to start ngrok from any terminal simply by typing ngrok._

Now is the time to start our server and test it, this implies:

1. Set a webhook trigger in your bot (detailed in step 1)
2. Run your python script
3. Expose port 5000 to the internet with ngrok: ngrok http 5000
4. Copy the forwarding URL form ngrok and past it as your bot base URL on SAP Conversational AI

4. Preparing the external API call

It’s about time to start building! Let’s have a look at the api call we’ll be doing to get the price of any cryptocurrency. Several APIs are available for this purpose so I just went ahead and picked one: Cryptocompare API.

Cryptocompare API offers thousands of possibilities, but for the sake of simplicity, we’ll stick with the basics. We want the price of the matched crypto in BTC, USD and EUR.

Here’s how the call is structured (here for ETH):

https://min-api.cryptocompare.com/data/price?fsym="ETH"&tsyms=BTC,USD,EUR"

You have two parameters:

• fsym: the symbol of the cryptocurrency, this is where we’ll need to fetch the crypto_name recognized in the #crypto_name entity.
• tsyms: the currency in which the price will be returned. We chose BTC, USD and EUR here.

So, in our case, we’ll only need to adapt the fsym parameter to the recognized cryptocurrency, while the rest of the call stays the same.

5. Adapt the API call to include the symbol recognized in the user input

Now that we know how to fetch the prices, we need to go back to our server code and upgrade it so it can:

• Know the #crypto_name recognized by SAP Conversational AI.
• Make an API call to Cryptocompare using the #crypto_name.

Let’s get started!

Step 1: Finding our data in SAP Conversational AI JSON

Let’s have a look at the data returned by SAP Conversational AI on a user input. To do so, you click the CHAT WITH YOUR BOT button present on all pages, on the bottom-right corner. Then, you can switch between the conversation and the JSON view by clicking on the orange information circle as below:

Check the JSON of the conversation.

Here, our symbol is accessible with ['conversation']['memory']['crypto']['raw']. Since the value and the raw and identical in this case, you can use either.

On our server, the JSON returned by the website test panel is encapsulated into the data dictionary (see server code). So we need an extra step to retrieve it on our server:

# FETCH THE CRYPTO NAMEcrypto_name = data['conversation']['memory']['crypto']['value']

Step 2: Make an API call using the recognized entity

import requestsr = requests.get("https://min-api.cryptocompare.com/data/price?fsym="+crypto_name+"&tsyms=BTC,USD,EUR")

Go ahead and print it, but you may be disappointed:

Indeed, if you want to get the values returned by the call, you need to print r.json(). The good news is that JSON returned by Cryptocompare is really as simple as it could be:

Cryptocompare JSON

Great! Now, we just have one last step to figure out: returning the prices to the user.

Step 3: Returning the data fetched to the user

Now, it’s time to finish our base server code upgrade: we need to edit the replies returned to include our freshly fetched data. To do so, we’ll edit the message returned by our server code:

return jsonify(     status=200,     replies=[{       'type': 'text',       'content': 'Roger that',     }],

We’ll be editing the replies only, to include the prices we fetched:

replies=[{      'type': 'text',      'content': 'The price of %s is %f BTC and %f USD' % (crypto_name, r.json()['BTC'], r.json()['USD'])    }],

Since the reply is a string, we must use the modulo (%) operator to include our prices in the string. Here, the first %s tells Python to look for a string while the two following %f indicates floats.

Our upgraded server is now finished, here’s the whole code:

from flask import Flask, request, jsonifyimport jsonimport requestsapp = Flask(__name__)port = '5000'@app.route('/', methods=['POST'])def index():  data = json.loads(request.get_data())  # FETCH THE CRYPTO NAME  crypto_name = data['conversation']['memory']['crypto']['raw']  # FETCH BTC/USD/EUR PRICES  r = requests.get("https://min-api.cryptocompare.com/data/price?fsym="+crypto_name+"&tsyms=BTC,USD,EUR")  return jsonify(    status=200,    replies=[{      'type': 'text',      'content': 'The price of %s is %f BTC and %f USD' % (crypto_name, r.json()['BTC'], r.json()['USD'])    }]  )@app.route('/errors', methods=['POST'])def errors():  print(json.loads(request.get_data()))  return jsonify(status=200)app.run(port=port)

With our new server completed, we now have all the pieces of our puzzle. Let’s assemble it:

1. Run your python script,
2. Expose port 5000 to the internet with ngrok: ngrok http 5000,
3. Copy the forwarding URL form ngrok and past it as your bot base URL on SAP Conversational AI

Now that you have the basics to build a bot able to fetch third party data, what’s it gonna be? You show us!

PS: Since this tutorial uses ngrok, your computer must be on and ngrok must be running for your bot to function.

Originally published on SAP Conversational AI blog.

Blockchain has a diverse set of use cases, ranging from finance to a decentralized Internet. However, most blockchain use cases can be implemented using relatively few patterns. For example, A Pattern Collection for Blockchain-based Applications provides a list of 15 Blockchain patterns.

Fine-grained patterns, such as described above, are useful. However, system design needs a much higher level of abstractions. It is useful also to have more coarse-grained macro patterns, which we call architecture patterns. This post describes four such architecture patterns.

Let’s get started. To describe patterns, I will use the template described in by Aleksandra Tešanovic in What is a Pattern?

Architecture Pattern for IAM.

Context: IAM environments include many users and service providers. IAM systems give each user an account and set of capabilities enabling users to go to service providers, demonstrate their ownership of accounts, and then receive services based on their capabilities.

Forces: Need to implement a decentralized IAM environment where a single rogue user or few users can’t significantly affect the system.

Solution: Proposed pattern candidate uses World Wide Web Consortium (W3C) DID specification and W3C Verifiable Claims specification in the following manner.

Figure 1: Blockchain-based IAM Architecture Pattern

Let’s assume Alice needs an identity (DID, which is a unique identifier). As shown by the figure for creating a new DID, Alice creates an entry in the blockchain. This entry includes a randomly generated identifier, a link to the repository with her profile data, and a hash of the profile data. The user profile contains a public key and a set of verifiable claims. The generated random identifier now becomes Alice’s DID because only she owns the private key that corresponds to the public key.

Verifiable claims are delegation tokens signed by a competent authority. The creator also records them in a blockchain together with the hash of the claim in a manner similar to the DID.

Alice obtains the verifiable claims in the first place by going to authorities. For example, the department of personal registration or equivalent is the proper authority for verifiable claims of name, address, and date of birth. Assuming authorities issue verifiable claims, Alice first demonstrates her ownership of the DID uses a challenge-response-protocol. Then she submits requests for verifiable claims for her attributes, which may, for example, include her name, address, degree, and date of birth. To update her profile data, Alice will add a new entry to the blockchain with a new hash of the profile.

In the challenge-response-protocol, the validator generates a random seed, encrypts it using Alice’s public key, and then challenges Alice to demonstrate that she has the private key by decrypting the encrypted seed. Since Alice has the private key, she must be the owner of the DID.

A different user or an organization (authenticator), Bob, who wants to identify Alice, first receives the DID from Alice, read all entries related to that DID from the blockchain, retrieve Alice’s profile data, and verify them. Bob can verify the identity of Alice (identification) again using challenge-response-protocol. Then Bob can confirm the verifiable claims and be assured that the claims about Alice are true.

We can layer most IAM use cases on top of this architecture pattern. For example, we can achieve access control either by issuing verifiable claims for actions we want users to perform or by only accepting users who have certain properties (e.g., age, job description, group membership) in their verifiable claims. An implementation may choose to cache relevant subsets of the profile data in a database to improve performance.

Architecture Pattern for Auditable History or Workspace

Context: A two or more parties perform transactions or works together, and their activities need to be recorded in an indisputable manner.

Forces: Need to implement a decentralized audit log or a workspace where a single rogue user or few users can’t significantly affect the system.

Solution: The proposed system records activities and creates entries in the blockchain for those records. The entry contains the hash of activity records, and therefore, the records can’t be disputed later.

Figure 2: Blockchain based Auditable History or Workspace Architecture Pattern

For example, let’s assume Alice wants to pay a tax. Tax Server accepts the payment application, creates a digital receipt, records its hash in the blockchain, and sends the receipt to Alice. Alice can verify the receipt by calculating the hash and checking against the value stored in the blockchain. After this, Bob can’t deny the receipt because the receipt hash and time are recorded in the blockchain.

If the activities are numerous, there may be a need to workaround blockchain performance limitations. Therefore, some implementations may record a hash of several activity records as a block instead of a single activity record.

Architecture Pattern for Registry or Marketplace

Context: A registry is a collection of data entries that can be searched and retrieved over the network. A market place is a registry that allows users to buy the services or products represented by data entries. For example, a registry may be a catalog of available APIs.

Forces: Need to implement a decentralized environment where a single rogue user or few users can’t significantly affect the system.

Solution: The proposed pattern works as follows.

Figure 3: Blockchain based Registry Architecture Pattern

Let’s first consider a registry. With the proposed architecture, when a user issues a registry update (to add or modify an entry), the client records the change in the blockchain. If data in the update is large, the blockchain record may contain a link to the data and a hash value of the data. If data stored in the registry needs to be amended, the registry client adds a new record to the blockchain with amended information.

In the diagram above, each user has a registry client running in the local machine (e.g., laptop or phone). Each registry client reads the update records from the blockchain, verifies the update data against the hash included in the records, and reconstructs the most current view of records from updates. For example, by reading blockchain records about APIs, their additions, amendments, and removals, the registry client can create a view that shows current APIs included in the registry. To avoid having to read and verify all records every time the registry is used, clients might store data in a database and index it. The client should periodically check the blockchain and update the registry.

Blockchain works well as a “service marketplace,” since the same service may be sold many times. However, due to performance limitations, blockchain-based marketplaces are not suitable for items that can be sold only once.

To illustrate, the functionality of a blockchain-based registry, let’s look at when Alice wants to subscribe to “weather news service” in the blockchain marketplace. When she submits her request, the registry creates credentials for the service and shares it with Alice. The payment may happen in one of several ways: using Bitcoins, via a smart contract where payments are made on a timely basis, or by some out-of-bound means.

Architecture Pattern for Smart Contracts and Managed Things

Under this pattern, we consider two cases. First, we consider smart contracts, and as the second, we consider a common special case of smart contracts: “Managed Things.”

Smart Contracts Pattern

Context: Multiple users want to abide by a contract, described as an executable program. Contract undergoes state transitions as per conditions defined in the contract, and at a given time, everyone can agree on the current status of the contract.

Forces: need to implement an environment where a single rogue user or few users can’t significantly affect the system.

Solution: Smart contacts are part of blockchain technologies and supported by blockchain implementations, such as Ethereum. A contract is described using a smart contract language and distributed to all participants. As conditions defined in the contract changes, each participant executes the contract and records the current status in the blockchain using the consensus algorithm.

Managed Things Pattern

Context: We need to track the ownership of real-world smart things. Here smart things are real-world objects that are capable of running computing logic within them. The owner is allowed to control and perform actions on the real world things. Also, the owner may transfer his ownership to someone else.

Forces: need to implement an environment where a single rogue user or few users can’t significantly affect the system.

Solution: Following describes the implementation of the pattern using Car as the managed thing as an example.

Figure 4: Blockchain based Managed Things Architecture Pattern

We can implement a blockchain for a managed thing, in this case, a car, in two steps. First, the manufacturer records the DID and the public key of the owner of the car. When ownership changes, the owner adds a new record in the blockchain specifying the new owner. Second, when checking for ownership, the car first retrieves all records in the blockchain and verifies that each record is added by the owner at that time. This is done by checking the public key of the user who wrote the record against the public key included in the previous ownership record. The last owner in this valid chain is the current owner.

After determining the owner, the car logs in the current owner, Alice, by retrieving her public key and carrying out a challenge-response-protocol-based login with Alice’s phone, which has Alice’s private key.

Such a system reduces the risks associated with remotely controlled artifacts. For example, in a non-blockchain implementation, someone with access can change the ownership of your car. However, with the blockchain-based model, to remotely control the car, a would-be attacker must change the ownership record in the blockchain, which is very hard to achieve without being the owner.

However, it is hard to stop someone who has access to the “thing” from physically changing the logic running inside (e.g., by replacing the firmware of the car). One solution to this problem is to build some form of self-destruct that triggers when tampering into the artifact is detected.

For example, Alice buys the car from Bob using a smart contract that pays Bob and updates the ownership of the vehicle. After the transaction, Alice walks to the car, which reads Alice’s DID from the phone, retrieves her public key, authenticates her using a challenge-response-protocol by communicating with the phone that has Alice’s private key, verifies her ownership, and unlocks the car.

Conclusion

We discussed four blockchain based architecture patterns. The GitHub document, Blockchain-based Integration Use Cases, shows these patterns in action, describing how 30-plus blockchain use cases can be implemented using these four patterns.

If you have opinions about the above patterns or know about other patterns, I would really like to hear about them.

I hope this was useful. If you like this, you might also like a detailed blockchain analysis in our recently published paper, “A use case centric survey of Blockchain: status quo and future directions.”

We’re currently in the midst of a new burgeoning industry with blockchain development.

Blockchain technology is very much in a nascent stage, however this disruptive technology has already managed to take the world by storm and has experienced a boom like no other in recent times.

With many well-funded projects now eager to build out their blockchain network and deploy decentralized applications on top of them, there’s a great shortage of capable, competent blockchain developers.

With billions having been funneled into this sector, the pay and demand for blockchain developers has escalated with projects bidding against each other to attract the best blockchain talent that is left on the market.

This gold rush may leave some developers wondering if they have what it takes to dive into this industry, and especially what programming languages are most sought after in this new industry. Almost all popular programming languages are used in the blockchain industry, however developers have to consider what type of development they would like to undertake as different languages are used for certain blockchain projects and applications.

Here’s a brief rundown of the different languages and projects that are utilizing them to serve as a basic understanding and foundation for those looking to dive deeper into this industry.

Solidity — A new and simple programming language that is popular amongst Ethereum developers, as it is the language used for developing Ethereum smart contracts. Solidity is a contract-oriented Turing-complete programming language and the number of developers is estimated at over 200,000.

As Ethereum has taken the head start on smart contracts, many alternative blockchain platforms are ensuring that they are Solidity (or ERC-20) compatible, thus allowing smart contracts to be easily ported from Ethereum into their new blockchain networks.

Ethereum — Technically Ethereum functions as an Ethereum Virtual Machine (EVM) as a “world computer”, and is made up of multiple languages including C++, Python, Ruby, Go, and Java. JavaScript serves as the backbone of Ethereum as it functions as a runtime environment with script execution.

Java — A general-purpose programming language that is concurrent, object-oriented, and class-based is designed in such a way that Java has few implementation dependencies. Since its launch in 1995, Java has become one of the top 3 programming languages and rightly so with over 9 million developers. NEM’s core blockchain network has been written solely in Java (soon to be C++).

C# — An object-oriented language known to enable developers to build robust applications that run on the .NET Framework with at least 2M developers worldwide. C# was developed back in 2000. Since its inception, it has become a popular programming language used to build powerful cross platform code that works over multiple operating systems such as Windows, Mac, Linux, and Android. Blockchain projects written with C# include:

• Stratis a Blockchain-as-a-Service provider backed by Microsoft, allows enterprises to build their own private blockchain systems.
• NEO was written in C#, however it also supports a variety of programming languages such as Javascript, Java, Python, and Go.

Javascript — Often abbreviated as JS, this is a multi-paradigm language that supports event-driven, functional, and imperative (including object-oriented and prototype-based) programming styles. It is one of the most popular programming languages in the world used by at least 9.7M developers worldwide.

Lisk’s SideChain Development Kit (SDK) is written in JavaScript and allows developers to build applications on top of Lisk’s blockchain platform.

SQL — Structured Query Language or ‘’Sequel’’ is a programming language developed by IBM used to communicate with databases that store, query, and manipulate data. There is an estimated 7 million developers for SQL today. Popular databases such as MySQL, PostgreSQL, SQL Server, DB2, Oracle and more all use SQL to develop applications. A blockchain project that incorporates SQL is:

• Aergo — An entreprise-ready blockchain solution developed by Blocko under their proprietary Coinstack technology utilizes SQL smart contracts. The Aergo chain features a SQL-based smart contract platform that will allow enterprise entities to create and execute advanced smart contracts in commercial business environments.

C++ — A general-purpose programming language with an estimated 4.4 million developers, it’s greatest strength lies in the capability to scale resource intensive applications and enable them to run smoothly, thus making it a very popular programming language for 3D games. Blockchain projects using C++ include:

• EOS — C++ is the main programming language of EOS preferred for its flexibility to run extensive applications on top of the blockchain. EOS also supports any language that compiles into WebAssembly (WASM)

Random Fact: Bitcoin core’s network is programmed in C++.

Golang — An open source general programming language loosely based on the syntax of the C programming language, Golang is easy for developers to learn, and for testers to understand. Currently there is an estimated 800,000+ developers on the Golang language that is used by the consortium network:

• HyperLedger Fabric — Most of the chaincode (smart contracts built using HyperLedger Fabrics) is written in Golang. They also have a Java SDK for developing blockchain applications.

Hopefully this has provided you with a basic overview of where to start and what to dig into further if the blockchain industry is something that interests you. There is little doubt that this industry will continue to further explode over the next decade or so as advancements are made and real-world adoption use cases emerge.

Not everything will be tokenized, but that which can be will be.

2017 saw the hype of utility tokens and ICOs. 2018 marks the hyped start of asset tokenization and the launch of securities tokens/platforms. This trend is notably huge in the U.S, given how A16z and GGV Capital invested in the likes of tokenization platforms like TrustToken, Harbor, and Polymath.

In Asia, the trend is starting to pick up too. For instance, Rate3 Network was funded by various notable Asian VCs that include Matrix Partners China and Fenbushi Capital.

Conceptually, tokenization might seem easy: Issue an ERC-20 token (or any other blockchain tokens), imbue legal rights and ownership rights in the tokens, and you can trade them easily. However, this warrants a much deeper look: how do you distinguish claim rights and ownership rights? What are the differences in tokenization between different asset classes? What is impeding tokenization from adoption?

Thinking comprehensively about tokenization requires an understanding of blockchains and smart contracts, legal, finance, and economics. There has already been in-depth research on each of these components.

In this piece, I want to give a comprehensive introduction to tokenization through using real estate as a primary example. Here’s what we’ll discuss:

• What exactly is Tokenization? (Is it not just securitization?)
• What are the real benefits of tokenization? (Why do we even bother?)
• What are some of the tougher issues to think about? (How do we ask the right questions?)
• What are the challenges for tokenization? (What’s stopping adoption?)
• How will the tokenized future be? (What are some elements?)

Let’s get started!

What is Tokenization?

Isn’t Tokenization just securitization?

For structured finance professionals, tokenization might seem like securitization. In summary, securitization consists of a few steps:

1. Originator (owner of the assets) collects the assets in a pool and transfers the pool to a legal entity (usually a special purpose vehicle). Through this legal structure, assets are not exposed to counter-party risks or risk of bankruptcy of the originator bank
2. The SPV structures the assets within the pool into several tranches, according to different risk levels and characteristics usually. Securities are issued, and backed by the cash flows generated by the underlying assets.
3. After issuing the securities, the SPV sells the securities to investors, whilst transferring the proceeds to the originator afterwards.

Securitization has various flaws.

The classic securitization process is extremely costly and takes up a lot of time. The entire process might cost up to millions of dollars and takes up to a year. The securitization process requires agreements with various parties under conditions of asymmetric information, as well as a heterogeneous structure of asset data.

Furthermore, there might be a lack of full transparency in the various stages of securitization, all of which hinder auditing and rating of the underlying assets. In the sub-prime mortgage crisis, there is no transparency on the credit pool nor the audit process that lead to defaults on the bonds issued.

Clearly, tokenization =/= securitization

Tokenization — in its simplest definition — refers to converting an asset into a digital token on the blockchain system. The biggest difference between tokenization and securitization, is how programmability is introduced into the tokenized asset. This way, business logic can be introduced, reducing the need for manual settlements. Smart contracts can have functions for automatic transactions, formulas for calculating asset prices and other specific features.

What are the real benefits of Tokenization then?

Photo by @sanfrancisco, Unsplash

Numerous research pieces have talked about various benefits of tokenization, but these various benefits can be categorized into three core principles: 1) liquidity, 2) programmability and 3) immutable proof of ownership.

Key Principle 1: Liquidity

World Economic Forum predicts that over the next ten years, 10% of the world’s GDP will be stored in crypto assets, amounting to $10 trillion. This is primarily due to increased fractional ownership, and unlocking of liquidity premiums.

Assuming no legal and regulatory barriers, tokenization allows for increased fractional ownership. Most tokens can be broken into 18 decimals, as compared to fiat which can be broken down to $0.01 only. Fractional ownership lowers the barriers of entry for new investors. For instance, instead of paying $1 million for a new apartment, I can pay $50,000 for a tokenized fraction of the real estate. For investors, fractional ownership and lower barriers help them to increase portfolio diversification and construct a “truer” market portfolio.

The increase in liquidity helps unlock value for markets through liquidity premiums. When illiquid assets become more liquid, a liquidity premium of approximately ~20–30% is unlocked. One example is real estate: Even a fractional improvement in the sales price of such investments could result in trillions of dollars of new value for issuers and resellers.

Key Principle 2: Programmability built into tokens

Programmability refers to the ability to introduce certain business logic into smart contracts, allowing for automated events to occur. Tokenization can also lead to easier management of investors and their rights. Secondary transactions can be easily tracked by collaborating with third-party exchanges, allowing investors to receive distributions and exercise their other rights (e.g., voting) through the blockchain.

Programmability is especially useful in increasing the speed of settlements. In traditional finance, settlements refer to the process of documentation of the transfer of asset ownership before the ownership of assets actually changes hands. Compliance can be programmed into the tokens, if all participants have a digital identity that has gone through the relevant compliance/KYC/AML checks.

Key Principle 3: Immutable proof of ownership

Blockchains are immutable and keep a public trace of every transfer, and owner. This digital trace of transactions not only proves the history of ownership but also helps to ensure less fraud. The immutable structure makes it impossible for a token-holder to “double-sell” a token — accepting a transfer for the same token to two different sources. This helps assure investors that no one can falsify transactions after the transaction has happened.

Let’s dive deeper into tokenization.

Tokenization is the process of digitally storing the property rights to a thing of value (asset) on a blockchain or distributed ledger, so that ownership can be transferred via the blockchain’s protocol. What are the other challenges?

Issue #1: What are the requirements for tokenization to take place?

There are 3 fundamental requirements:

1. The rights to an asset can be stored digitally on a blockchain

Let’s go back to the real estate example. If I want to tokenize my house, I must be able to record my ownership of my house on a token itself. This means that to regulatory authorities, holding a token represents an ownership right or claim right on the house itself. (We will go into these rights in a bit.)

2. These rights can be legally transferred via blockchains

Whilst I can document my rights to my house in a legally-recognized way, I should be able to transfer these rights to anyone I want and that person will have legal ownership of my house, assuming my tokens are imbued with ownership rights.

3. Tokens can be easily exchanged for value, giving the assets “value”

Lastly, like any security, I must be able to exchange my real estate token for value easily — so I can subscribe value to the asset.

Issue #2: What are the other legal issues to consider?

Apart from the 3 requirements, what is more crucial to take note is the exact asset you are tokenizing: Does the token represent a claim on the asset or does the token represent actual ownership of the asset itself? Investors and token issuers must think carefully about what exactly a token represents.

The truth is: it depends on what you want to tokenize. Tokenization is flexible. Using real estate as an example again, what can be tokenized could be direct ownership in the real estate (being a partial equity owner), right to rental income, or even the right to use an asset (renting the apartment).

Hence, a token could represent ownership of the underlying real asset, an interest in a debt secured by the asset, an equity interest in a legal entity that owns that asset, or a right to the cash flow from the asset.

There are 3 basic categories of rights to understand.

The rights bestowed by tokenized securities (or security token) can be very complex to understand. However, tokenized securities can include claims to the assets (and usually the resulting cash flows), direct ownership rights, governance rights or a combination of all.

1. Claim rights: Claims to only certain specific uses (and claims) of the asset
2. Ownership rights: Equity ownership and control of the asset
3. Governance: System by which a group of people can come to unified decisions

Let’s illustrate this with real estate again, with a few examples on the token holders’ rights:

1. Claim rights, but no ownership rights: Token holders are entitled to cash flows from ongoing leases, but they have no ‘equity’ and ‘ownership’ of the underlying real estate
2. Claim rights, AND ownership rights: Token holders are the ‘owners’ of the underlying real estate with claims to the cash flows. They can make decisions directly: how much to charge for rent, investments made to maintain the real estate, hiring staff and given the proceeds from the sale of the real estate.
3. Only ownership rights: This example is rarely the case, but it means that token holders are now the ‘equity owners’ of the real estate.

What are the challenges that arise from these different rights?

It is possible that there is a separation of claim rights and ownership rights, and this creates misaligned incentives between both parties.

What if… the tokens have ownership rights for token holders? How do 1,000 token holders make decisions collectively for the best of the assets? Is there a need for delegated voting or decision making?

What if… the tokens only imbue claim rights for token holders? The token issuers (owners) can reduce profits and cash flows to the token holders, by re-investing the profits. This will be to the detriment of token holders who originally look towards the future cash flow.

The smart contract geek might ask: can’t one automate all these logic in smart contracts?

No, smart contracts cannot solve all these issues.

Contracts and smart contracts are incomplete:

1. Contracts are only enforceable when events and actions can be verified by a third party

This is the long-standing problem of “oracles” in tokenization. There are some events that can be captured in code, but near impossible for any arbiter to determine if they really happened.

For instance, I issued out real estate tokens to holders so they can receive a portion of the rental income. However, it is possible that I do not document down all the rental agreements so token holders do not know what the real amount of rental income is. If this cannot be enforced effectively, there is no rational reason for parties to abide by the smart contract.

2. It is near impossible to write a contract that contains all possible conditions and events, hence achieving “completeness”

The problem with contracts is not what is in them, it is what is not in them. It is very costly and operationally challenging to write down every condition and event. Furthermore, events and conditions change in real life — and contracts have to adapt to these real-life changes.

Given the limitations of smart contracts as inherently incomplete, certain asset types should not be tokenized.

What should not be tokenized?

1. When the blockchain cannot fully capture the change of ownership of assets

There are some assets in markets where I can sell the physical asset outside of the protocol directly, despite it being tokenized. For instance, I can tokenize real estate and transfer the token (with ownership rights) to you, but it is possible I can also legally sell the same real estate to another.

There are also other cases when I can trade tokens, but have no guarantees that I can verify the authenticity of the underlying asset. In the case of real estate, it is easier to verify, but other examples include gold bars. If it takes a lot of costs and resources to verify the authenticity, tokenization might not be a viable solution.

2. When the use of prices impede the protocol from achieving its objectives

There are some situations in which we don’t want prices to determine who gets what. Sometimes, prices do not capture external societal benefits and costs, and might not be the most equitable way to allocate resources. Examples include social goods, for instance.

3. Sometimes, we just do not want to tokenize some ‘assets’ and rights

For instance, rights to birth certificates or educational records should not be tokenized since they represent a unique right. We do not, and should not tokenize these ‘assets’.

Clearly, there are some asset classes that _should no_t be tokenized, given real-life limitations.

How do you really tokenize?

We have walked through the what and why of tokenization, now let’s talk a little about the how of tokenization.

There are a few categories of assets that have been tokenized:

• Fiat currencies

The tokenization of fiat currencies gave rise to stablecoins. Tether is the first example, creating USDT. However, there are inherent challenges with Tether. For a good, updated summary on stablecoins, I suggest this:

Stablecoins are now officially in vogue again
_With seemingly one new project unveiling multi-million-dollar funding every other week, no one will blame you for…_blog.goodaudience.com

• Gold

An example of a gold tokenization project is Digix.

Each DGX token is 1:1 gold-backed, and 1 token represent 1 gram of 99.99% gold from London Bullion Market Association-certified refiners, with gold stored in The Safehouse vault. Purchasing 1 DGX token is equivalent to purchasing actual gold itself.

• Real Estate

My primary interest lies in real estate, given the analogy between REITs and tokenized real estate. A few interesting examples are how a Manhattan real estate property was most recently tokenized, or how a portion of the St. Regis Aspen is tokenized. In the case of St. Regis Aspen, each Aspen token represents an indirect ownership interest in a common stock of the St. Regis Aspen REIT. According to Elevated Returns, the “REIT provides tax efficient structure while the blockchain provides peer-to-peer investing and cross-border transaction made simpler for investors.”

Clearly, there are many challenges associated with tokenization.

1. Lack of tokenization standards and legal infrastructure

Tokenization is not simply the creation of a token — any Solidity developer can do it. Instead, it’s about the design of the whole system, including understanding the various rights and issues we’ve talked about previously.

How do tokenization standards cater for these issues:

• Incentives (claim rights, ownership rights, governance)
• Privileges of users and system admins (who operate the token contracts)
• Life-cycle management of an asset (issuance, payouts, withdrawal)
• Security management
• Integration of KYC/AML requirements across different jurisdictions
• Integration with exchanges
• Interoperability between different public chains

In the case of cross-chain interoperability, we do see different chains with different nascent characteristics. For instance, Ethereum has scalability issues but provides for more complex Turing-complete smart contracts. How about other public blockchain networks like Stellar or IOST or Zilliqa?

How can tokenized assets (in the form of tokens) be interoperable across these different chains?

2. Digital identity that’s globally and legally-recognized

From a regulatory point of view, it is a regulatory nightmare for assets to be issued and transferred across citizens of different legal jurisdictions.

Suppose I am an EU resident looking to tokenize my real estate and the token only imbues claim rights. How do I transfer this token to U.S persons, whilst taking into account their identity, KYC/AML issues, U.S regulations, taxes and all the other issues?

How can I reasonably and easily deal with a verified, attested U.S person in a legally-compliant way for both our national jurisdictions?

3. Tokenization does not mean instant liquidity

Liquidity is the biggest challenge in the security token space and it does not happen organically. History has given us various examples of financial markets and instruments that have not yet achieved significant levels of liquidity. Helping to create liquidity through allowing institutional investors or accredited retail investors — through custodian solutions will be key. Of course, the underlying asset must be useful.

How do we introduce long-term, sustainable solutions for large institutional investors — the market makers — to create and maintain liquidity?

What does a tokenized future look like?

I’m generally bullish on a tokenized future: a fairer, more equitable world with lower barrier to entry and capital requirements for individuals or businesses.

Through capturing value in tokenized assets, we can re-create all the sophistication of the existing financial and operational world we live in, with far less operational costs and complexities. When combining tokenization with reasonably complex business logic enabled by smart contracts, we can represent complex business interactions faithfully and more efficiently.

There will be interoperability, through standardization

ERC 20 for token standards, as an example

If the ecosystem for global assets becomes interoperable, it means we can hold ownership claims to a commercial building, early-stage equity, corporate bonds, a T-bill, a single-family residence, and a decentralized network on the same platform.

Different assets can reference each other contractually and interact in an automated way. It means an increased liquidity for all (tokenized) asset classes.

ERC 725 for Identity, as another

Fabian Vogelstellar — creator of the ERC 20 standard — is leading the front for a unique decentralized identity for “humans, groups, objects and machines”. Quoting directly from the ERC 725 Github itself, “ This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self-attested (#ERC735), as well as a proxy function to act directly on the blockchain”.

You can read more here about ERC 725 here:

ERC: Identity · Issue #725 · ethereum/EIPs
_eip: title: ERC-725 Identity author: Fabian Vogelsteller (@frozeman) discussions-to…_github.com

There are notable projects that have been working on implementing ERC 725 identity contracts. A few examples are: Origin Protocol and Rate3 Network.

Managing Identity with a UI for ERC 725
_At Origin, we’re building a platform for decentralized, peer-to-peer marketplaces. You can imagine a future Airbnb-like…_medium.comRate3 Cross-Chain Identity Protocol — Identity and Claims (ERC 725, ERC735)
_At Rate3, we initially wanted to build a blockchain-based settlement and clearance network for businesses. We…_medium.com

The future of tokenization is not here (yet), but it will be sooner than we know

We are optimistic and bullish for the future of tokenization and tokenized securities. There are many elements of the envisioned tokenized future that we observe today:

1. Governments are increasingly partnering with private companies to create infrastructural solutions

One such example is the collaboration between NASDAQ, Monetary Authority of Singapore (Singapore’s Central Bank) and Singapore Exchange (Singapore’s main stock exchange) to develop Delivery versus Payment capabilities for settlement of tokenized assets across different blockchain platforms to improve operational efficiency and reduce settlement risks.

MAS and SGX partner Anquan Deloitte and Nasdaq to harness blockchain technology
_Singapore, 24 August 2018… The Monetary Authority of Singapore (MAS) and Singapore Exchange (SGX) today announced a…_www.mas.gov.sg

2. Projects have recognized the need for compliance, and are creating solutions that target automated compliance and AML/KYC

We have touched about the need to meld real-world legal requirements into the blockchain space. There are various projects that have been doing these globally:

1. Harbor: A compliance platform and protocol to ensure tokenized securities comply with existing securities laws at issuance and on every trade, everywhere across the globe.
2. Rate3 Network: A protocol that handles asset-tokenization and identity management across both Ethereum and Stellar blockchains.
3. Polymath: A security token platform on which regulatory-compliant tokens can be built

I do notice more blockchain projects building tokenization solutions targeted at different asset classes, different ways of modeling structured finance through issuing both debt and equity tokens, for instance. More importantly, these solutions know that working directly with regulatory authorities, collaborating with central banks and other projects will help to improve the overall ecosystem.

Ensuring the legally-compliant design of the whole system is key.

3. “Paths of least resistance” will help everyone relate existing real examples to upcoming tokenization projects

Real estate have always been quoted as an example for tokenization projects. This is due to the structure of real estate investment trusts (REITs), that one could relate more easily to tokenized structures.

Tokenized real estate is not REITs, but there are various principles we can use to help us understand, relate and think better: property rights, economics for REITs for instance.

Not everything will be tokenized, but those that can be will be.

Disclosure: I work at Rate3 Network, a dual-protocol that handles asset-tokenization and identity management across both Ethereum and Stellar blockchains.

Update

On November 2nd MetaMask and other dapp browsers will stop exposing user accounts by default. This will make some code from this paper to break. I will publish updated version with web3 1.0 and new MetaMask interface.

Metamask is the de facto standard for dApps on the web. It injects a Web3 instance into a window object making it available for JavaScript code.

We are going to use Web3 0.20 version, not Web3 1.0. The code for Web3 1.0 would be different.

Every dApp has its mission, but the way they interact with Metamask is similar. In this article, we’ll cover the ten most common practices to handle Web3/Metamask interactions.

#1. Detect Metamask and instantiate Web3

According to docs, here’s the best way to do it.

What is going on here? First, we check if Web3 was injected. If it is injected we create a new instance using the injected provider. Why is that? Because we want to use our library version, not the one injected by Metamask.

If Web3 is not present, we try to connect to a localhost provider, like ganache.

#2. Check if Metamask is locked

Metamask can be installed but locked. In order to interact with a user account and send transactions, the user has to unlock Metamask.

#3. Check the current network

There are many test networks beyond the main network. Typically your contract is deployed to a certain network. You want to be sure that the user runs Metamask on the same network.

#4. Get the current account

A user may have multiple accounts at Metamask, but they expect the dApp to interact with the current one.

You should always grab the account from the Web3 instance. Do not keep and reuse it, because the user may change their account at any time.

#5. Get the balance on the current account

Here we use the function getAccount from #4 and call getBalance. Easy.

#6. Detect that the current account has changed

A user may change their account at any time. You dApp should be ready for that and react properly.

#7. Detect whether Metamask is locked/unlocked

Similar to #6. A user may lock/unlock anytime. Your dApp should handle it correctly.

#8. Handle cancel/confirm

Once a user interacts with your dApp, you have to send a transaction using the Web3 API. A user may press the cancel or confirm button on the Metamask popup. This may lead to UI inconsistency if not handled correctly.

In order to return instantly with the transaction hash, call contract.methodName.sendTransaction.

#9. Get the transaction receipt

Once your dApp transaction is mined, a transaction receipt becomes available. Yet there is no event/notification, so we have to implement a poll mechanism.

#10. Listen for Web3 events

Solidity events are great. They allow switching from ugly polling to just a push mechanism, assuming your contract implements all necessary events. You can completely avoid polling and just react to events. Event callback returns a lot of data, but we are mostly interested in args.

Summary

Whatever your dApp is about, it still has to perform common tasks, such as detecting Web3, getting the account state and balance, recognizing the current network, and handling transactions and events. We’ve gone over how it can be done using ten code snippets.

P.S.

A lot of examples here use methods which might throw an error because of Metamask’s state or some variables being undefined at the moment of a call. You should wrap them in try/catch in a production environment.
Async/await has been used here for simplicity. It can be replaced with Promise then/catch.

Social

• Connect with me on LinkedIn.
• Follow me on twitter.

Want More?

How to Create and Deploy Your Own EOS Token
_We are going to figure out what is EOS token and how you can create and deploy one yourself._hackernoon.comHow Much Does It Cost to Run DApp in 2018
_You think your AWS or Digital Ocean bill for your website is killing you?_hackernoon.comDifference Between Ethereum and EOS Tokens
_Ethereum has ERC-20 token and EOS has EOSIO.Token. They serve the same purpose, but are they the same?_medium.com

Originally published at ylv.io on October 15, 2018.

Kriptofolio app series - Part 4

Dependency injection will significantly improve your code. It makes your code more modular, flexible and testable. Actually its name sounds more complicated than the idea which stands behind it.

In this part of the series we are going to learn about dependency injection. We will then implement it in “Kriptofolio” (previously “My Crypto Coins”) app. We are going to use Dagger 2. Dagger 2 is the most popular open-source dependency injection framework for Android. This is a valuable skill to have for creating modern apps, even thought the learning curve is hard enough.

Series content

• Introduction: A roadmap to build a modern Android app in 2018–2019
• Part 1: An introduction to the SOLID principles
• Part 2: How to start building your Android app: creating Mockups, UI, and XML layouts
• Part 3: All about that Architecture: exploring different architecture patterns and how to use them in your app
• Part 4: How to implement Dependency Injection in your app with Dagger 2 (you’re here)
• Part 5: Handle RESTful Web Services using Retrofit, OkHttp, Gson, Glide and Coroutines

What is Dependency Injection?

To explain dependency injection first we have to understand what dependency means in programming. A dependency is when one of the objects depends on the concrete implementation of another object. You can identify a dependency in your code whenever you instantiate an object within another. Let’s take a look at a practical example.

class MyAppClass() {

    private val library: MyLibrary = MyLibrary(true)
    ...
}

class MyLibrary(private val useSpecialFeature: Boolean) {

    ...
}

As you see from this example your class MyAppClass will depend directly on concrete configuration and implementation of your library class MyLibrary. What if you would like one day to use a third-party library instead? What if you would like to have another class where you would like to use exactly the same library configuration? Every time you will have to search through your code, find exact place and change it. It’s just a few examples.

The idea is that this tight coupling between the components of the application will make your development work harder as your project grows. To avoid any problems, let’s use dependency injection for loosening the coupling described.

class MyAppClass(private val library: MyLibrary) {

    ...
}

class MyLibrary(private val useSpecialFeature: Boolean) {

    ...
}

That’s it, that’s a very primitive dependency injection example. Instead of creating and configuring a new MyLibrary class object inside your class MyAppClass, you just pass or inject it into the constructor. So MyAppClass can be totally irresponsible for MyLibrary.

What is Dagger 2?

Dagger is a fully static, compile-time, open-source dependency injection framework for both Java and Android. In this article I will be talking about its second version which Google maintains. Square created its earlier version.

Dagger 2 is considered to be one of the most efficient dependency injection frameworks built to date. Actually if you compare Dagger 1, Dagger 2 and Dagger 2.10 you would discover each implementation is different. You need to relearn it each time as there were significant changes done by the authors. When writing this article I am using Dagger 2.16 version and we are going to focus only on it.

As you now understand about dependency injection, our classes should not create or have dependencies. Instead they need to get everything from outside. So when using Dagger 2, this framework will provide all the dependencies needed.

It does this by generating a lot of boilerplate code for us. That generated code will be fully traceable and will mimic the code which a user may write by hand. Dagger 2 is written in Java and the code generated by its annotation processor will be Java code too.

However it works with Kotlin without any problems or modifications. Remember that Kotlin is fully interoperable with Java. If compared to similar frameworks, Dagger 2 is a less dynamic one. It works at compile time rather than at run-time with reflection. There is no reflection usage at all. All that means is that this framework will be harder to set up and to learn. It will provide performance boost with compile-time safety.

Manual Dependency Injection without tools

You may have noticed in the My Crypto Coins app source code from the previous part that there is a piece of code for injecting objects without using any dependency injection tools. It works fine, and this solution would be good enough for such a small app like this. Take a look at the utilities package:

/**
 * Static methods used to inject classes needed for various Activities and Fragments.
 */
object InjectorUtils {

    private fun getCryptocurrencyRepository(context: Context): CryptocurrencyRepository {
        return CryptocurrencyRepository.getInstance(
                AppDatabase.getInstance(context).cryptocurrencyDao())
    }

    fun provideMainViewModelFactory(
            application: Application
    ): MainViewModelFactory {
        val repository = getCryptocurrencyRepository(application)
        return MainViewModelFactory(application, repository)
    }

    fun provideAddSearchViewModelFactory(
            context: Context
    ): AddSearchViewModelFactory {
        val repository = getCryptocurrencyRepository(context)
        return AddSearchViewModelFactory(repository)
    }
}

As you see this class will do all the work. It will create ViewModel factories for activities or fragments that require them.

/**
 * Factory for creating a [MainViewModel] with a constructor that takes a
 * [CryptocurrencyRepository].
 */
class MainViewModelFactory(private val application: Application, private val repository: CryptocurrencyRepository) : ViewModelProvider.NewInstanceFactory() {

    @Suppress("UNCHECKED_CAST")
    override fun <T : ViewModel?> create(modelClass: Class<T>): T {
        return MainViewModel(application, repository) as T
    }

}

Then you use InjectorUtils class like this where you need to get a specific ViewModel factory:

/**
 * A placeholder fragment containing a simple view.
 */
class MainListFragment : Fragment() {

    ...

    private lateinit var viewModel: MainViewModel

    ...

    override fun onActivityCreated(savedInstanceState: Bundle?) {

        super.onActivityCreated(savedInstanceState)

        setupList()
        ...
    }

    ...

    private fun subscribeUi(activity: FragmentActivity) {

        // This is the old way how we were injecting code before using Dagger.
        val factory = InjectorUtils.provideMainViewModelFactory(activity.application)

        // Obtain ViewModel from ViewModelProviders, using parent activity as LifecycleOwner.
        viewModel = ViewModelProviders.of(activity, factory).get(MainViewModel::class.java)

        ...
    }

}

As you see our MainListFragment class don’t even know about CryptocurrencyRepository or AppDatabase. It gets a successfully constructed factory from InjectorUtils class. Actually this is one simple way to do it. We are going to get rid of it and learn how to setup Dagger 2 tool for advanced dependency injection. If this app would expand in functionality and code, I don’t doubt we would start seeing benefits really fast of using a professional dependency injection framework over a manual solution.

So let’s delete InjectorUtils class right now and learn how to setup Dagger 2 in My Crypto Coins app source code.

Dependency Injection for MVVM with Kotlin

How to setup Dagger 2 with ViewModels, Activities and Fragments

Now we’ll go through the Dagger 2 step by step setup on the My Crypto Coins app project.

To begin, you should enable Kotlin’s own Annotation Processing Tool (kapt). Then add special Dagger 2 dependencies.

You can do this by adding these lines to your gradle file:

apply plugin: 'kotlin-kapt' // For annotation processing

...

implementation "com.google.dagger:dagger:$versions.dagger"
implementation "com.google.dagger:dagger-android:$versions.dagger"
implementation "com.google.dagger:dagger-android-support:$versions.dagger"
kapt "com.google.dagger:dagger-compiler:$versions.dagger"
kapt "com.google.dagger:dagger-android-processor:$versions.dagger"

Kapt plugin will enable the compiler to generate stub classes required for interoperability between Java and Kotlin. For convenience we will define the concrete Dagger 2 version in a separate gradle file, as we do that with all our dependencies.

def versions = [:]

versions.dagger = "2.16"

ext.versions = versions

To find the latest version available check the releases at Dagger 2's official repository on Github.

Now, create your application App class.

Skip this if you already have this class set. After you’ve done that, we will leave it as it is for a while, but come back later.

class App : Application() {

    override fun onCreate() {
        super.onCreate()
    }

}

For My Crypto Coins app, we already have created the application class earlier.

Next, update your manifest file to enable your App class.

Skip this if you have already done that before.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.baruckis.mycryptocoins">

    <application
        android:name=".App"
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        ...

For My Crypto Coins app, we’ve also already set the App class in the manifest earlier.

Now let’s create a new package called dependencyinjection.

Here we are going to keep all the files related to Dagger implementation.

Create AppModule class module which will provide dependencies all over your application.

/**
 * AppModule will provide app-wide dependencies for a part of the application.
 * It should initialize objects used across our application, such as Room database, Retrofit, Shared Preference, etc.
 */
@Module(includes = [ViewModelsModule::class])
class AppModule() {

    @Singleton // Annotation informs Dagger compiler that the instance should be created only once in the entire lifecycle of the application.
    @Provides // Annotation informs Dagger compiler that this method is the constructor for the Context return type.
    fun provideContext(app: App): Context = app // Using provide as a prefix is a common convention but not a requirement.

    @Singleton
    @Provides
    fun provideCryptocurrencyRepository(context: Context): CryptocurrencyRepository {
        return CryptocurrencyRepository.getInstance(AppDatabase.getInstance(context).cryptocurrencyDao())
    }
}

As you see, to create a Dagger module we need to annotate it with the special @Module annotation. Projects usually have multiple Dagger modules. It is typical for one of them to provide app-wide dependencies. This AppModule will be used to initialize objects used across our application, such as Room database, Retrofit, Shared Preference, etc.

As an example, we could discuss a very common scenario for AppModule to provide a Context object in case we need it to get access to it anywhere in our app. Let’s analyze the code to see how to do that.

We need to use a special Dagger annotation @Provides. It tells Dagger that the method provides a specific type of dependency, in our case, a Context object. So when somewhere in the app we request to inject a Context, AppModule is the place where Dagger finds it. And it does not matter the names of our methods, as Dagger cares only about the return type. It is only common practice to name the method with provide prefix, but it can be anything you want.

The @Singleton annotation which you see applied to the same method is not part of the Dagger annotations. It is contained inside the javax package. This annotation tells Dagger that there should only be a single instance of that dependency.

You don’t need to write the boilerplate code to check if another instance of the object is already available. When generating the code Dagger will handle all that logic for you because of this annotation. Notice that our AppModule includes another module ViewModelsModule. Let’s create it now.

Create a ViewModelsModule class module. This module will be responsible for providing ViewModels all over your application.

/**
 * Will be responsible for providing ViewModels.
 */
@Module
abstract class ViewModelsModule {

    // We'd like to take this implementation of the ViewModel class and make it available in an injectable map with MainViewModel::class as a key to that map.
    @Binds
    @IntoMap
    @ViewModelKey(MainViewModel::class) // We use a restriction on multibound map defined with @ViewModelKey annotation, and if don't need any, we should use @ClassKey annotation provided by Dagger.
    abstract fun bindMainViewModel(mainViewModel: MainViewModel): ViewModel

    @Binds
    @IntoMap
    @ViewModelKey(AddSearchViewModel::class)
    abstract fun bindAddSearchViewModel(addSearchViewModel: AddSearchViewModel): ViewModel

    @Binds
    abstract fun bindViewModelFactory(factory: ViewModelFactory): ViewModelProvider.Factory
}

This module uses Dagger 2 feature map multi bindings. Using it, we contribute objects of our choosing into a map that becomes injectable anywhere in our app. Using the combination of Dagger annotations @Binds, @IntoMap and our custom annotation @ViewModelKey(this one we are going to create), we create an entry inside our map with key MainViewModel::class and value MainViewModel instance. We bind specific factory with the help of some common ViewModelFactory class. We need to create this class.

Create a custom annotation class ViewModelKey.

/**
 * An annotation class which tells dagger that it can be used to determine keys in multi bound maps.
 */
@MustBeDocumented
@Target(
        AnnotationTarget.FUNCTION,
        AnnotationTarget.PROPERTY_GETTER,
        AnnotationTarget.PROPERTY_SETTER
)
@Retention(AnnotationRetention.RUNTIME)
@MapKey
annotation class ViewModelKey(val value: KClass<out ViewModel>) // We might use only those classes which inherit from ViewModel.

This class is used for binding ViewModels in the ViewModelsModule. The specific annotation @ViewModelKey represents the key of our map. Our key can be only a class that inherits from ViewModel.

Create the ViewModelFactory class.

/**
 * Factory to auto-generate a Class to Provider Map.
 * We use Provider<T> to create an injectable object at a later time.
 */
@Suppress("UNCHECKED_CAST")
@Singleton
class ViewModelFactory @Inject constructor(private val viewModelsMap: Map<Class<out ViewModel>,
        @JvmSuppressWildcards Provider<ViewModel>>) : ViewModelProvider.Factory {

    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        var creator: Provider<out ViewModel>? = viewModelsMap[modelClass]
        if (creator == null) {
            for (entry in viewModelsMap.entries) {
                if (modelClass.isAssignableFrom(entry.key)) {
                    creator = entry.value
                    break
                }
            }
        }
        if (creator == null) {
            throw IllegalArgumentException("Unknown model class $modelClass")
        }

        try {
            return creator.get() as T
        } catch (e: Exception) {
            throw RuntimeException(e)
        }
    }
}

This ViewModelFactory is a utility class which helps you dynamically create ViewModels. Here you provide the generated map as an argument. The create() method will be able to pick the right instance from the map.

Create the ActivityBuildersModule class module.

/**
 * All activities intended to use Dagger @Inject should be listed here.
 */
@Module
abstract class ActivityBuildersModule {

    @ContributesAndroidInjector(modules = [MainListFragmetBuildersModule::class]) // Where to apply the injection.
    abstract fun contributeMainActivity(): MainActivity

    @ContributesAndroidInjector
    abstract fun contributeAddSearchActivity(): AddSearchActivity
}

This module is responsible for constructing all your activities. It will generate AndroidInjector for all Activities defined in this class. Then objects can be injected into activities using AndroidInjection.inject(this) in the onCreate function from the activity lifecycle. Notice that this module also uses another separate module responsible for fragments. We will create this module next.

Create the MainListFragmetBuildersModule class module.

/**
 * All fragments related to MainActivity intended to use Dagger @Inject should be listed here.
 */
@Module
abstract class MainListFragmetBuildersModule {

    @ContributesAndroidInjector() // Attaches fragment to Dagger graph.
    abstract fun contributeMainListFragment(): MainListFragment
}

This module will build all your fragments related to MainActivity. It will generate AndroidInjector for all Fragments defined in this class. Objects can be injected into Fragments using AndroidSupportInjection.inject(this) in the onAttach function from the fragment lifecycle.

Create the AppComponent class component.

/**
 * Singleton component interface for the app. It ties all the modules together.
 * The component is used to connect objects to their dependencies.
 * Dagger will auto-generate DaggerAppComponent which is used for initialization at Application.
 */
@Singleton
@Component(
        modules = [
            // AndroidSupportInjectionModule is a class of Dagger and we don't need to create it.
            // If you want to use injection in fragment then you should use AndroidSupportInjectionModule.class else use AndroidInjectionModule.
            AndroidSupportInjectionModule::class,
            AppModule::class,
            ActivityBuildersModule::class
        ]
)
interface AppComponent {

    @Component.Builder // Used for instantiation of a component.
    interface Builder {

        @BindsInstance // Bind our application instance to our Dagger graph.
        fun application(application: App): Builder

        fun build(): AppComponent
    }

    // The application which is allowed to request the dependencies declared by the modules
    // (by means of the @Inject annotation) should be declared here with individual inject() methods.
    fun inject(app: App)
}

Component is a very important class. It will enable all the above to start working together. It does this by connecting objects to their dependencies. Dagger will use this interface to generate the code necessary to perform the dependency injection.

To create a component class you will need to use Dagger annotation @Component. It takes a list of modules as an input. Another annotation @Component.Builder allows us to bind some instance to component.

Then generate a graph object.

At this moment you have all your modules and your component setup. You can generate your graph object by selecting Build -> Make Module inside your Android Studio IDE. We will need this generation for future steps.

Now create an Injectable interface.

/**
 * It is just a plain empty marker interface, which tells to automatically inject activities or fragments if they implement it.
 */
interface Injectable

This will also be needed for future steps. Injectable interface should be implemented by activities or fragments which we want to be injectable automatically.

Create a new helper class named AppInjector.

/**
 * It is simple helper class to avoid calling inject method on each activity or fragment.
 */
object AppInjector {
    fun init(app: App) {
        // Here we initialize Dagger. DaggerAppComponent is auto-generated from AppComponent.
        DaggerAppComponent.builder().application(app).build().inject(app)

        app.registerActivityLifecycleCallbacks(object : Application.ActivityLifecycleCallbacks {
            override fun onActivityPaused(activity: Activity) {

            }

            override fun onActivityResumed(activity: Activity) {

            }

            override fun onActivityStarted(activity: Activity) {

            }

            override fun onActivityDestroyed(activity: Activity) {

            }

            override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle?) {

            }

            override fun onActivityStopped(activity: Activity) {

            }

            override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {
                handleActivity(activity)
            }
        })
    }

    private fun handleActivity(activity: Activity) {
        if (activity is HasSupportFragmentInjector || activity is Injectable) {
            // Calling inject() method will cause Dagger to locate the singletons in the dependency graph to try to find a matching return type.
            // If it finds one, it assigns the references to the respective fields.
            AndroidInjection.inject(activity)
        }

        if (activity is FragmentActivity) {
            activity.supportFragmentManager.registerFragmentLifecycleCallbacks(object : FragmentManager.FragmentLifecycleCallbacks() {
                override fun onFragmentCreated(fragmentManager: FragmentManager, fragment: Fragment, savedInstanceState: Bundle?) {
                    if (fragment is Injectable) {
                        AndroidSupportInjection.inject(fragment)
                    }
                }
            }, true)
        }
    }

}

It is just a simple helper class to avoid calling the inject method on each activity or fragment.

Next, setup the App class which we already created before.

class App : Application(), HasActivityInjector {

    @Inject // It implements Dagger machinery of finding appropriate injector factory for a type.
    lateinit var dispatchingAndroidInjector: DispatchingAndroidInjector<Activity>

    override fun onCreate() {
        super.onCreate()

        // Initialize in order to automatically inject activities and fragments if they implement Injectable interface.
        AppInjector.init(this)

        ...
    }


    // This is required by HasActivityInjector interface to setup Dagger for Activity.
    override fun activityInjector(): AndroidInjector<Activity> = dispatchingAndroidInjector
}

Because the application has activities, we need to implement the HasActivityInjector interface. If you see an error called out by Android Studio on DaggerAppComponent, it is because you have not generated a new file, as was pointed out in the previous step.

So, setup MainActivity to inject the main ViewModel factory and add a support for fragment injections.

// To support injecting fragments which belongs to this activity we need to implement HasSupportFragmentInjector.
// We would not need to implement it, if our activity did not contain any fragments or the fragments did not need to inject anything.
class MainActivity : AppCompatActivity(), HasSupportFragmentInjector {

    @Inject
    lateinit var dispatchingAndroidInjector: DispatchingAndroidInjector<Fragment>

    @Inject
    lateinit var viewModelFactory: ViewModelProvider.Factory
    private lateinit var mainViewModel: MainViewModel


    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Obtain ViewModel from ViewModelProviders, using this activity as LifecycleOwner.
        mainViewModel = ViewModelProviders.of(this, viewModelFactory).get(MainViewModel::class.java)

        ...
    }

    ...

    override fun supportFragmentInjector(): AndroidInjector<Fragment> = dispatchingAndroidInjector

    ...
}

Because our activities have child fragments we need to implement HasSupportFragmentInjector interface. We also need this because we plan to make injections into our fragments. Our activity should not know about how it is injected. We use the AndroidInjection.inject(this) code line inside overriding onCreate() method.

Calling inject() method will cause Dagger 2 to locate the singletons in the dependency graph to try to find a matching return type. However we don’t need to write any code here because it’s done for us by previously created AppInjector helper class which we initialized inside our application class.

Then, setup MainListFragment to inject the main ViewModel factory.

/**
 * A placeholder fragment containing a simple view.
 */
class MainListFragment : Fragment(), Injectable {

    ...

    @Inject
    lateinit var viewModelFactory: ViewModelProvider.Factory
    private lateinit var viewModel: MainViewModel

    ...

    override fun onActivityCreated(savedInstanceState: Bundle?) {
        super.onActivityCreated(savedInstanceState)

        ...
        subscribeUi(activity!!)
    }

    ...

    private fun subscribeUi(activity: FragmentActivity) {

        // Obtain ViewModel from ViewModelProviders, using parent activity as LifecycleOwner.
        viewModel = ViewModelProviders.of(activity, viewModelFactory).get(MainViewModel::class.java)

        ...

    }

}

Similar to activities, if we want our fragment to be injectable, then into its onAttach method we should write the code AndroidSupportInjection.inject(this). But again this is a job done by the AppInjector helper, so we can skip that. Just notice that we need to add the Injectable interface which we created earlier for the helper to work.

Congratulations, we’ve implemented Dagger 2 in the My Crypto Coins app project. Of course this article is a quick guide to deploy Dagger 2 in your app straight away, but not deep coverage of it. I recommend that you continue researching this topic if you feel lost on the basics.

Repository

Check out the source code of the updated “Kriptofolio” (previously “My Crypto Coins”) app on GitHub.

View Source On GitHub

Ačiū! Thanks for reading! I originally published this post for my personal blog www.baruckis.com on October 7, 2018.

As an analyst at Amazix, I spend a large portion of my time reading through hundreds of projects’ whitepapers and analyzing their token economic models to discern whether or not they’re adequately capturing the value created by the project.

This is extremely important because the value captured by a token is essentially its utility or intrinsic value which is also what ensures that the token’s price grows alongside adoption/success of the underlying project. A token lacking utility will see its price supported only by speculation and is very likely to fail in the long-run.

For more on this, see my earlier blog, in which I discussed the importance of token economic models in ensuring a token’s long-term value.

In part 1 of this series, I covered the problem of misaligned incentives caused by projects which have both equity and tokens, suggesting there’s an inverse relationship between the value of a project’s equity and the value of its token in that they are effectively competing to capture the value created by the project. I also suggested some potential solutions to this issue.

In this blog, I’ll discuss the second most common problem we see with token economic models: the velocity problem facing “Medium of Exchange” tokens. I’ll begin by giving a brief background of what token economics is before describing what the velocity problem is, why it matters and some of the solutions we recommend to our clients.

What is a token economic model and why does it matter?

If you’re a seasoned crypto investor or understand what a token economic model is, feel free to skip this part.

Before we start talking about token economic models, it may be wise to start at the very beginning with what is a token and what makes up its value.

A token is a crypto-economic unit of account that represents or interacts with an underlying value-generating asset. A token’s value is made up of its intrinsic value, the percentage of the token’s value that derives from demand for the underlying asset, and its speculative value, the percentage of the value of the tokens that derives from demand due to an expectation of future price increases. While speculation is nice, it is hard to control/predict and puts projects at the mercy of short-term-oriented investors, like our friend below:

Rather than focus on speculative value, we recommend investors focus on intrinsic value. A token’s intrinsic value is dependent on two factors: the value created by the underlying asset and the percentage of this value which is captured by the token.

The token economic model is what determines the latter — how much of the value created by the platform is captured by the token. As such, it’s one of the primary determinants of a project’s utility value and long-term success.

Medium of Exchange tokens and the velocity problem

A pure Medium of Exchange token is a token whose sole or at least primary use is as payment for some utility on the project’s platform or protocol. There are various incarnations of this, from marketplaces such as Signals Network where the token is the sole currency used to buy services on the platform, to SaaS type projects like BitStation where customers can only access the platform’s utility by paying the company a fee in the native token.

The general problem with MoE tokens is that they suffer from extremely high velocity. This has been well documented by many, including Vitalik, James Kilroe and Kyle Samani.

Basically, given the MoE token’s only use is payment for a service on the platform, there’s no incentive actually to hold tokens and incur price risk vs FIAT.

Buyers of the platform’s utility will simply acquire tokens for the purposes of a specific transaction (holding it for as little time as possible). On the other hand, sellers of the platform’s utility (whether this be users on a marketplace as in the case of Signals or the company behind the project in the case of Bitstation) will instantly sell the tokens they receive for FIAT rather than incur price risk vs FIAT.

This will result in high velocity for the token, as the increase in demand driven by buyers acquiring tokens will always be quickly matched by a corresponding increase in supply from sellers converting these tokens to FIAT.

Effectively, high velocity acts as an increase in circulating supply and is thus inversely proportional to the value of the token (although a certain base level velocity is necessary for the token to have any value, as pointed out by James Kilroe). We can see how this works using the Equation of Exchange, which has famously been adapted to crypto by both Chris Burniske and Vitalik.

To use Burniske’s definition:

MV=PQ

Where:
M= size of the asset base
V= velocity of the asset (the number of times that an average coin changes hands every day)
P= price of the digital resource being provisioned. This is not the price of the cryptocurrency but rather of the resource being provisioned by the network (i.e. price in $ per GB of storage in the case of Filecoin)
Q= quantity of the digital resource being provisioned (GBs of storage provided)

As Burniske tells us, in order to value the coin, we solve for M, where:

M = PQ/V.

M is the size of the monetary base necessary to support a cryptoeconomy of size PQ, at velocity V. In order to find the token price, we simply divide M by the total token supply. As we can see, the higher the velocity the lower the coin’s value.

Or, if we prefer to use Vitalik’s definition:

Vitalik takes MV=PT and in order to simplify the analysis of cryptocurrencies recasts it as MC=TH, where:

M= total money supply (or total number of coins)
C= price of the cryptocurrency (or 1/P, with P being price level)
T= transaction volume (the economic value of transactions per time)
H= 1/V (the average time that a user holds a coin before using it to make a transaction)

Therefore, the left part of the equation (MC) is simply the market cap (total supply*price) whereas the right side is the economic value transacted per time period (T) multiplied by the average time a user holds a coin (H).

To solve for the token price, one must therefore solve for C:

C=TH/M

Once again, we can see that the higher the velocity (or the lower the holding time H), the lower the token price.

Vitalik impress

In both Burniske and Vitalik’s definitions, it is apparent that the velocity of the coin is inversely proportional to the value of the token, That is, the longer people hold the token, the higher the price of each token. As James Kilroy tells us:

“This is intuitive, because if the transactional activity of an economy is $100 billion (for the year) and coins circulate 10 times each over the course of the year, then the collective value of the coins is $10 billion. If they circulate 100 times, then the collective coins are worth $1 billion. Thus, understanding and calculating the velocity in any token economy is extremely important.”

To see the drastic effects that velocity can have on a token’s value capture and market cap, see the following analysis of the effects of velocity on Ethereum’s market cap by John Pfeffer:

“In a protocol-land where protocol usage is managed by capital-efficiency optimising intelligent bots (which seems likely), let’s assume for simplicity the absolute floor on 1/V is the block time of the chain in question. Let’s then take ETH with a 2.5 minute block time as an example (highly theoretical, just to make a simple maths point). This implies each token could be used (assuming fixed block times, which in fact will likely shorten) 210,240 times a year. Buterin, Choi, etc. talk about, say, 10% of ETH being staked (let’s assume staked tokens never move at all). That would bring V down to 189,216 per year. Assume 50%, then V=105,120. Multiply this last number by $50b of network value (i.e., ETH just maintains its current value, and you’d need $5.25 quadrillion of economic activity denominated in ETH (i.e., excluding any ERC20/ ERC721-denominated economic activity), that is to say, 65x the current global GDP of $80 trillion. These numbers are all just varying shades of silly. That’s the point. As long as some of your tokens are circulating at a high V, your overall V is high.”

Solutions to the velocity problem

The most commonly used solutions to this problem all involve designing token economic models that provide incentives for people to hold the token — basically turning it into an asset (or “Store of Value”) rather than a currency. This can be done in several ways:

(1) Ensure token model has a “sink” in it

This one was initially suggested by Vitalik and has been widely adopted since. Basically, it involves designing token models with “buy-and-burn” mechanisms in which the project charges transaction fees and then uses some or all of the cash flows generated by its platform to purchase its own tokens and destroy them. The decrease in supply raises the value of all remaining tokens by the percentage of total supply destroyed. Effectively, the project is distributing its cash flows to its token-holders, very similar to how equity distributes cashflows to its stockholders through a dividend.

An example of this is Iconomi, a digital asset management platform which burns preset percentages of all fees collected and also produces quarterly reports outlining the number of tokens burned (crypto quarterly earnings reports).

Since, as we previously mentioned, velocity acts as an increase in circulating supply which reduces the value captured by the token, a buy-and-burn mechanism has the opposite effect of ensuring each additional transaction (i.e. increase in velocity) on the platform reduces the total supply of tokens, thus counteracting the increase in velocity with a deflationary force.

This should also reduce velocity by giving people a reason to hold the token, namely the expectation that it will be more valuable in the future due to the deflationary force created by the token burn.

The Joker reducing $ velocity

(2) Implement a “profit-share”

This one was initially suggested by Kyle Samani of Multicoin. It is very similar in spirit to the “buy-and-burn” in that it is providing the token with a yield and turning it into an asset that generates cash flows.

An example of this is Augur which pays REP holders for performing work for the network. REP tokens are like taxi medallions: you must pay for the right to work for the network. Specifically, REP holders must report event outcomes to resolve prediction markets. Other examples of “profit-share” tokens include FOAM , Sharpe Capital and also Ethereum once it has switched to Proof of Stake.

Once again, a profit-share reduces token velocity by forcing people to hold the token in order to have the right to generate cash flows by providing work to the network.

(3) Encourage users to lock up tokens

This can be done through mechanisms such as Proof-of-Stake which encourage users to lock up a certain amount of tokens, verify transactions and receive a yield in return (this also has the added benefit of acting as a profit-share). DASH, NEO and Navcoin are all examples of coins that have implemented proof of stake models.

Users can also be encouraged to lock up tokens through clever gamification — providing users with rewards (financial or otherwise) for locking up tokens. For instance, Alluma, a crypto exchange targeting Asian markets, offers different membership levels and fee discounts based on users staking different amounts of tokens:

• Gold memberships offer 35% discounts in exchange for staking 2500 LUMA for 30 days, and
• Platinum memberships offer 50% discounts in exchange for staking 10,000 LUMA for 90 days (source: page 28 of Alluma whitepaper).

For another example, we can look at YouNow, a live streaming app which allows users to tip content creators in its native token PROPS.

While content creators could immediately convert PROPS to FIAT, they are incentivized to hold onto it as their content is ranked higher by YouNow’s algorithm based on how many tokens they hold. Since discoverability leads directly to more tips, YouNow is effectively turning PROPS into an asset by ensuring users who hold it are able to generate cash flows.

Donald Duck’s masternode

Conclusion

Token economic model design is an extremely important and underrated area for both investors and founders of cryptocurrency projects to think about. A project with a weak token economic model may see its token price fail, even as the project itself succeeds, simply because the token is not capturing any of the value created by the project.

Velocity is one of the biggest problems with current token economic models and many established projects such as Civic, Storj and Po.et have recently revamped their token models to address this issue. If you believe your project may also suffer from high velocity and are interested in having your token economics audited or discussing this further, feel free to get in touch with me through here or on Twitter.