NuCypher & Proxy Re-encryption

In April I entered (and won!) the NuCypher+CoinList hackathon. I didn’t actually know much about the NuCypher tech before I got started but once I had built my DApp it was clear this is really interesting stuff and it’s stuck with me ever since as something interesting to build on.

Proxy Re-encryption

The NuCypher solution will eventually provide a decentralised privacy infrastructure but during the hackathon I was mainly making use of a subset of the tech, Proxy Re-encryption.

Proxy re-encryption is a set of encryption algorithms that allow you to transform encrypted data. Specifically… it allows you to re-encrypt data — so you have data that’s encrypted under one set of keys, you can re-encrypt the data without de-encrypting it first, so that now it’s encrypted under a second, different set of keys —NuCypher co-founder MacLane Wilkison

So What?

To understand why this is pretty awesome imagine I have some encrypted data I want to share with Bob, what are the options to do this?

Crazy way – I just give me private encryption key to Bob (who I’m sharing the data with) who can use it to decrypt the data. But now Bob has my key and who knows where this ends up.

Inefficient way – I decrypt the encrypted data then rencrypt it using Bobs public key. This is more secure for sure but I have to do a lot more work. What if I have to do this many times? What if the encrypted data is stored and accessed over a network? Hows the information all being shared? Intensive!

How about the Proxy Re-encryption way:

With Proxy Re-encryption I encrypt the data once.

The encrypted data can be stored anywhere — Amazon, Dropbox, IPFS, etc. I only need to upload it once and provide access to the Proxy service (eventually this will be a NuCypher decentralised service)

The Proxy can rencrypt the data for anyone else I choose (provided I have their public key) efficiently and without ever having access to the decrypted data.

Bob decrypts the data using his own key and resources.

If the data I’m sharing is a stream, i.e. a Twitter feed, then I can enable/revoke decryption access whenever I want — i.e. I can stop someone seeing the data.

NuCypher will eventually provide a decentralised privacy infrastructure which will replace a centralized proxy with a decentralized network. A really good overview of the NuCypher solution is here.

Combine all this with decentralised smart contract as a source of access — very cool!

My DApp — thisfeedisalwaysforsale

My DApp was innspired by Simon de la Rouvieres This Artwork Is Always On Sale where he implements a Harberger Tax on the ownership of a digital artwork. In my app, instead of an artwork, access to a feed of data is always for sale. NuCypher is used to encrypt the data and only the current Patron can decrypt (using NuCypher) to get access. Anyone can buy this access from the current Patron for the sale price set when they took ownership. Whilst they hold ownership they pay a 5% fee to the feed owner. In the demo app the data is a Twitter like feed but the concept could be extended to have more than one Patron and could also be used for other kinds of feed data such as sensor data, camera/video feeds, music, etc.

I was super happy to get a mention in Token Economy as Stefanos favourite entry!

Cool Crypto — Sending Value With A Link

Lately I’ve been helping out on the open source burner-wallet app created by Austin Thomas Griffith. The idea behind it was to try and create an app that could exchange value using a mobile web browser. It trades off the complexity and best practices of storing private keys, downloading apps, etc to just make something that should be easy to get started with and easy to use.

One of the functions I found the most interesting was the ability to send some value, in this case xDai, to someone using a link (try out the app here). The functionality behind this method is pretty cool and makes use of a lot of web3/crypto fundamentals. I found it interesting to dig into it and thought it would be worth sharing.

To Begin

First of all, the Dapp isn’t really ‘sending’ the xDai, it’s more of a deposit/claim pattern with some cool cryptography used to make sure only the person with the correct information, provided by the sender via the link, can claim the value.

Secondly there are two parts — the web Dapp and the smart contract on the blockchain. The web Dapp is really just a nice way of interacting with the smart contract.

Step By Step

A step by step description helped me get it into my head. Please note that I’m not showing all the details of the code here, it’s more a high level description to show the concept.

Sending

Using the Dapp the ‘sender’ enters the amount they want to send from and hits send.

Once send is hit the Dapp does a bit of work in the background to get the inputs required by the smart contract set-up.

The Dapp uses web3.js to hash some random data:

let randomHash = web3.utils.sha3("" + Math.random());

Now the Dapp uses web3.js to generate a random account which will have a private key and a public key:

let randomWallet = web3.eth.accounts.create();

The random hashed data is then signed using the random wallet private key (see below for more details on signing, etc):

let sig = web3.eth.accounts.sign(randomHash, randomWallet.privateKey);

The Dapp sends a transaction to the blockchain smart contract with the value equal to the amount that is being sent along with the signature and the hashed data:

