With web3 we have the opportunity to build new systems where value, data transfer, and communication are peer-to-peer; tied to your digital identity rather than to platforms.

As more and more creators start livestreaming on the402, we want to make sure that we can empower them to build a fan graph that they own. We wanted to build a way where creators can communicate with the audience they’ve built rather than relying on us or Twitter.

Current platforms like Twitch & Youtube gate-keep data. As you grind to gain more of an audience and subscriber base, you still know very little about who your audience is..while the platforms know every single detail. You can spend years growing your audience and at the snap of a finger, you can be de-platformed, losing everything that you’ve worked for with no way to reclaim or reach your audience.

In fact, this exact thing happened to one of our friends, who quit his 6-figure job to become a full-time YouTuber only to be de-platformed after 2 years of work.

Currently, we’ve been heavily reliant on Twitter as the main form of communication to notify audiences or potential collectors that a drop or livestream is happening. Twitter is great to build the top of funnel, but there needs to be proper infrastructure in web3 to connect with your fanbase.

We’re actually DMing every collector to notify them that a livestream is about to happen!

With on-chain subscriptions, creators will have full independence. The record of subscribers is immutable and they have the ability to directly communicate with their fans.

Power is shifting from platforms to individuals. As we design new platforms around the individual creator, it’s our responsibility to create systems for individuals to have full control of their audience.

https://ppv-nft-files.s3.us-west-2.amazonaws.com/Screen+Recording+2022-09-19+at+9.42.43+AM.mp4?autoplay=true&muted=true

At a high level, we have a smart contract (currently on testnet) that registers a subscription from a fan to a creator.

This subscription includes the wallet address of the subscriber as well as a pointer to an IPFS URL containing the email address of the subscriber, encrypted using Lit Protocol in a way that only the creator can decrypt.

The data is indexed via Graph Protocol and creators can see their subscribers in our web app.

First things first, we had to identify the technical constraints we were operating under. And this required answering a few questions:

1. Why do we need to store subscriptions on a blockchain?

2. What functional role does a subscription play? Is a subscription a time-bound monetary contribution? Or a way for creators to simply collect the contact info of their fans?

3. Given the answer to question 2, what information did we want a subscription to carry with it?

Let's answer these questions one by one.

Why use a blockchain?

A blockchain is a strictly better data structure for subscriptions to be stored on for 2 different reasons, the first of which we are making use of now and the second of which we have the option to take advantage of later. The first reason is that an on-chain subscription is immutable and permanent. Even if we wanted to, we wouldn't be able to remove a creator's ability to access their fan's contact information. In this respect, an on-chain subscription is a significant improvement over a centralized database with a permission-gated API.

Second, on-chain subscriptions easily come with the ability to add monetary contributions because doing so would just require us to make the subscribe function payable. We haven't added the ability to tie a subscription to a payment (more on that below), but retaining the option to add that piece of logic is valuable.

What role do we want subscriptions to play?

We have chosen to focus on the utility for an artist to collect the contact information of their fans, e.g. to notify them of future drops. While permissionlessness and permanence are nice long-term benefits of using a blockchain, the short-term benefit of our on-chain subscription contract is to give artists a way to collect the emails of their fans. We chose this instead of payments because as previously mentioned, this was a common ask from creators. We do see paid subscriptions as an important part of the future of web3 monetization, but keeping payments out of the initial implementation allows us to test the value prop of on-chain subscriptions on testnet first.

What information do we want a subscription to carry with it?

While storing the addresses of subscribers in the subscription graph is useful, we also wanted to store their email addresses so that creators can reach out to their fans directly..

So given these constraints, the main technical problem to solve was how to store the email addresses of a creator's subscribers in such a way that only the creator has access to them.

The smart contract that we developed contains a function that allows us to register a subscription. Because we are not dealing with payments at the moment and simply using the blockchain as a database, we were able to keep this contract on testnet. Furthermore, since we register a subscription on behalf of our users, a user that wants to subscribe to an artist doesn't have to sign any transactions themselves, making the UX less cumbersome.

We decided to store the email addresses in IPFS, instead of on-chain. Storing the addresses in the contract felt like overkill, as it could lead to a more bloated contract and higher gas fees when we migrate to mainnet. Each IPFS file contains the email address of one subscriber, and the contract contains the pointers to all the IPFS URLs. However, a pointer to an IPFS file containing an email address is not secure (even if the IPFS URLs are stored in a private variable), so the IPFS files contain an encrypted version of the subscriber's email address. We use Lit Protocol to encrypt the email address with one on-chain criterion required to decrypt the string: that the person trying to decrypt the email is the same creator that received the subscription.

And that's all it takes! We spun up a subgraph on the Graph Protocol to index data from the subscriptions contract and built flows in the web app for fans to subscribe to their favorite creators. In addition, creators have a dashboard that they can visit to view the addresses and emails of their subscribers. We’re excited to roll this out today on our site and see what on-chain subscriptions will unlock for our creators.

Stay tuned for more updates on our Twitter!

