Analysing Token Models

ICO’s

An ICO or Initial Coin Offering allows a company to sell its own cryptocurrency token to investors. As William Mougayar (a true Blockchain expert) states:

A [cryptocurrency] token is just another term for a type of privately issued currency.

It’s probably fair to say that at this time raising funds via an ICO is relatively easy when compared to traditional methods. There have been many successful ICOs with large amounts of cash being generated. It’s also probably fair to say that a large amount of the companies running these have no real requirement for a token and are simply accessing the ‘easy’ cash.

Some experts predict the majority of ICOs will fail but the organisations with genuine token models (and good execution) will survive and these are the ones that are innovative, valuable and interesting.

Analysing The Token Model

My plan is to analyse companies that use tokens to basically answer the question:

What does the token do that makes it essential to the business model?

This should help me to better understand the technology and identify how tokens can be used.

As a basis of the investigation I will use William Mougayars Role — Features — Purpose framework for assessing token utility as described in his post, Tokenomics — A Business Guide to Token Usage.

The chart shown below is taken from the Tokenomics post and shows the main roles a token can play.  The post itself provides great detail that I won’t repeat but is definitely worth a read. Using this and the list of questions at the end should result in a reliable conclusion on the utility of the token.

Token Utility – William Mougayar

Token Utility Questions (credit William Mougayar)

  1. Is the token tied to a product usage, i.e. does it give the user exclusive access to it, or provide interaction rights to the product?
  2. Does the token grant a governance action, like voting on a consensus related or other decision-making factor?
  3. Does the token enable the user to contribute to a value-adding action for the network or market that is being built?
  4. Does the token grant an ownership of sorts, whether it is real or a proxy to a value?
  5. Does the token result in a monetizable reward based on an action by the user (active work)?
  6. Does the token grant the user a value based on sharing or disclosing some data about them (passive work)?
  7. Is buying something part of the business model?
  8. Is selling something part of the business model?
  9. Can users create a new product or service?
  10. Is the token required to run a smart contract or to fund an oracle? (an oracle is a source of information or data that other a smart contract can use)
  11. Is the token required as a security deposit to secure some aspect of the blockchain’s operation?
  12. Is the token (or a derivative of it, like a stable coin or gas unit) used to pay for some usage?
  13. Is the token required to join a network or other related entity?
  14. Does the token enable a real connection between users?
  15. Is the token given away or offered at a discount, as an incentive to encourage product trial or usage?
  16. Is the token your principal payment unit, essentially functioning as an internal currency?
  17. Is the token (or derivative of it) the principal accounting unit for all internal transactions?
  18. Does your blockchain autonomously distribute profits to token holders?
  19. Does your blockchain autonomously distribute other benefits to token holders?
  20. Is there a related benefit to your users, resulting from built-in currency inflation?

Scotcoin

Earlier this week I attended the Scotcoin & the blockchain meetup at Napier University. It was a Q&A session, there must have been around 25 people there and it was an informative and interesting evening.

The two Scotcoin representatives were approachable and enthusiastic and seemed genuinely pleased to host the meetup and field the questions. The attendees were a mixed bag of crypto geeks, anti-establishmenters and nationalists. Some with pretty passionate opinions they weren’t scared to show.  It led to a pretty entertaining interaction. In a way I think the mix of people reflected the mixed Scotcoin vision.

Scotcoin was initially conceived during the build up to the 2014 Scottish Independence Referendum. At this time it was unclear what the currency situation would be if Scotland went independent and Scotcoin was a potential solution. As an ambitious, alternative solution to the currency issue I think it was quite smart (although I doubt the Scottish Government would have had the vision or courage to implement it).

However, Scotland didn’t become independent…The original Scotcoin founder left the project and a new investor/team took over. At that point I think it became less an idealistic vision and more like a way for some people to make money. -which is fair enough.

Nevertheless, according to the Business Model Canvas, a successful product must:

“Provide value to the customer by resulting in the solution of a problem the customer is facing or providing value to the customer.”

Without the need for an alternative to the GBP Scotcoin no longer seems to meet these requirements.