Contract.send(randomHash, sig.signature), 140000, false, value ...
// This is just a pseudo code to give the gist, see the repo for the full code

The smart contract contains a mapping of Fund structures to bytes32 ID keys:

struct Fund {
    address sender;
    address signer;
    uint256 value;
    uint256 nonce;
    bool claimed;
}

mapping (bytes32 => Fund) public funds;

When the Dapp ‘sends’ the value the smart contract creates a new Fund structure with the signer field set to the public key of the random wallet created by the Dapp. This field is important as it is used as the check when a claim is made:

newFund = Fund({
    sender: msg.sender,
    signer: randomWallet.publicKey,
    value: msg.value,
    nonce: nonce,
    claimed: false
})

Now the newFund is mapped using the randomHash value as the key:

funds[randomHash] = newFund;

The xDai from the sender has now been sent to the smart contract and is ready to be claimed by anyone with the required information.

Finally the Dapp generates a link with the randomHash and random wallet private key as the link parameters:

Link Format: xDai.io/randomHash;privateKey

The link can then be copied and sent via WhatsApp, SMS, etc.

The Claim:

Here it’s probably worth noting the link is really just a nice way to share the important information required to claim the xDai. The Dapp also does the hard work of interacting with the blockchain smart contract.

When the link is visited the Dapp parses the randomHash and the privateKey from the link.

It then signs a message using the privateKey from the link:

let accountHash = web3.utils.sha3(claimAccount);
let sig = web3.eth.accounts.sign(accountHash, privateKey);

Now the smart contract claim function is called using the signature and the original data:

Contact.claim(accountHash, sig, randomHash, claimAccount)

The Solidity ecrecover function is used to get the public address from the signature (this is the magic, see the info below):

address signer = recoverSigner(accountHash, sig);

Finally, the smart contract checks the fund with key matching randomHash has the ‘signer’ equal to the address recovered from the signature. If it does then it can send the value to the claimers account:

if(funds[randomHash].signer == signer && funds[randomHash].claimed == false){    
    funds[randomHash].claimed = true;
    claimAccount.send(funds[randomHash].value);
}

Phew, that’s it! It feels like a lot going on but the basics is it’s a smart way for a user to store value in a smart contract that can only be claimed with the correct information without showing what that information is on the public blockchain.

The Cool Crytography

Signing, ecrecover, eh what?? There’s some things that are probably worth going into a bit more detail.

Wallets, Accounts, etc

An account generated with web3.eth.accounts.create() has it’s own a private key and public key. More info can be found in the docs and here. The private and public keys are linked through an algorithm that has signing and validation properties.

Signing & Validating

The following is a very brief summary of this helpful post.

Signing is the act of a user “signing” data that anyone can validate came from that user.

The signing function will take in a private key and the data. The output will be another string that is the signature.

To validate the signature is from the owner of the private key the signature, the original data and the public key is required.

A validator function is run that recovers the public key from the signed data.

The recovered public key is then compared to the original one and if both are the same the signature is valid.

ecrecover

In this case the Solidity ecrecover (Eliptic Curve Recover) function is used to recover the address associated with the public key. The recoverSigner function in the smart contract code shows an example of how this is done and this is a pretty decent explanation of what is going on.

I think that’s a pretty awesome example of crypto in action!

Ethereum — Scaling Is Not The Problem?

Warp Speed! Photo by chuttersnap on Unsplash

The reality is that State Channels are here now, and work great, today. We can ship commercial quality dapps that use them NOW — JezSan FunFair

The quote above was from a Reddit post highlighted in the November issue of Week In Ethereum. It confirmed something that I didn’t really appreciate until I went to Devcon IV — scaling isn’t the issue that is preventing main stream adoption of Ethereum. It’s the fact that the dApps out there don’t really offer any real improvement over the existing solutions for the main stream user.

As Jez says further down the post — State Channels are a useful and immediate form of scaling and they work today.

Both FunFair and SpankChain already have products that can scale and that in look and feel matches what’s already out there. But that’s the problem—to a normal user they are the same as what’s out there already, they’re not actually any better. In fact by the time you add in all the hassle of dealing with ‘crypto’ it’s actually worse.

It’s Just Not Good Enough

I actually experienced this first hand at the FunFair DevCon party. I took a non-crypto friend along and I explained the concept to him while we watched a demo on a big screen. He appreciated the look and quality of the demo but asked why should he chose this over any other?

Why should we use the dApp? — Photo by Ken Treloar on Unsplash

One of the FunFair developers actually tried to answer – ‘it’s provably fair’. My friend answered, quite fairly, with how can he, himself, verify that it’s fair? (I have to admit I’m fairly ok with code but I would find it hard and he has no experience) The FunFair guy admitted this is a problem.