With web3 we have the opportunity to build new systems where value, data transfer, and communication are peer-to-peer; tied to your digital identity rather than to platforms.

As more and more creators start livestreaming on the402, we want to make sure that we can empower them to build a fan graph that they own. We wanted to build a way where creators can communicate with the audience they’ve built rather than relying on us or Twitter.

Current platforms like Twitch & Youtube gate-keep data. As you grind to gain more of an audience and subscriber base, you still know very little about who your audience is..while the platforms know every single detail. You can spend years growing your audience and at the snap of a finger, you can be de-platformed, losing everything that you’ve worked for with no way to reclaim or reach your audience.

In fact, this exact thing happened to one of our friends, who quit his 6-figure job to become a full-time YouTuber only to be de-platformed after 2 years of work.

Currently, we’ve been heavily reliant on Twitter as the main form of communication to notify audiences or potential collectors that a drop or livestream is happening. Twitter is great to build the top of funnel, but there needs to be proper infrastructure in web3 to connect with your fanbase.

We’re actually DMing every collector to notify them that a livestream is about to happen!

With on-chain subscriptions, creators will have full independence. The record of subscribers is immutable and they have the ability to directly communicate with their fans.

Power is shifting from platforms to individuals. As we design new platforms around the individual creator, it’s our responsibility to create systems for individuals to have full control of their audience.

https://ppv-nft-files.s3.us-west-2.amazonaws.com/Screen+Recording+2022-09-19+at+9.42.43+AM.mp4?autoplay=true&muted=true

At a high level, we have a smart contract (currently on testnet) that registers a subscription from a fan to a creator.

This subscription includes the wallet address of the subscriber as well as a pointer to an IPFS URL containing the email address of the subscriber, encrypted using Lit Protocol in a way that only the creator can decrypt.

The data is indexed via Graph Protocol and creators can see their subscribers in our web app.

First things first, we had to identify the technical constraints we were operating under. And this required answering a few questions:

1. Why do we need to store subscriptions on a blockchain?

2. What functional role does a subscription play? Is a subscription a time-bound monetary contribution? Or a way for creators to simply collect the contact info of their fans?

3. Given the answer to question 2, what information did we want a subscription to carry with it?

Let's answer these questions one by one.

Why use a blockchain?

A blockchain is a strictly better data structure for subscriptions to be stored on for 2 different reasons, the first of which we are making use of now and the second of which we have the option to take advantage of later. The first reason is that an on-chain subscription is immutable and permanent. Even if we wanted to, we wouldn't be able to remove a creator's ability to access their fan's contact information. In this respect, an on-chain subscription is a significant improvement over a centralized database with a permission-gated API.

Second, on-chain subscriptions easily come with the ability to add monetary contributions because doing so would just require us to make the subscribe function payable. We haven't added the ability to tie a subscription to a payment (more on that below), but retaining the option to add that piece of logic is valuable.

What role do we want subscriptions to play?

We have chosen to focus on the utility for an artist to collect the contact information of their fans, e.g. to notify them of future drops. While permissionlessness and permanence are nice long-term benefits of using a blockchain, the short-term benefit of our on-chain subscription contract is to give artists a way to collect the emails of their fans. We chose this instead of payments because as previously mentioned, this was a common ask from creators. We do see paid subscriptions as an important part of the future of web3 monetization, but keeping payments out of the initial implementation allows us to test the value prop of on-chain subscriptions on testnet first.

What information do we want a subscription to carry with it?

While storing the addresses of subscribers in the subscription graph is useful, we also wanted to store their email addresses so that creators can reach out to their fans directly..

So given these constraints, the main technical problem to solve was how to store the email addresses of a creator's subscribers in such a way that only the creator has access to them.

The smart contract that we developed contains a function that allows us to register a subscription. Because we are not dealing with payments at the moment and simply using the blockchain as a database, we were able to keep this contract on testnet. Furthermore, since we register a subscription on behalf of our users, a user that wants to subscribe to an artist doesn't have to sign any transactions themselves, making the UX less cumbersome.

We decided to store the email addresses in IPFS, instead of on-chain. Storing the addresses in the contract felt like overkill, as it could lead to a more bloated contract and higher gas fees when we migrate to mainnet. Each IPFS file contains the email address of one subscriber, and the contract contains the pointers to all the IPFS URLs. However, a pointer to an IPFS file containing an email address is not secure (even if the IPFS URLs are stored in a private variable), so the IPFS files contain an encrypted version of the subscriber's email address. We use Lit Protocol to encrypt the email address with one on-chain criterion required to decrypt the string: that the person trying to decrypt the email is the same creator that received the subscription.

And that's all it takes! We spun up a subgraph on the Graph Protocol to index data from the subscriptions contract and built flows in the web app for fans to subscribe to their favorite creators. In addition, creators have a dashboard that they can visit to view the addresses and emails of their subscribers. We’re excited to roll this out today on our site and see what on-chain subscriptions will unlock for our creators.

Stay tuned for more updates on our Twitter!