I Won the Blockchain Hackathon at Berkeley

If you know me IRL, you know how much I enjoy competing at Hackathons. For me, it’s almost like compressing the early (and most exciting) part of a startup into 24 hours. Given the work I have been doing on WhenHub and Walkstarter and life happenings, I haven’t had a chance to participate in one in some time. When the IDEAS Global Blockchain Hackathon at Berkeley came to my attention, I jumped at the opportunity.

I spent last weekend with other coders creating a blockchain-based app as my Hackathon entry. My entry was Badge Spark: Micro-credentials for the Blockchain. Guess what…I WON FIRST PLACE!!! The prize was an Amazon Echo speaker so expect to see future an Amazon Skill or two in the future.

My app “Badge Spark” decentralizes OpenBadges (originally from Mozilla, now managed by IMS) by using IPFS (Interplanetary File System) and an Ethreum blockchain Smart Contract. In my research for the project, I found BlockCerts which has a similar vision, but a different approach. I think the BlockCerts solution is to “enterprisey” and what I had in mind was something much simpler, easier to work with, easier to implement, completely decentralized and fun!

The basic workflow is as follows:

1) An entity (individual or organization) creates a bunch of badge templates. This is the “Issuer.” The Issuer may associate a price in ETH for the badge (much like the DMV charges for issuing you a license that you have earned by passing a test).

2) A person does something online or offline to earn a badge and makes a claim for that badge. This is the “Claimee.” They must pay any required ETH for the transaction.

3) The Issuer validates the claim, and generates an OpenBadge Credential which consists of the following steps:

a) The JSON-LD data for the badge following the specification is stored on IPFS. (This needs some IPNS work to handle the self-referencing, but it’s a solvable problem).

b) The badge PNG or SVG file with claim data embedded is stored on IPFS.

b) The IPFS hash along with some key properties is stored in an Ethereum Smart Contract. Funds (if any) are transferred to the Issuer’s wallet.

4) In the future, any person or entity seeking to validate the Claimee’s Credential can do one of the following:

a) If they trust the Claimee => Upload the Credential badge provided by the Claimee to any validation service like this one.

b) If they don’t trust the Claimee => Use the Smart Contract to search for the Claimee’s unique identifier (could be email address or something else) and obtain the IPFS hash, get the issued Credential badge from IPFS and then validate it using a validation service.

The important point here is that once the Issuer has issued the Credential badge, it doesn’t matter if they continue to exist IRL or have an online presence. Anyone can validate the Credential using the decentralized web.

The code for this is quite a mess, but I’ll clean it up soon and post on GitHub. Meanwhile, here’s a video of step 1.