AppCoins: embedded cryptocurrencies

Naval Ravikant writes:

In economics, the artificially scarce token used to allocate scarce resources is called “money.” So Bitcoin is crowdfunded OSS to run an Economic network. Now, a new generation of Appcoins can be created as open source software, crowdfunded into existence, and go public on day one. They can run networks where Bitcoin may not work, or where separate funding and compensation is needed.

The idea is to embed an application-specific cryptocurrency into a useful network technology to regulate its usage and remunerate its creators:

The Tor network is slow because it relies on volunteers to relay traffic. Anytime we see a line, the product in question is underpriced. Let’s crowdfund a Torcoin – users of relays will pay in Torcoins and operators of relays will get paid in TorCoins. Founding developers collect equity when TorCoins are first mined and sold. Non-founding developers and network operators are paid revenues from newly mined coins and transaction fees.

A P2P technology like Tor is an obvious candidate for AppCoin integration. It does suffer free-rider economics, and network performance would improve if users were incentivised to relay traffic and run exit nodes.

Bittorrent is another technology ripe for AppCoin integration. There is a project underway by the developers of one client to integrate Bitcoin, but I suspect that an application-specific coin would be more appropriate.

I’ve long thought that a grid computing platform like BOINC would be more widely used if it swapped its credit system for an AppCoin.

One of the advantages of an AppCoin is that tight integration with the target technology’s protocol allows for seamless transaction settlement. It’s important to remember that Bitcoin and its variations handle only the payer side of a transaction. Payee performance must be monitored via trust, third-party escrow, 2-of-3 signature transactions, or some other mechanism. For informational goods such as Tor, Bittorrent, grid work units, etc, the overhead of integrating a generic cryptocurrency seems sub-optimal; much better to have a generic mechanism for exchange between different AppCoins, with something like Bitcoin as the reserve/intermediary currency.

Another advantage of the AppCoin is that it will likely get the monetary economics right. In a one-good economy, where the AppCoin buys a digital resource like traffic on a p2p network, it will be obvious to the creators that an AppCoin whose coin supply expands at a rate proportional to the usage of the resources is much better than a supply rule (like Bitcoin’s) that aims for long-term appreciation of coin’s value.

AppCoin’s will also provide an array of avenues for the widespread distribution of crypto coins. Unless you have something to sell those who hold cryptocurrency balances, the only way to acquire cryptocurrency is to mine (economically unfeasible unless you invest in ASIC hardware) or buy them on exchange (counterparty risk, KYC/AML hassles). AppCoins will provide a way for anyone to barter scarce but ubiquitous resources like bandwidth and disk storage for coin.

One interesting, if difficult, dimension to the AppCoin idea is the prospect moving proof-of-work beyond the current model of cryptographic hash functions. GridCoin tries to integrate hash-based with grid-computation-based proof-of-work. Making these ideas work in a robust way is hard, but I suspect that progress will be made beyond these early experiments, and it will come from the AppCoin space.

There are non-obvious implications of the AppCoin crowdfunding model, both economic and legal. The current VC/Angel funding model of startups is based on the familiar NPV of expected future earnings. Crowdfunding via an AppCoin will be based on the seigniorage of a literally monetised network. In a future post we’ll discuss how to approach the valuation of such things. We will also discuss some of the favourable legal aspects of crowd funding in a manner that clearly falls outside the scope of securities law.


I’m a big fan of this concept, so this bit of anecdotal evidence is discouraging. A BBC reporter spent a week trying to earn a living from crowdwork. In total: 37 hours worked, 19.16 GBP earned. I’m sure others can do better (and this was only an experiment), but still.. does anyone know of some proper stats on the hourly pay distribution of crowdsourced work?

I can’t help but think that these skills would be renumerated better if they were hired as employees or contractors. If that’s correct, I have some guesses as to why:

  • Buyers of the skills get less value from the workers because of the quasi-anonymity and one-off nature of the relationship.
  • The middle-man doesn’t add much value.

In light of the news of Ronald Coase’s recent passing away, we might want to consider whether this crowdworking phenomena can be understood in terms of his transaction cost analysis of firms.

I’ve had some limited experience as a consumer of crowdwork. My impression so far is that you have to wade through a sea of rubbish before you find someone worth paying. And when you’re there, you’d really rather deal with the person one-on-one in an on-going, no-commitments basis. What makes all of this work is search and reputation, and a fragmented hodge podge of different crowdwork platforms doesn’t really perform either of those functions very well.

Indeed, the very term “crowdwork” suggests the wrong framework, in my opinion. Most work takes place over time and needs to be integrated by the entrepreneur or manager with other work to make the whole. Both of those factors require lots of tacit knowledge on the part of both worker and employer. Tacit knowledge is the sort of knowledge that only really exists in the minds of individuals or small groups. You can’t share it with a paid “crowd”.

To make this empowering vision work, I think we need a protocol rather than crowdworking platforms.

Oh, and the highest paying gig the journo did was.. getting paid to click “likes” on websites, something that requires no skill at all!