A service with the acronym PAID, which stands for Permissionless Autonomous Incentivized Decoupled, has the following characteristics:

• Permissionless: Disposable and lightweight account modeling.
• Autonomous: Its functions are managed by different, independent stakeholders.
• Incentivized: Participants are finacially rewarded for maintaining the service's health and scalability.
• Decoupled: It utilizes general microservices that can be combined to create user experiences.

As an illustration, a blockchain mining service qualifies as a PAID service because it:

• Allows any client, including automated ones, to submit valid transactions without restriction.
• Handles transactions in a decentralized manner through a consensus mechanism.
• Provides incentives through mining rewards and transaction fees.
• Integrates with other applications like GraphQL services, smart contracts, and dApps to provide various products.

In contrast, the majority of conventional services are permissioned, often necessitating or heavily promoting account registration through methods such as email addresses or phone numbers. These services typically involve human verification, consequently denying access to automated bots even if they adhere to the protocol. While some services, like Pastebin, calculators, or QR code generators, may not require registration. They are usually operated by single entities and are limited to basic functions that demand minimal resources without the defense by account models from abusive behaviors. These services are also often supported by intrusive advertising for monetization. Furthermore, they generally do not offer the same level of query flexibility as blockchains, like unrestricted GraphQL queries.

Some examples of PAID services include:

Service	Permissionless	Autonomous	Incentivized	Decoupled	PAID
Bitcoin	✅	✅	✅	✅	✅
X	❌	❌	❌	✅	❌
Mastodon	❌	✅	❌	✅	❌
Pastbin	✅	❌	✅	❌	❌

However, the concept of PAID services is distinct from decentralized applications (dApps). Further details can be found on the page comparing it to similar technologies.

Currently, many Internet companies generate revenue through advertising, a successful approach for quickly gaining market share by offering a free service. After achieving a dominant position, these companies can generate significant profits through advertising as a media channel. However, this model also has several disadvantages.

• Monopoly: Service providers lose motivation to enhance their offerings once they establish a monopoly. They may then begin to exploit users by increasing the amount of advertising to boost revenue. Some may provide a premium membership option at a monopoly price. Yet, they still lack the incentive to consistently improve the service unless a competitor emerges, which is hard in areas like social networks.

• Privacy: To tailor advertisements, companies typically monitor users' clicks and impressions, raising privacy concerns. Even anonymous identifiers do not prevent the linking of user behaviors. Furthermore, recent advancements in private tracking methods like VDAF require more computing power to scale or rely on stronger assumptions about non-colluding servers.

• Data Isolation: The most valuable assets for content companies are their data, which are collected in two forms: publicly available, general viewer-agnostic data such as posts, and user behavior data used for modeling and creating recommendation systems to attract users. The exclusive control over these data enables companies to establish unique communities but also restricts the possibilities for sharing and collaborative use.

• Mandatory App Experience: Typically, a company develops its own app or website and limits user access to resources through these platforms. App development is dictated by the company's business objectives rather than individual user needs. For instance, a user might prefer to open PDF files in single-page view by default, while others prefer continuous scrolling. A PDF reader app company may not consider this feature a high-priority development item. As a result, many minor features are missing or difficult for users to personalize in settings.

PAID services aim to address these issues in the following ways:

• Free market of services: Open-source code for the user agent ensures that it acts in the user's best interest transparently. It will consistently choose the service that offers the optimal experience, such as the highest click-through rate and viewing duration. This essentially breaks the traffic monopoly held by service providers. Traditionally, viewer-agnostic data is controlled by both the uploader and the content service company. Here, we eliminate the latter to create a free market for content services, which aligns better with the original intention of authors sharing their content.

• Purchasable privacy: Acknowledging the importance and cost of privacy, PAID services offer users the option to pay for privacy features or opt out in favor of improved usability and convenience, catering to varying levels of privacy concern among users.

• Cross-app behavior access: Instead of traditional data collection by individual companies with indefinite consent upon app installation, PAID services do not collect free data for model training. However, users can benefit from models trained on data purchased from other users. Moreover, during inference, the data is now shared across multiple apps for content recommendation. Again, users concerned about privacy can perform inference on their own devices using downloaded models.

• Personalized user interface: PAID services allow users to select their preferred app. Content is delivered to any client app without restrictions or concern about resource abuse, as providers are already compensated for customer usage. This serving style also opens the potential for AI user interfaces where users directly specify desired features.

How and why do we use these four PAID properties to achieve these goals? Let's explore them individually.

We aim for permissionless services to eliminate the need for traditional accounts, which are "heavy".

In recent years, companies have been compelling users to provide multifactor personal information, including accounts on other platforms, personal phone numbers, and device IDs, ostensibly to "keep accounts safe." This data is sensitive for smaller companies to manage. Additionally, it hinders user adoption by requiring mandatory preliminary procedures before using the app.

If we examine the reasons why accounts are used, we discover they address separate issues. Some of these can be solved with lighter, more scalable alternatives:

1. Reputation and Sybil attacks: Identifying and preventing spam traffic to avoid wasting computational and bandwidth resources.
2. User state management: Tracking and storing user interaction history for user experience and efficient commercial conversion through content recommendations.
3. Valuable asset management: Recording users' valuable assets (money) and facilitating transactions between parties.
4. Access control: Restricting resource access to authorized users and preventing unauthorized modification.

