One of the potential benefits of the new app token business model, in which the developers issue tokens that have a utility within the application or protocol, is that it helps solve the cold start problem. Speculators and crypto enthusiasts will want to get in on the token early at a low price in expectation of future gains (if they believe in the value prop of the network), which will in turn drive up the price, and create incentives for participants to want to participate in the network to earn the currently inflated value of the token. At some point, the actual value of the network has to catch up and exceed the initial speculation, but in the early days, the inflated value actually helps bring new users into the network, potentially getting over the hump of the cold start challenge faced by so many consumer applications.
This is great, but it presents another type of cold start problem - the fact that in many implementations, users must hold some of the token initially to participate in the first place, either because there are transaction fees associated with every action (Ethereum gas), or there are bandwidth and anti-spam limitations that require a minimum holding (Steem bandwidth limits). What are the options for an dApp developer on top of the Ethereum or Steem blockchains to get over this hurdle? I see a few options...
- Require the user to purchase the token.
- Transfer some token to new users from the company monetizing the dApp.
- Use a distributed credit network to fund the growth of the network.
For #1, unless the app is highly transactional in nature (placing a bet, buying an asset, etc) I think we can all agree that the hurdle to purchase and acquire a crypto token just to take any action in the network is too high. People won’t bother. In the case of #2, the model used by Steemit Inc, this transfer of value is built in as a customer acquisition cost. It can definitely make sense, but it required Steemit to hold a large portion of the tokens initially, to verify their new users identities via FB or Reddit, and it isn’t necessarily long term sustainable. I’d like to focus on #3, the idea of a distributed 3rd party playing the role of credit provider to the network.
Let’s use a social network like Steemit as an example for how this may work. Steemit has a bunch of low friction actions like voting and commenting that people wouldn’t necessarily buy token in order to accomplish. Steemit also has some high value transactional actions that people would gladly pay Steem for, such as promoting a post. The basic idea is that rather than Steemit.com needing to give away Steem to each user in order to get them to try low value actions, hoping that they’ll eventually contribute to increased high value actions, they could rely on a 3rd party to take this risk while the economics made sense to do so. The third party could essentially provide credit to new users, depending on their ability to qualify them on chain via things like past transaction history in other dapps, linked identities, balances, requirements of this dapp, etc. And then the third party would have a hook to take a cut of the high value transactions.
The rate that they charged would float depending on the network’s ability to monetize and sustain its new user growth. So as more users engaged in the value creating transactions, the rate would go down and the amount of credit extended could increase. This could even be decentralized, via the credit provider being a DAO in which users invested their own capital and voted on whether to accept certain app’s proposals and implementations, in exchange for receiving the profits generated by the credit providing contract. In order to implement such a system, an app would have to provide the following hooks.
- Ability for credit provider to set the rate they’re currently charging.
- Hook within the high value transaction to send the credit provider their cut.
- Ability to make a call to the credit provider to extend credit to a specific user, and ability for the credit to be received.
- Fallback experience for if credit is denied for a specific user. Likely user has to bring their own capital.
- Ability to boot the credit provider, again relying on the fallback.
- Ability for credit provider to stop serving the ecosystem.
Steem is somewhat centralized at the moment during the early days with Steemit being the main application provider, and protocol developer, but I could see all of this being encoded pretty nicely into a series of Ethereum smart contracts.
If the credit provider abuses their power and sets a non-market-determined rate, they will lose their job and be booted from the network. If the network fails to monetize effectively, then the credit provider will determine it isn’t worthy of its credit, and will stop serving the network (for example if no one is buying promoted ads). Sybil attacks could be identified by either party and would certainly affect the credit model, but both sides are incentivized to put in place the right requirements/incentives to achieve credit transparently as a new, legitimate user.
Since different businesses have different characteristics and different credit profiles, the DAO governing the credit agency has the ability to manually review the business plans and network’s worthiness offchain and vote onchain whether to extend credit in the first place and under what parameters. Working this out is an exercise left to the reader 😉, but if enacted it could enable a less risky environment for funding the early growth of a dapp, prior to the business maturing enough to capture all the value it intends to in the long run.
Do any services exist like this on chain in Ethereum or other networks? Who’s doing interesting stuff to get over the cold start problem as it relates to consumers acquiring cryptocurrency to participate in a light-transactional dapp? Let me know here or @petkanics on twitter.