Decentralized applications (dApps) are in vogue and we hear about them in almost every forum. Currently, there are more than 2,100 active dApps, with a cumulative DAU around 25,000 — . The lack of user adoption is not solely a symptom of early market entry, it is a fundamental limitation of decentralizing a consumer application. What I would argue is that the killer apps in crypto are going to be with decentralized components. Rather than building decentralized protocols, they will decentralized protocols in their centralized consumer apps. source centralized on top of integrate Before we jump in let’s first align on some definitions: an app that runs on a shared protocol with a shared data layer and is not controlled by one single entity DApp: an app operated by a single entity that controls UX and maintains a central database for operations native to the app Centralized App: Centralized apps will win the user experience battle with decentralized applications ten times out of ten. I feel confident making this rigid statement because it is simply a question of what consumers care about — simplicity, speed, and breadth. All of which are compromised when the core user experience is entirely decentralized. Developers care about three things: build, grow, monetize. A decentralized protocol has properties that will fundamentally change the third prong (monetize), but the dichotomy is that the same virtue that unlocks new monetization opportunities hinders the first two (build, grow). Crypto fundamentally changes the monetization paradigm for app developers, unlocking a new design space that is grounded in growing demand for a scarce asset. This aligns incentives of the actors to bootstrap the growth and use of the network (I wrote about this in further detail ). The fallacy in the dApp thesis is that all components should be decentralized. This constraint is fundamentally at odds with the app’s ability to generate network effects. here Let’s use Snapchat as a concrete example. If Snapchat was implemented as a dApp, every snap would have to wait for confirmation from validators and would then be committed to a public ledger. Consumer apps like Snap are driven by network effects: number of friends on the network and the fast feedback loop inherent in ephemeral communication. If Snap was a dApp on Ethereum and every DAU sent snap it would take 351 days just to process them all, give or take. Obviously this is an extreme example, ignoring layer-2 solutions or more performant permissioned blockchains. But, even if throughput was orders of magnitude higher, and every snap sent was captured in the next block, at a lower bound snaps would take 5–10 seconds to be delivered — in consumer tech, 5 seconds feels like an eternity. one Reducing user friction is a foundational prerequisite for growth. The strategy is counter to the adoption and usage of these networks. The build/grow pillars are diametrically at odds with the monetize pillar. “Decentralize Everything” Cryptokitties was an example of this — it found some level of product/market fit and some initial momentum but effectively never took off — failure to launch. That wasn’t because they didn’t have a novel product or a strong team, they were hamstrung. Network effects are everything, and when an app hits a level of virality the compounding effects render graphs that go up and to the right — every startup’s dream. However, dApps have an upper-limit on their growth given the limitations of the network. It’s not like early Instagram days where they can call up AWS to get more server bandwidth, the open network is tapped out. My argument is not anti-decentralization, my argument is that we should start with the components that do need to be decentralized and build centralized products to enable engagement in those decentralized networks. An app is a tool to engage in a decentralized network but often has core functionality outside the scope of decentralization — these ancillary use cases should be bifurcated. An example would be a game that monetizes by selling scarce digital collectibles to users i.e. swords, shields etc. The collectibles need to be maintained on a decentralized network to guarantee state, and when sold, should be with a decentralized currency — but the game itself, the onboarding experience, the communication between players should be centralized. Not every action in the game is going to involve the collectible, in fact, what makes the collectibles attractive is that most users have one. This app would generate a lot more demand for the scarce asset if millions of users were hyper-engaged in the game and only a small subset had the rare sword. This is best accomplished if the game developer builds a killer game on centralized servers, makes it easy to onboard, play and invite friends, and then integrate the decentralized components that it needs. I would bet on that horse over the one that is decentralized first, asks a user to complete complex operations to onboard and can’t scale because of network limitations. don’t Startups are like a drag race, once you find product/market fit its an exercise in reaching escape velocity so that no one can catch you. This is even more critical for dApps because they’re operating in an open-source environment — you can’t just “fork” Instagram — so the margin for error for dApps is even lower than traditional consumer tech. It’s like starting the drag race but instead of a dragster you’re in a golf cart, and you left a bunch of other golf carts for every other developer at the starting line, gassed up and keys in the ignition. This brings me back to where I opened. Our core thesis at Kin is that the killer app for crypto is just that, an app, not a dApp. DApp platforms optimize for decentralization, requiring developers to sacrifice user experience. Kin is not a dApp platform. Kin is a decentralized monetization tool for centralized apps, developed from first principles, optimizing for consumer experience with a bias towards pragmatism. In an open-source environment, network effects are everything — crypto unlocks a fundamentally new business model where apps have an economic incentive to drive demand for a scarce asset — the best way to drive demand is in a centralized app.