For the first two challenges, PAID services employ pseudo accounts that are inexpensive and disposable:

• Sybil attacks: Users are charged for each operation, eliminating the need to differentiate between human users and bots since all actions are paid for.
• User states: User states are stored on the frontend with recommenders downloaded to the edge. Tracking is only done if explicitly purchased by recommender companies for model training.

For problems 3 and 4, accounts are still required, potentially involving the intrusive information collection practices already employed by major technology companies for authentication safety.

For problem 3, asset management, PAID services offer a partial solution. We minimize the assets under management by ensuring that each transaction involves a small amount. Even if an account is compromised, the loss remains manageable. Thanks to the Internet's scalability, we can support most commonly used daily applications with small assets.

This relaxation also allows us to avoid consensus mechanisms, which are costly, even after decades of attempts by the blockchain community to solve them.

Regarding problem 4, access control, we do not currently have any new solutions. However, for common daily uses such as browsing content or searching for items like shoes, most applications can and should relax their constraints to cultivate a healthier environment. For example, a seller listing a T-shirt on a marketplace shouldn't need to limit details like color, size, and price to only users of that platform. A seller will generally sell as long as they are paid, regardless of the platform. Platforms often restrict crawlers from accessing publicly intended information for their own benefit, rather than the benefit of the sellers. If we relax access control to allow third parties to collect, process, and serve buyers and sellers, it could lead to greater overall social benefits rather than just platform revenue.

Even for some writing operations, an account isn't necessary. For example, when someone publishes content, such as code on a repository, they only need to pay for the storage and bandwidth used by those downloading it, unless they want to maintain an identity to build trust for future contributions.

Finally, accounts tied to human identities are becoming less suitable with advancements in intelligent machines. We want machines to exchange information before providing it to humans. For example, a user browsing an e-commerce website might want an AI agent to select items based on specific needs. Allowing user agent bots and platform seller bots to interact may be necessary for developing next-generation user interfaces.

To foster a competitive market where service quality thrives, it's crucial that service providers can transition between options easily and affordably. A cloud-centric strategy is being adopted to promote the freedom of choice for service providers. Federation, where each node handles a segment of overall requests and an aggregator compiles content from these diverse nodes for users, represents one method to achieve this. Usually, each node must manage its own complete service infrastructure, encompassing separate account management, an activity database, and object storage. This is referred to as vertical autonomy.

!figure

In contrast to federation, PAID services realize autonomy through a cloud-centric strategy. Like SaaS, each abstract service is dedicated to its specific function, with independent service providers implementing them and building upon one another. They achieve autonomy by being able to switch service providers as needed. This is termed horizontal autonomy.

PAID goes further by offering a marketplace featuring standardized interfaces for defining functions and controlling the quality of each abstract service. This facilitates seamless transitions between services. Even the cloud itself is treated as an abstract service, preventing any single cloud provider from having total control over services running on it, as these services can switch to a different cloud if the current provider's service quality declines.

With a competitive service marketplace, we can examine the effects of applying modern financial instruments. Standardization allows for the stabilization of service prices using financial tools such as futures and options.

Imagine a situation where a service experiences low demand in the morning and high demand in the evening. The service provider could issue access tokens with a one-hour expiration. Consequently, prices would be low in the morning and high in the evening. Traders could also accumulate access tokens if they believe the service provider's price is too low. Eventually, the access token's price would stabilize at an equilibrium point. Regardless of how these tokens are traded, the service provider remains incentivized because they always receive payment for all access tokens, whether from end-users or speculative traders, ensuring non-negative utility.

Typically, information stored in databases is accessed through a "backend" server, which manages business logic for query formation, authorization checks, and data flow management. However, in PAID services, applications are designed to minimize backend business logic at the server level, instead implementing it in the frontend via user agents.

User agents decouple infrastructure services by using multiple standardized services simultaneously. This enables seamless switching between services, as they are already in use concurrently.

As their name suggests, user agents represent the user's interests. They can remain unbiased by major technology companies by using transparent, open-source implementations.

User agents also hide the complexities of the underlying services from the user. Users only need to remember the brands that provide these user agents. After selecting a user agent, it will track service reputation, quality, and cost on behalf of the user.

Furthermore, the user interface is more adaptable. Instead of being limited to a single interface dictated by one company, users can select any application maintained by the open-source community.

1. Birulin, Oleksii. (2006). Public goods with congestion. Journal of Economic Theory. 129. 289-299. 10.1016/j.jet.2005.01.003.

Even considering this limitation, PAID services are not intended to completely replace advertisements or traditional monetization strategies. They function as a complementary system. Users with limited budgets can choose to either exchange their privacy for sponsorships or view advertisements, or both, to offset the cost of the high-quality service fee.

The key distinctions between PAID and conventional advertising-based monetization are summarized in the following table:

	PAID	Traditional
Paid by	Users	Advertisers
Pricing	Service market	Advertisement market (ADX / DSP / SSP)
Viewer-agnostic data	Public goods	Private goods
User behavior data	Bought from user	Given out free
User interface	No restriction	Only the app built by the company allowed
Content recommender	Full competition	Data isolation
Service provider	Decentralized microservice stakeholders	Single stakeholder
Disaster recovery	Builtin by the market	Dedicated efforts
Account model	Permissionless	Registration required
AI readiness	Bot welcoming	Human only