Next suggestion was that he would always have control over his funds so there’s no issue with an operator delaying or withholding them. To my friend this just wasn’t a problem he had ever experienced so he didn’t really see it as a benefit.

I need what tokens to use it? Ok, lets just leave it there! Basically it came down to the fact that for my friend there was no real improvement and actually the whole thing was a bit of a pain in the ass to use.

It was a an eye opener for me as I’ve always been a big fan of FunFair and I really like the tech — but I guess I’m not a mainstream customer, in fact I’m not actually a customer at all! (I still reckon FunFair will crack it though 😄) When I think about in general the stuff I have used isn’t very user friendly and it’s normally just my enthusiasm for the tech that pushes me to use it.

BUIDL To The Rescue

So what to do? Well at Devcon there was a lot of focus on design and user experience so obviously smarter people realised this issue a good while before me! And smart people are experimenting and building. Universal Logins are super cool. Week In Ethereum also linked to some details about the work of Austin Griffith at Gitcoin labs. I think this is the kind of thing that’s going to drives things forward and there’s a lot of room to get involved.

Check out some of the stuff below, dive in and experiment.

Universal Logins: First Demo
You can already use an app without ether, todaymedium.com

Ethereum Meta Transactions
Lowering barriers to drive mass Ethereum adoptionmedium.com

Counterfactual Loan Repayment
exploring predictive smart contract deploymentsmedium.com

austintgriffith/burner-wallet
🔥👛Burner Wallet to move xDai quickly in a web browser. Sweep to cold storage when you get home. 🏠👨🏻‍🚒 …github.com

My Devcon IV

The Quick & Not So Nasty Summary

It’s going to happen. Ethereum is going to scale, PoS is going to come, UI/UX is going to improve and more people will use DApps. Amazing minds are working on all these things. The researchers are super inspiring. The community is strong, dedicated and buidling away. The ship is being steered in the right direction. The combination of all these things feels a bit special and it might just be the start of a new future.

I need to contribute.

My Personal Highlights

ENS & Universal Logins — Nick Johnson, Alex Van De Sande

These kind of things are really going to drive adoption. Both Nick Johnson and Alex Van De Sandé were quality speakers.

I should look at using ENS in a DApp to gain some experience and the technical details are interesting to look into more, might be something I could contribute to?

Universal Logins, meta transactions, etc are just cool and the demo is awesome. I wonder what work is being done on the next stage? i.e. what’s the Universal Login equivalent for setting up your own wallet properly, or installing MetaMask?

Material world — Vinay Gupta

This was interesting because Mattereum seems to have solved the problem of how Ethereum tech can legally control real world assets. It still looks bloody complex but worth following for sure.

Making Sense Of Layer 2 — Josh Stark, L4

Explained state channels, plasma and other layer 2 technologies in a really good way.

One feeling I got from the conference was that some of these technologies, i.e. state channels seem usable already but don’t seem to be widely adopted to solve so called scaling issues. Is it because they’re hard to implement or is there some other reason?

Philip Daian — Smart Contract Security

Ended up at this one by accident and it was really interesting. Philip is a researcher and presented lots of interesting data. He was refreshingly original, realistic and non-biased. I’d like to watch his talk again and will definitely follow more.

CryptoEconomics at Scale — Karl Floersch

This guy was great. Energetic, enthusiastic, funny and explained things well. Very inspiring and encouraged everyone to get involved because there’s loads to do.

Andy Milenius — MakerDao, A new hope for financial reform

Did not expect much from this but it was excellent, really inspiring. These guys have a grand vision and they seem to be very clear and focused .Don’t know if I’ve ever fully appreciated the real power of stable coins but this definitely made me more aware.

Turbo geth — Alexey Akhunov

This guy was awesome! Possibly the best I saw. I only caught the end of the talk as didn’t plan to go but glad I randomly ended up there. He was so knowledgeable a fantastic presenter and it was super inspiring.

Contributing To Ethereum & OpenSource — Danny Ryan

One of the reasons I wanted to go to Devcon was because I know I want to be involved in the Ethereum ecosystem, I’ve been dabbling in the tech but I haven’t really found the best way for me to move forward so this presentation was perfect. Danny presented loads of ways to get involved and he believes it’s there are great opportunities for everyone. Some things to consider:

Follow conversations on https://ethresear.ch/
Build interfaces for research projects
Build prototypes for researchers
Get involved in meta transaction work
or ENS
Hack away and build my own applications, gain experience, skills and see if I identify any specific pain points.

So, what to do, what to do 🤔

The Experience In General