The official project line was that “Scotcoin will grow the Scottish economy by offering small business owners benefits.” When questioned on what those benefits are the only one suggested was lower transaction fees – a benefit that more established cryptocurrencies like Bitcoin (which Scotcoin is basically modelled on) already provide.

There was mention of the development of other features, but these couldn’t be discussed and I struggle to see the team having enough talent or vision to truly innovate. Whilst I hope the project doesn’t fail, for now, like a lot of crypto projects out there I think it’s mainly fueled on pure speculation.

DApp – My First Solidity Contract

As explained in my previous post my first smart contract is based on the “Withdrawal from Contracts” example from the Solidity Common Patterns documentation. In this post I review some of the Solidity code I learned.

Smart Contract Intro

The example in the documentation was inspired by the King of the Ether game and the rules of the contract are:

  • To play a user submits a value of X Ether paid from his address
  • If X > historicHighest:
  • user is king
  • old king can collect previous payments
  • historicHighest = X

The contract itself is:

pragma solidity ^0.4.2;

contract WithdrawalContract {
    address public richest;
    uint public mostSent;
    mapping (address => uint) pendingWithdrawals;

    function WithdrawalContract() payable {
        richest = msg.sender;
        mostSent = msg.value;
    }

    event BecameRichestEvent(address sender, uint amount);
    event FailedRichestEvent(address sender, uint amount);
    event Collected(uint amount);

    function BecomeRichest() payable returns (bool) {

        if (msg.value > mostSent) {
            pendingWithdrawals[richest] += msg.value;
            richest = msg.sender;
            mostSent = msg.value;
            BecameRichestEvent(msg.sender, msg.value);
            return true;
        } else {
            FailedRichestEvent(msg.sender, msg.value);
            return false;
        }
 }

function withdraw() {
    uint amount = pendingWithdrawals[msg.sender];
    // Remember to zero the pending refund before
    // sending to prevent re-entrancy attacks
    pendingWithdrawals[msg.sender] = 0;
    msg.sender.transfer(amount);
    Collected(amount);
 }
}

Solidity Specifics

I found this Introduction to Smart Contracts documentation a good source of information.

Addresses – address public richest;

Type address — holds a 20byte Ethereum address. Here it’s used to save the address of the user who is currently the richest.

public allows other contracts to access the variable.

An address has various member functions as detailed here. One of these is address.transfer(uint256 amount) which sends the given amount of Wei to the address. In this case transfer is used in the Withdraw function to safely send Ether to a valid users address.

Mappings - mapping (address => uint) pendingWithdrawals;

The next line, mapping (address => uint) public balances; also creates a public state variable, but it is a more complex datatype.

Mappings can be seen as hash tables. pendinWithdrawals maps addresses to unsigned integers. For example:

pendingWithdrawals[0xc7975434577b0d57248e1de03fcc6f27cd6cc742] = 7;

Maps the value 7 to address 0xc7975434577b0d57248e1de03fcc6f27cd6cc742 and can be called using:

x = pendingWithdrawals[0xc7975434577b0d57248e1de03fcc6f27cd6cc742]; 

x = 7

Transactions & Constructors – function WithdrawalContract() payable

This is a constructor – a function that is run when the contract is first created.

The payable modifier means the function is a transaction. A transaction is the transfer of data between two accounts (good explanation here). A transaction contains some standard data e.g. sender address or the amount of wei being transferred. We can access the transaction data using the global msg variable.

In this case msg is used to set the initial richest address to msg.sender which is the address of the person deploying the contract. It also saves the mostSent as the msg.value which is the number of wei sent during the deployment.

Events – event BecameRichestEvent(address sender, uint amount);

The front end of the application, in my case Web3.js, listens for Solidity events being fired so it can update the interface. For example the BecameRichest event fires when a new account becomes the richest.

The event is fired by the line:

BecameRichestEvent(msg.sender, msg.value);

The listener will have access to the sender and value data passed to the call.

In the next post I plan to detail some of the front end functionality, including how to listen for events.

Ethereum Work – Beginners Sending & Receiving Eth

Intro

