Open protocols allow any application to build on them. Open access creates competition, and makes it harder for any single application to establish a sustainable business model. Many decentralized projects run on volunteer work and donations. This funding method will not be covered. This document will explore examples of decentralized projects that have succeeded or failed to monetize, as well as emerging and experimental monetization possibilities.
Three layers of business models can be considered: application level, provider level, and protocol level. Application level business models for decentralized social applications are similar to current business models in centralized social applications. Providers are servers (in federated systems) or supernodes (in p2p systems) that provide capacity to the network, and may charge for their services. Protocol level monetization was not a proven business model until cryptocurrencies came into existence, and it is still at an experimental stage.
## Application Level
Protocols must be open source in order to be used and adopted. Applications built on top of open protocols do not necessarily have to be open source. Gmail is an example of a highly successful application built on top of open, federated email protocols. Every popular centralized web application is built on top of the open protocols of the web. Because of this, many of the business models for decentralized applications are already familiar.
If applications access user data through a provider, (as in federated systems where a user signs up to a server, or in Solid, where applications access user data through pods), the provider can have a separate business model from the application.
- Charge a commission of the revenues of each application.
- Charge users a membership fee. (However, up-front membership fees for users tend to discourage adoption of social applications, where users have come to expect free applications.)
- Charge users for premium features like extra storage.
One method of protocol-level monetization is the creation of a token used for transactions internal to the protocol. Facebook's Libra, which will allow users to send payments to each other, is an example of this approach. Brave browser created [BAT, Basic Attention Token](https://basicattentiontoken.org/), for transactions between publishers, advertisers and users. Advertisers pay in BAT to place ads. Publishers receive most of the BAT from ad revenue and Brave takes a percentage. Users of Brave browser earn BAT when they view ads. They can't withdraw it, and instead can only donate it to publishers of their choice. According to Brave's research, in 2020, Users could earn up to $200 by consuming ads. Publishers haven't been vocal about their earnings, but [freecodecamp have said that they earned $2000 between early 2018 to mid 2019.](https://www.freecodecamp.org/news/the-brave-browser-how-much-money-can-your-website-make-as-a-publisher/).
Existing cryptocurrencies can also be used for protocol-level business models. Brave originally used Bitcoin instead of BAT for in-browser micropayments. In a server-based federated system, servers that provide services to the network could also function as Lightning hubs that route Bitcoin payments through the social graph using payment channels, and collect fees for doing so.
Namespaces are a limited resource across a common protocol. For this reason, business models could be developed around username registrations, like how domain names are sold on the web. Currently, Twitter prohibits the trading of usernames, but a [black market has emerged](https://www.theguardian.com/technology/2018/apr/17/selling-twitter-handles-big-business-identity) anyways, illustrating the latent demand for good names. Legitimizing a username marketplace could be one method of monetization for a decentralized Twitter.