I really, really enjoyed it! It was fun, inspiring, exciting and super interesting.

Prague is awesome. A beautiful city that offers a lot of fun. We even got the weather! The Congress Centre was kind of spectacular and the food was amazing.

You can have a lot of fun in Prague, partying on the 24th floor of the Corinthian was FUN and Halloween is celebrated in style!

Although there was so much good work going on at the conference there’s still this kind of out-there, wacky, punky vibe too. The keynote sing song was amusing and surprisingly The chill out zone was cool and useful to rest the head after a late one the night before!

The amount of swag was crazy, I can’t say no to a free t-shirt!

There’s so many smart, enthusiastic and decent people working on this. I kind of knew about the smart and enthusiastic side but I was pleasantly surprised at how decent the people I met were — friendly, approachable, cooperative and mostly non-egotistical. Really different from attitudes I’ve experienced elsewhere.

I need to dive in even more and start contributing.

Also-prepare for Devcon V!

Ethereum — Vyper Development Using Truffle

Why Vyper?

Vyper is a contract-oriented, pythonic programming language that targets the Ethereum Virtual Machine (EVM)

Vyper is a relatively new language that has been written with a focus on security, simplicity and audibility. It’s written in a Pythonic way which appeals to me and as a more secure alternative to Solidity I think it has a lot of potential. I plan on writing more about working with Vyper in the future.

Truffle — Too Much Of A Sweet Tooth?

I’ve recently finished working on a hackathon project and completed the 2018 ConsenSys Academy and during that time, for better or worse, I’ve become pretty accustomed to using the Truffle development environment for writing code, testing and deploying— it just makes life easier.

So, in an ideal world I’d like to use Truffle for working with Vyper. After a bit of investigation I found this ERC721 Vyper implementation by Maurelian who did the work to make it Truffle compatible. I thought it might be useful to document the build process for use in other projects.

How To — Vyper Development Using Truffle

Install Vyper

The first step is to make sure Vyper is installed locally. If this has been done before you can skip — you can check by running the $ vyper -h command. There are various ways to install, including using PIP, the docs are here. I’m using a Mac and did the following:

Set up virtual environment:

$ virtualenv -p python3.6 --no-site-packages ~/vyper-venv

Remeber to activate the environmet:

$ source ~/vyper-venv/bin/activate

Then in my working dir:

$ git clone https://github.com/ethereum/vyper.git
$ cd vyper
$ make
$ make test

Install Truper

Next I installed Truper, a tool written by Maurelian to compile Vyper contracts to Truffle compatible artifacts. It uses Vyper which is why we installed it previously. (See the next section for details of what it’s doing). To install run:

$ npm i -g truper

Compiling, Testing, Deploying

From your project dir (you can clone the ERC-721 project for a quick test).

Run ganache test network:

$ ganache-cli

Compile any Solidity contracts as usual using:

$ truffle compile

Compile Vyper contracts using the command:

$ truper
* this must be called from the project dir and you must have the virtual environment you built Vyper in running.

Truffle tests can be written and run the usual way, i.e.:

Use artifacts in test files:
const NFToken = artifacts.require('NFToken.vyper');

Run tests using:
$ truffle test

Truffle migrations also work the usual way. For example I used the following migration file to deploy to ganache:

2_deploy_contracts.js

const NFToken = artifacts.require('NFToken.vyper');
const TokenReceiverMockVyper = artifacts.require('NFTokenReceiverTestMock.vyper');

module.exports = function(deployer) {
  deployer.deploy(NFToken, [], []);
  deployer.deploy(TokenReceiverMockVyper);
};

$ truffle migrate

What’s Going On

Truper uses Vyper which is why we installed it in the first step. If we look at https://github.com/maurelian/truper/blob/master/index.js we can see Truper is creating Truffle artifact files for each Vyper contract and writing them to the ./build/contracts folder of the project.

Truffle Artifact Files

These *.json files contain descriptions of their respective smart contracts. The description includes:

Contract name
Contract ABI (Application Binary Interface — a list of all the functions in the smart contracts along with their parameters and return values). Created by Truper using: $ vyper -f json file.vy
Contract bytecode (compiled contract data). Created by Truper using: $ vyper -f bytecode file.vy
Contract deployed bytecode (the latest version of the bytecode which was deployed to the blockchain). Created by Truper using: $ vyper -f bytecode_runtime file.vy
The compiler version with which the contract was last compiled. (Doesn’t appear to get added until deployed.)
A list of networks onto which the contract has been deployed and the address of the contract on each of those networks. (Doesn’t appear to get added until deployed.)

Maurelian describes it as a hacky stop-gap but it works so thank you!

Progress

