The Benefits of Building Apps On-Chain

It sometimes feels like there’s an aversion to embedding elements of crypto into otherwise more traditional types of consumer applications. After all, why should something like a movie ticket live on-chain when millions of people already buy movie tickets as is? Or so the logic goes.

This is short-term thinking.

The real unlock lies in the long-term capabilities created from the buildups of data that aggregate on-chain. Traditional-looking apps with select elements of data or resources on-chain create the ability to see patterns of user across both time and applications. These are new information networks that not only don’t but can’t exist in Web2.

My hypothesis is that these information network, or “metagraphs,” will expand the design space for engaging and exciting consumers.

Alana Levin is an Investment Partner at Variant, where she focuses on infrastructure.

Blockchains as metagraphs

A straightforward way to envision a blockchain is as an open, permissionless database. Users interact with applications via wallets, which live above the data layer on-chain. I’ve always thought of blockchains as loosely analogous to cars, transporting users from one destination to another (where each “destination” is an app). As such, wallets also provide identifiers for one’s interactions across different blockchain-based applications.

The result is that the blockchain itself becomes an information network. By having a unified identifier for a unique user’s activity across applications, developers can start to construct and leverage more holistic views of user behaviors. These metagraphs are useful for segmenting customer behaviors, identifying superusers and facilitating more meaningful connections.

An example might help put the value of these metagraphs in context. Consider the relationship between a musician and two of their fans:

• Fan A: listens to that artist’s music on Spotify for five hours a week, likes every single one of their Instagram photos, subscribes to their newsletter, collects the albums on vinyl, buys their merch and attends their concerts whenever they’re in town.

• Fan B: listens to that artist’s music for 10 hours a week on Spotify but doesn’t do any of the other things.

Which fan is more of a superfan? Clearly it’s Fan A. However, most consumer behaviors are untraceable, and so depending on the data the musician can see, they may unwittingly value the second fan more — after all, Fan B listened to their music 2x more than Fan A.

Don’t believe this is a real pain point? Say that the musician is Taylor Swift, and both Fan A and B really want to be whitelisted for early access to ticket sales for her next tour. Based on Spotify data alone, Fan B would likely receive priority. A painful result for Fan A and an unoptimized outcome for Taylor.

Blockchains change this dynamic. Putting information and activity on-chain expands the surface area for how applications, creators and consumers may think about patterns of behavior. Many of the components in the musician example could easily involve (minimally invasive) on-chain elements:

• Subscribe to a newsletter via

  Mirror

  , with on-chain provenance of that subscription

• Like/collect social media posts on Lens (or maybe one day Farcaster?)

• Buy merch or vinyls that have digital twins on-chain

• Each ticket itself could be a non-fungible token (NFT)

• Scan a QR code live while at a concert to mint a proof-of-attendance NFT

In isolation, each of these may not seem like material improvements in consumer applications.

The aggregate metagraph, however, is a new social mapping — and that is what’s meaningful. Build a new road connecting two towns, and someone might not find it meaningful. Build a new highway system though, where each new road may not represent a significant incremental impact but the system in aggregate creates new connections, and you’ve built something powerful.

Expanding the metagraph: Time as a new element

If activity across applications is one form of how metagraphs expand context, user behavior over time is another. Every action on-chain is timestamped, which means third-party developers can tie together things that happened at certain dates/times, regardless of whether those actions occurred within their specific applications.

This is a step-function improvement in creating compelling products. References to personal history can produce compelling emotional ties between a user and an application. But within Web2, time as a dimension has been gated to incumbent apps: the data is siloed, so apps can only reference behaviors that existed within their app.

These emotional ties are powerful retention levers. Case in point: I still use Snapchat, despite not having sent an actual Snapchat in years, because I enjoy the “on this day five years ago” type of reminders and the nostalgic feelings they evoke. The longer an app has been around, the greater its ability to embed time into the product.

The problem is that new applications can’t tap into such elements of time. To date, the only way to create an “on this day five years ago” type of notification is if the app has been around for at least five years. This is not a favorable environment for new apps, which may explain why we haven’t seen many new consumer apps take off in recent years.

Web3 changes this dynamic. By encouraging activity to live on-chain, it democratizes access to information.

The ability to tap into global contextual information expands the design space for builders to remix and reimagine consumer experiences around specific points in time. One of my favorite examples would be an app built entirely around recreating “2015 vibes” — with an interface and content feed tailored to the types of songs, writing and media an individual consumed during 2015.

It’s like taking a nostalgic playlist on Spotify and making the experience 10x more immersive by enriching the interface with other media relevant to you from that time period. And because this data isn’t gated by outrageously expensive APIs, the app developers can build it with relatively low overhead. Phrased differently, the idea doesn’t need to be venture-scale to deliver a delightful experience.

Why does this matter?

It’s very possible that some breakout Web3 applications may look largely indistinguishable from Web2 in the short term — with crypto elements simply living under the hood—and that the true “aha” moments will come years down the road. An idea only needs to be modified by 3% to create something entirely new. Putting select elements on-chain may be that 3%: it creates optionality around what else can be built that leverages that data.

The challenge is that it’s rarely obvious what those products or features are, at least in the short term. As a result, some may write off the benefits of fostering such open access. I think this is a mistake. Open access to data facilitates experimentation and, in turn, creates a market of developers building with the broadest set of ideas.

Moreover, the most interesting metagraphs likely rely on identifying patterns across many applications and time periods.

My guess is there will be a point at which the richness and breadth of data onchain will hit an inflection point. Thus, while some applications may look skeuomorphic today because at the surface they only innovate on a few degrees of the product, those three degrees can change the long-term trajectory entirely.

To be clear, there are also short-term, more single-player benefits to building on crypto rails. Crypto often offers cheaper and better payment infrastructure, especially if a product’s user base is globally distributed. The relative ease of creating secondary markets means areas that may suffer from traditionally wasteful resource consumption (e.g. unused airline tickets, reservations, etc.) can be made more efficient and unlock net new value. Attribution — and value attached to sources of distribution — may be easier to track and program on-chain.

But with each of these single-player examples, it’s important to note that the problem to be solved should never really be viewed as a “crypto” problem. Rather, the framing should be to use crypto as an enabling technology for whatever industry the application actually lives within: restaurants, entertainment, sports, content creation, etc. The most compelling short-term benefits are often best described relative to the context of each industry.

The point of this piece is to highlight what might be enabled when large parts of a broader system are rearchitected in an open and collaborative way — because that’s arguably less obvious, but just as important. We’re now at a point where crypto is becoming both easy and secure enough that using it under the hood adds little to no cost — and, at a minimum, opens a valuable call option for future product directions.

So if you’re building an app that leverages elements of crypto and someone asks “why does it have to be Web3?” send them this piece. Because the question shouldn’t be whether blockchains are necessary, but rather whether they’re helpful. It’s like asking if a car is necessary to get from one place to another 20 minutes away: it’s not necessary, but so long as the technology is safe and sufficiently inexpensive, it’s probably preferable.

The same is true of blockchains: so long the infrastructure continues to improve, the answer to “is it helpful to leverage blockchains?” will increasingly be yes.