Team
Background
After Crypto-Susu we were ready to take on a real project. A friend had a hardward startup that made drink vending machines – mostly focused on dispensing coffee on demand and charging customers by the ounce. All of the machines are connected to the Internet allowing for a central backend to report sales and monitor the status of CO2 and when product needs to be refilled.
I came up with the idea of doing a kind of micro-ICO where we could crowd-fund the capital necessary to build and deploy an individual machine, say $5,000. At a $1,000 buy-in five investors would get digital tokens for their investment. Then as sales occurred on that machine, token holders would be paid back by the smart contract until they had earned back a certain premium on their investment. For the sake of argument, we’d say the cap would be 125% of the original investment. At that point the tokens would essentially be extinguished, and further profits would just flow back to the machine owner. The idea was to create a proof-of-concept for the development/deployment of one machine, then scale to 10 machines, then 100 machines.
I had been learning a lot about how startups were using ICOs to provide millions of dollars of capital in exchange for some sort of equity in their business or alternatively in exchange for tokens that could be used to consume goods within the ecosystem that the startup was developing. This idea was different however, in that investors were not getting tokens that represented equity in the business, nor could those tokens be used to purchase coffee (although that might be an option worth examining). Instead the tokens were basically operating a kind of debt instrument which raised some novel technical and legal issues to explore.
Development & Lessons Learned
Overview
Again, props to Shawn to really took on the bulk of the smart contract development work for CoffeeCoin. At this point he had reached a higher level of fluency with Solidity than the rest of us and was more comfortable with the related web development work (using React) than I was. Most blockchain development is focused on web-based deployments of the final application rather than the native mobile development that I have some fluency in. I instead focused on investigating the legal and regulatory implications of what we were experimenting with (more on that later).
Money-In
Using CryptoSusu as a starting point, the money-in side of CoffeeCoin operated much the same way. Much like the Susu, we just had to define a group of investors and have the smart contract accept contributions for those members. This time, in exchange for their contributions, the smart contract would mint tokens for the investor representing their investment.
Money-Out
The money-out situation however was much different than CryptoSusu. Instead of paying each investor a set amount during a certain time period, the initial design had the investor payback being based on a percentage of the gross revenue made by that machine during the time period. In the ideal world, the smart contract would get up-to-the-second info from the machine on its sales and payback investors constantly. We ran into a few issues with this approach.
First, there was an initial unspoken assumption that the target user for this would be the everyday person who might be interested in investing in small businesses. These investors would not be cryptocurrency enthusiasts so therefore their starting point would be having dollars to invest. There is no way to have Ethereum smart contracts make use of dollars. The dollars would have to be converted to ether for the smart contract at the time of investment. Then the smart contract could pay back amounts in ether that would have to be converted back to dollars. This is all fine, if the exchange rate between dollar and ether is relatively stable. But crypto currencies have been notoriously volatile. So there was a lot of debate about how to handle this. The current version of CoffeeCoin has not solved this problem yet.
Upgrading Contracts
CoffeeCoin still needs further development and the team is fully aware that there may be bugs in the code that might need to be patched in the future. This exposed a huge problem with blockchain application development. One of the core value propositions of the blockchain is that it records on it are immutable and not subject to nefarious rewrites by bad actors. There is no single, central database of account balances that one admin could go into and edit to give themselves 1,000,000 more units of currency.
This immutability is a two-edged sword though. In normal software development there is a a cycle of deploying code to the real world learning of a vulnerability (or adding additional functionality), writing a new version to address those issues, and then deploying the new version to replace the existing version. The ostensive immutability of blockchain smart contracts makes this process next to impossible. We had assumed that if we just structure the contract differently, make it more modular, and use tools like ZepplinOS, that there were set industry-standard solutions to this fundamental update problem. Then Nick uncovered this article that threw a whole lot of cold water on that idea. Basically, updating contracts is a messy issue.