Well that’s been a fun and productive couple of months!

ConsenSys Academy 2018

I’m now officially a ConsenSys certified dApp Developer 👊! (Certificate apparently on its way)

The ConsenSys Developer course was definitely worthwhile. I covered a lot of Blockchain theory while following the course lectures and taking the quizzes. The real learning and fun came from the final project where I actually had to build something.

Colony Hackathon Winner

I also managed to bag myself a prize in the Colony Hackathon for my decentralised issue reporting app. I got the Creativity Honorable Mention which was pretty cool and I used my winnings to buy a Devcon IV ticket ✈️ 🤘!!

The Learnings

I came across a few things that I wanted to do while I was #BUIDLING but couldn’t easily find the info on so I’ve been keeping a kind of cheat sheet. Hopefully it might help someone else out there.

https://github.com/johngrantuk/dAppCheatSheet/blob/master/README.md

The Future Is Bright

The last few months I’ve confirmed to myself that the Blockchain/Ethereum world is something I want to be involved in. There’s so many different, exciting areas to investigate further, now I just have to chose one and dive further down the rabbit hole!

Blockchain – The Adjacent Infrastructure

The Adjacent Infrastructure Movement

Chris Robisons Ethreal summary post really reinforces the feeling I get about Blockchain. He mentions how Joseph Lubin described the tech as an Adjacent Infrastructure. This really rings true to me. He goes on to say that from the ground up a new parallel society is being built and people can opt into it. Some nice examples are given:

Crypto – adjacent financial industry infrastructure
Ujo – adjacent music industry infrastructure
Hoard – adjacent virtual entertainment infrastructure

It’s my first real experience of a “community”. This community is growing. There are people genuinely enthusiastic about the technology and they are willing to contribute and collaborate to drive things forward. As more and more adjacent infrastructure is built more people are going to opt in. At the same time the building blocks of the Adjacent Infrastructure are still being built. There’s loads of opportunity to get involved and help make this happen. Personally I’m looking forward to getting stuck in to the Consensys Academy in June/July and here are some of the other things that have enthused me lately!

Ideo, Designing for Blockchain: Three Ways to Get Started

Really good article centered around three Blockchain challenges that can be worked on now:

Design secure and user-friendly ways to store private keys.
Design better ways to help users make a decision about transaction costs, or find ways to abstract it away all together.
The challenge: Design ways to display blockchain addresses in a more readable or recognizable format.

The challenges are real. People who are well versed, immersed and interested in the technology sometimes forget how difficult it can be to actually just use it. Solving these challenges would go a long way to getting more adoption and real life use. The article also provides a bit of inspiration to get started and it’s definitely thought provoking.

WalletConnect/Balance

A project I’ve enjoyed reading about lately is WalletConnect from the team at Balance. Their blog posts are great and the code is interesting and well documented. Richard Burton appears to be really open to collaboration with a genuine desire to drive the technology forward.

The WalletConnect concept is an example of something built to solve the usability challenges described in the Ideo article. The solution feels natural to me and I can definitely imagine using it. Balance themselves are in the process of developing a mobile wallet and I think this is something to look forward to.

ETHPrize

I read the introduction post to ETHPrize and it sounds like a great idea. Bounties as a driving force for development seem to be taking off.

The list of key points is really interesting. It shows how early stage this technology and the tools around it is. There’s so much opportunity to get involved and really make a difference.

I found it really weird to be inspired to do something about documentation! Not something I naturally gravitate towards but its something I know can actually make a massive difference and from experience it’s an issue in places. Seems like a great way to get involved and do valuable work for projects.

DApp Learnings – Storing & Iterating a Collection

I’ve been working on a rock, paper, scissors Ethereum DApp using Solidity, Web3 and the Truffle framework. I hit a few difficulties trying to replicate functionality that would normally be trivial in a non blockchain world so I thought I’d share what I learned.

My first thoughts for the DApp was to display a list of existing games that people had created. Normally if I were doing something like this in Django I’d create a game model and save any new games in the database. To display a list of existing games on the front end I’d query the db and iterate over the returned collection. (I realise storage is expensive when using the Ethereum blockchain but I thought trying to replicate this functionality would make sense and would be a good place to start.)

Solidity

Structures

While investigating the various data types that could be used I found the Typing and Your Contracts Storage page from Ethereum useful. I settled on using a struct, a grouping of variables, stored under one reference.

struct Game {
   string name;
   uint move;
   bool isFinished;
   address ownerAddress;
   uint stake;
   uint index;
}

That handles one game but I want to store all games. I attempted to do this in a number of different ways but settled on mapping using the games index as the key. Every time a new game is added the index is incremented so I also use gameCount to keep count of the total games.