I’ve been following the Status project for some time and recently they announced their virtual hackathon. I’d been planning on diving into the Ethereum/Decentralised App development world and thought this would be an ideal time to start and I pretty quickly saw how powerful and relatively simple this can be.

As a complete beginner to working with the blockchain I found it better to begin by forgetting about the Status part and even the Dapp part and just see how to interact with a blockchain. Basically you can send some Eth between accounts using one function – that’s impressive.

Setup

I figured you need to get set-up with three things to get going:

1. A blockchain

Normally this would be the Ethereum blockchain but whenever you run a smart contract on Ethereum you must pay for the computation using gas. Testnets simulate the Ethereum network on you local machine and allow you to experiment for free. I installed testrpc.

2. web3.js

web3.js is a Javascript library which runs in a browser, connects to a local blockchain node and allows you to make calls on the blockchain. It does this using remote procedure calls (RPC) which basically means passing messages in JSON format.

3. Truffle

Truffle is a development environment for Ethereum that makes development a lot easier. For this exercise I’m just using the Truffle console to interact with web3.js manually. It’s way more powerful than that, which I hope show during some more posts in the future.

The Action

Start the testnet

To begin the testrpc testnet needs to be started by entering the following command:

testrpc -p 8546
This just means a simulated Eth client is listening on my laptops IP address on port 8546.
When it starts gives a list of test wallets that are loaded with 100Eth (unfortunately not real Eth, just Eth for the simulated environment). These are handy for experimenting with. My output showed:
Available Accounts
 ==================
 (0) 0xc7975434577b0d57248e1de03fcc6f27cd6cc742
 (1) 0x74dcfef837aff77d7c43d44d1d69b1eef5d708a6
 (2) 0xac63a31fd24d692997e577c02524f81eb223cd1d
 (3) 0x86fd495d744d13d43d00aa700dc9517a92eb9eae
 (4) .......

Run web3 commands

Truffle has a console tool that can be used to run web3 commands. To start it just type (keep testrpc running in separate window):

truffle console

Then try:

web3.eth.accounts

you should see a list of the same accounts you saw when you started testrpc.

Send send send

So now the really cool part. To transfer Eth between accounts all you need to enter is:

var sender = web3.eth.accounts[0];
Which shows the first address in your list, in my case: ‘0x72ddd46949fddd6add06d99a3f64357a18506470′
var receiver = web3.eth.accounts[1]
Which shows the second address in your list, in my case:
‘0x05fc7ea9e73061234d45381e8cc2e1995d4d02da’
To show the current balances in both accounts:
web3.eth.getBalance(sender)

web3.eth.getBalance(receiver)

These should both return,

{ [String: '100000000000000000000'] s: 1, e: 20, c: [ 1000000 ] }
which shows 100Eth in both accounts.
We’ll transfer 0.01Eth:
var amount = web3.toWei(0.01, 'ether')
 And the actual transfer (this could have been run by itself right from the start but the above steps make the process a bit clearer):
web3.eth.sendTransaction({from:sender, to:receiver, value: amount})
 This returns a transaction address like: ‘0x9e9963f4782b4248b2cd42d8af17e85d64d049e052da335e3517f4a8a69aa064’
To confirm the transfer we can check the balances again:
web3.eth.getBalance(sender) this time shows:
{ [String: ‘99989999999999979000’] s: 1, e: 19, c: [ 999899, 99999999979000 ] }
web3.eth.getBalance(receiver) this time shows:

{ [String: ‘100010000000000000000’] s: 1, e: 20, c: [ 1000100 ] }

So 0.01Eth has been transferred!
If you look in your testrpc window you should see the transaction information on the blockchain, something like:
0x9e9963f4782b4248b2cd42d8af17e85d64d049e052da335e3517f4a8a69aa064
 Gas usage: 0x5208
 Block Number: 0x01
 Block Time: Tue Jun 06 2017 19:34:54 GMT+0100 (BST)

So with as little as one command you can transfer value electronically, cryptographically proven and with minimal fee. From a pure tech geek point of view that’s awesome, no wonder people get excited about this stuff!