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.
2 thoughts on “AppCoins: embedded cryptocurrencies”
It certainly sounds useful to have cloud apps to charge fees: to turn online apps into vending machines. But why use a different currency for each app a la “TorCoin”? Surely the ecosystem works far better if I can spend the coins I acquired running a Tor node on many other things besides Tor.
Since the AppCoin is exchangeable for other cryptocurrencies, you can spend your AppCoins on anything sold for any crypto currency. One of the advantages of AppCoins is native support of two-way tx (coin vs app service), but whether it makes since for an app to use its own coin or another rests on the technical merits of the particular AppCoin spec. For example, it makes sense for a distributed dns to have its own coin because you need to incentivise miners to maintain another blockchain. How about Tor? Don’t know, but I’d guess that some sort of distributed usage ledger would be required, and that suggests an AppCoin. Some types of trades lend themselves to reputation enforcement, some lend themselves to escrow or m-of-n signature, and some (like namecoin) distributed record keeping. Allot of web services fit into this layer category, and these are most amenable to an appcoin approach. That’s how I see it at least.