mapping (uint => Game) games;
uint gameCount;

struct Game {
        string name;
        uint move;
        bool isFinished;
        address ownerAddress;
        uint stake;
        uint index;
    }

To add a new game I used this function:

function StartGame(uint moveId, string gameName) payable {
      require(moveId >= 0 && moveId <= 2);
      games[gameCount].name = gameName;
      games[gameCount].move = moveId;
      games[gameCount].isFinished = false;
      games[gameCount].ownerAddress = msg.sender;
      games[gameCount].stake = msg.value;
      games[gameCount].index = gameCount;
      gameCount++;
}

I also added a function that returns the total number of games:

function GetGamesLength() public returns (uint){
   return gameCount;
}

Returning A Structure

Next I want to be able to get information about a game using it’s index. In Solidity a structure can only be returned by a function from an internal call so for the front end to get the data I had to find another way. I went with the suggestion here — return the fields of the struct as separate return variables.

function GetGame(uint Index) public returns (string, bool, address, uint, uint) {
    return (games[Index].name, games[Index].isFinished, games[Index].ownerAddress, games[Index].stake, games[Index].index);
}

Front End

On the front end I use Web3 to iterate over each game and display it. To begin I call the GetGamesLength() function. As we saw previously this gives the total number of games. Then I can iterate the index from 0->NoGames to get the data for each game using the GetGame(uint Index) function.

When my page first loads it calls:

getGames: function() {
    var rpsInstance;
    App.contracts.RpsFirst.deployed().then(function(instance) {
      rpsInstance = instance;
      return rpsInstance.GetGamesLength.call();
    }).then(function(gameCount) {
      App.getAllGames(web3.toDecimal(gameCount), rpsInstance);
    }).catch(function(err) {
      console.log(err.message);
    });
  },

Web3 – Promises, Promises & more Promises…

The getAllGames function calls GetGame(uint Index) for each game. To do this I created a sequence of promises using the method described here:

