Stubber

Digitally traceable ticket sales on the blockchain.

Comment 3

Inspiration

The problem I decided to tackle with Stubber was to deter ticket scalping for concerts by providing a platform that manages the sales of storage for various events on the Ethereum blockchain.

I was inspired to tackle this idea whilst listening to a fantastic NPR Planet Money podcast on how Kid Rock was fighting back against scalping in a couple interesting ways

What it does

Stubber Dashboard

Stubber stores event data on the public ledger, currently supporting fields like:

  • Location
  • Date
  • Price

On top of these public facing details, information about how many tickets have been sold, and most importantly it is able to limit the changing of hands of a ticket for a higher price then what was paid upfront.

While it's clear that it doesn't completely block scalpers from charging for tickets at a higher price through an external transaction, it does at-least bring to light the difference in price between what a scalper paid for the ticket they are trying to sell a loyal fan; and hopefully this in itself is enough to deter most, if not all of the shady sales.

How I built it

This DApp was built using the standard practices around Truffle and Open Zeppelin. The project was spun up using

$ truffle init

Open Zeppelin libraries were also used to simplify some of the more standard but extremely critical pieces of the Contract; specifically:

  • ownership/Ownable.sol - Handled the contracts Ownership to the address that deploys the contract. This allowed me to lockdown the createEvent function and a couple other sensitive functions.

  • token/ERC721/ERC721Token.sol - The Tickets are ERC721 compliant tokens, and I made sure of this by using the Open Zeppelin standards for this.

Challenges I ran into

A good majority of my problems were around poor data sanitisation from the front end application; I wasn't handling conversions between data types like byte32 -> uint correctly and ended up with some pretty interesting results!

Invalid Data

Another issue I still need to address is around how I am going to host the display images for the events. Currently I host an image under the .png file name which is loaded in for a given event. This format is standard enough so that I can retrofit a better solution in on-top of the existing contract in the future with no changes to the core distributed contracts logic

Accomplishments that I'm proud of

It was really interesting to work with a contract that had two core Struct types within it. In the past most of my contract work has been built around 1 single struct that is more often then not simple a container for the data in the ERC721 tokens.

    struct Ticket {
        uint eventId;
        uint price;
    }

    struct Event {
        address artist;
        bytes32 name;
        bytes32 location;
        uint price;
        uint time;
        uint salesCap;
    }

This time around it was fun to have to work in the Event Struct.

I'm also really proud to have worked a bit more on the frontend stuff, It's certainly not my strong suit but I'm definitely getting a lot better.

What's next for Stubber

There are a couple things I'd like to do to make Stubber even more awesome:

  • Come up with a better solution for storing the image URL / image data for the event picture. I'd really like to explore IPFS a bit more and look into how I could possibly deploy an image to IPFS and then store the URL to that image in the contract.

  • Move the UI across to React / Angular; I've never really worked with these frameworks, however I noticed that Truffle has a UI frameworks now called Drizzle I'm keen to learn.

Built With

Share this project:

Updates