getAllGames: function(NoGames, Instance){
   
   var sequence = Promise.resolve()

   for (var i=0; i < NoGames; i++){(function(){  
         var capturedindex = i
         sequence = sequence.then(function(){
            return Instance.GetGame.call(capturedindex);
         }).then(function(Game){
            console.log(Game + ' fetched!'
            // Do something with game data. 
            console.log(Game[0]); // Name
            console.log(Game[1]); // isFinished
         }).catch(function(err){
            console.log('Error loading ' + err)
         })
      }())
   }
}

Conclusion

Looking back at this now it’s all pretty easy looking but it took me a while to get there! I’m still not even sure if it’s the best way to do it. Any advice would be awesome and if it helps someone even better.

Token Models – Storm

Storm

Storm are another interesting crypto company that are planning to do an ICO for their Storm Token in the near future so it’s worth investigating how their token model works.

Storm Background

Storm plan to release a number of DApps:

Storm Play: Storm already have a product called BitMaker (1.2M+ downloads across 187 countries) which they are rebranding as Storm Play and integrating to the Storm products.

Storm Market: A decentralised micro-task marketplace.

Storm Shop: Opportunities where users can learn about or sample retail
goods and services (no real info on this yet).

How It Works

The service is relatively simple, and I see this is as a positive. The basics of the service are described below:

“Makers” and “Players” meet each other to buy and sell tasks.

“Storm Makers,” post tasks using the Storm Play app. To post a task you are required to pay using STORM tokens.

“Storm Players,” use the Storm Play app to perform tasks. Players receive reward units called Bolts in return.

Bolts may not be transferred off of Storm Market but are redeemable for STORM Tokens.

Players can also earn Bolts as part of the gamified reward system (see below). Players can be rewarded for:

Creating tasks
Completing tasks
Managing other Storm Players that a person referred in to complete a task
successfully
Helping categorize a task or helping to rank a task

These Bolts can be used for boosts. Boosts give the Storm Player access to more micro-tasks for a certain period of time

Token Analysis

As I did the last time, working through the twenty questions proposed by William Mougayar in Tokenomics — A Business Guide to Token Usage, Utility and Value really helps to think about how the tokens are used:

I found it more difficult to answer some of these and I’m not 100% convinced with some of my answers. For now I think the tokens offer the following utility:

The Value Exchange

Players are rewarded Bolts for tasks such as categorising a task or helping to rank a task. These Bolts can be used for boosts. Boosts give the Storm Player access to more micro-tasks for a certain period of time which should lead to more tasks being completed. Think this is maybe clutching a little to meet Mougayars definition, there’s not a real transactional economy between buyers/sellers as there’s not much to spend Bolts on but I think this will develop.

The Toll

Makers are required to pay for posts in STORM tokens. Also Players have to pay Bolts to boost.

The Currency

Reduces traditional payment fees.

Conclusion:

Overall score is 9/20. I’m not surprised it’s a fairly low score as my gut feeling is that apart from reducing fees the token isn’t intrinsic to the business plan. Micro-tasks and tokens fit well but they don’t need each other. I do still like the though and maybe ‘only’ reducing fees is enough – especially with the current industry leaders charging up to 40% (see whitepaper).

Gamification:

Whilst not blockchain technology specific the gamification aspect is interesting and is a big strength for the Storm team so I thought I’d investigate it a bit further in this section.

The main goal of embedding a ‘gamification’ layer to the Storm Market platform is to make it effective in reaching objectives for boosting and delivering business results, like ROE (Return on Engagement). Storm Play can make monotonous work much more enjoyable through a gamified platform.

Unlike previously cited freelance platforms too, gamification is a very important aspect of Storm’s ecosystem. Makers post tasks on the market and Players execute those tasks in exchange of different kinds of rewards (including money) that make the whole thing a fun experience.

To gamify the progression of its users, Storm uses “Bolts” as units of a rewarding system. Users can earn Bolts by doing micro-tasks and by doing training tasks to improve their skills. As their experience increase, they are assigned more micro-tasks. But your experience level on the Storm market is not tied to your Bolts, they are an artifact of it. You can actually use them to get “boosts”: “Within Storm Market, Storm Players can use their balance of Bolts for boosts. Boosts give the Storm Player access to more micro-tasks for a certain period of time”

Links

Storm Website

Analysis of Storm ICO

Token Models – Grid+

Grid+

In my previous post I stated I would try to learn more about token models and the associated technology by investigating crypto companies. First up a company called Grid+.

Grid+ aims to be a utility provider that exposes its customers to wholesale electricity prices. I really like their blog posts, they put a lot of effort into explaining the thought process behind the company. One of the co-founders, Alex Miller, actually encourages criticism and I think his transparency is refreshing. They’re one of the few companies who actually go into details about how blockchain technology can be used in a real life business and reading their posts really helps to develop my understanding of this technology.

Grid+ Value

First up it’s useful to look at what value Grid+ can potentially bring to a customer.

Grid+ want to expose its customers to wholesale electricity prices. Traditional utilities use fixed prices which are not market driven but wholesale prices vary throughout the day. Grid+ will offer prices both for consumed and generated energy based on the wholesale price (with a relatively small markup for most customers). This means customers have the opportunity to buy electricity when it is cheap, store it in batteries and sell when the price goes up. To me that’s pretty cool by itself.

The plan is to operate using the existing grid infrastructure. In theory thats a smart way to save costs, especially to start-up. From the description of how the system will work (see below) I wonder if this might potentially restrict them.

They place a lot of emphasis on giving their users ‘agency‘ which means users control the sending of funds, etc. In this system there is minimal human administration and minimal credit risk. Ultimately this keeps the price low for customers by avoiding traditional costs associated with admin, etc.

An IoT ‘Agent’ device is used to automatically handle payments via the Ethereum network. The goal is to create a p2p market between Grid+ agents. A customer who has electricity to sell can offer it at a local rate lower than the nearest wholesale rate. They will get bought out by another customer with the two customer Agents handling payments via a Grid+ hub on the Raiden network.

Grid+ acts as the bridge between the old world of traditional energy suppliers and the new world of prosumers and p2p transactions.

They also have ambitions to make the Agent ‘smart’ to help the customer purchase the cheapest electricity possible. The Agent can be connected to other sensors such as thermostats, it will then predict energy usage and save money on energy purchasing.

Ultimately these are all potentially smart ways to provide cheaper electricity to the customer.

Tokens

Grid+ Tokens

Grid+ will operate with a two-token model, a BOLT token and a GRID token.

The BOLT token will be treated by Grid+ as a stable-coin, redeemable by Grid+ customers for $1 worth of energy from Grid+ and backed by USD deposits.

The GRID token will allow Grid+ customers to purchase electricity from Grid+ at wholesale price. 1 GRID token = 500 kWh at the wholesale price.

Token Evaluation

Working through the twenty questions proposed by William Mougayar in Tokenomics — A Business Guide to Token Usage, Utility and Value really helps to think about how the tokens are used:

Question	BOLT	GRID
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?	Yes Provides access to Grid+ energy.	Yes 1 GRID token = 500 kWh at the wholesale price.
Does the token grant a governance action, like voting on a consensus related or other decision-making factor?	No	No
Does the token enable the user to contribute to a value-adding action for the network or market that is being built?	Yes Selling generated electricity on a p2p network.	No
Does the token grant an ownership of sorts, whether it is real or a proxy to a value?	Yes Ownership of energy.	Yes Ownership of wholesale energy.
Does the token result in a monetizable reward based on an action by the user (active work)?	Yes Any revenue earned by a customer from selling electricity is earned in BOLT tokens instead of fiat and is stored on the Agent.	No
Does the token grant the user a value based on sharing or disclosing some data about them (passive work)?	No	No
Is buying something part of the business model?	Yes	Yes
Is selling something part of the business model?	Yes	No
Can users create a new product or service?	No	No
Is the token required to run a smart contract or to fund an oracle?	No	No
Is the token required as a security deposit to secure some aspect of the blockchain’s operation?	No	No
Is the token (or a derivative of it, like a stable coin or gas unit) used to pay for some usage?	Yes Pay for used electricity.	No
Is the token required to join a network or other related entity?	Yes Can't join Grid+ network without token.	No
Does the token enable a real connection between users?	Yes? Allows p2p payments between users.	No
Is the token given away or offered at a discount, as an incentive to encourage product trial or usage?	No	Yes I think it incentivises people to start using Grid+.
Is the token your principal payment unit, essentially functioning as an internal currency?	Yes	No
Is the token (or derivative of it) the principal accounting unit for all internal transactions?	I think this is a yes although it may be kW instead.	No
Does your blockchain autonomously distribute profits to token holders?	Yes Agents are automatically updated.	No
Does your blockchain autonomously distribute other benefits to token holders?	Yes Possibly Casper, etc?	No
Is there a related benefit to your users, resulting from built-in currency inflation?	No	No
Total	13/20	4/20

Which leads to the conclusion that the tokens offer the following utility:

The Value Exchange

The BOLT token is a unit of value that allows the buying and selling of energy between Grid+ and users and also user to user.

Users can also earn BOLTS by generating and selling electricity or by arbitrage.

The Toll

It’s obvious that the BOLT token is used to pay for electricity used but I feel like I’m not 100% on this one. Maybe it’s because a token isn’t essential for this function. In the User Agency post Alex does admits this part could be done using a traditional infrastructure.

The Function

As far as I can see the GRID token is mainly for. It is offering a discount that encourages users to use Grid+ services.

The Currency

Traditional payment processing fees and admin costs are reduced.

p2p payments are made economically and technologically viable.

Conclusions

I’m not sure if 13/20 is considered a high score but my feelings are the BOLT token utility more than proves itself essential to the business model.

Initially I was sceptical about the use of the GRID token but after working through the questions I can see it’s potentially a really nice way to incentivise people to start using the service.

There are also some other interesting opportunities described in the post Casper, Plasma, and the Grid+ Agent that demonstrates the Grid+ team are super innovative when it comes to using blockchain technology and are still exploring new ideas – it must be a cool place to work! I think the last paragraph from Alex Millers The P2P Grid We All Want post demonstrates this:

However, this brainstorming session is likely an exercise in futility because the future is always uncertain and we’re talking about a future that is likely a decade or more away. Nevertheless, we at Grid+ are primarily motivated by bringing forth the future of energy. If Grid+ is so successful that our customers eventually dis-intermediate us and we really have no way to make money, then perhaps we’ve accomplished what we set out to do. We as a team would be happy with an outcome that empowers the people and establishes a new, transactive grid because that would mean we will have proven the power of decentralizing technologies — as far as we’re concerned, that’s a win for humanity.

How Grid+ Will Work

The following isn’t actually that relative from the token model perspective but it’s really interesting to see the nuts and bolts of how a crypto company could function. Really cool of the Grid+ to share this.

A customer purchases an agent (a small device capable of making signatures) and claims that device based on a serial number printed on the box.

Before shipping the agent Grid+ whitelist its serial number on their registry contract.

Grid+ map that serial number to an Ethereum address, which is a function of its public key .

Agent Address – Created when device first boots up.

Owner Address – customer who enters the serial number printed on the device into the Grid+ web console.

Customers will make a refundable initial deposit then will prepay each month.

Fiat payments will be converted to USDX tokens.

Every few hours Grid+ request payment from a customers agent commensurate with the amount of energy used.

If the customer exceeds her monthly allowance (or her agent simply doesn’t pay), the customer will be notified deductions are made from her initial account deposit.

your utility company tracks how much power goes into your house and how much power goes out of your house and then sends you a bill based on the net result.

Smart meters send data to ISO. ISO makes data available via API.

Grid+ will query the ISO (ERCOT in Texas) and bill customers’ Agents based on that usage.