A New Era: Celebrating 15M End-Users & Debuting Our Token-Centric Economy

Today, we celebrate a major milestone with an even greater announcement. 

A mere 12 months after launching, Particle has crossed 15 Million wallet activations, an explosive signal demonstrating the strong need for seamless Web3 onboarding. Over 800 decentralized applications are now integrating Particle's Wallet-as-a-Service solutions, propelling us to millions of existing and new Web3 users –particularly in the gaming sector. We credit this to our blazing-fast onboarding (0-100% in 20 seconds!) and profound care for user experience.

Propelled by this momentum, Particle's upcoming v2 will build upon our existing products with a focus on enhancing privacy, cross-chain interactions, user experience, and transaction efficiency. To support this transition, today we're officially announcing a crucial strategic shift along the road to v2: saying goodbye to our SaaS revenue model, embracing a token-centric economy free of charge for developers. 

Let us look into our rationale for this decision, the dyamics of value accrual in token economies, different trends emerging in Web3 revenue strategies, and give you a sneak peek into the Particle Network token’s utility.

Why this change?

Particle Network sits at a unique spot in the Web3 ecosystem. 

Simultaneously serving the creators of dApps and their users, Particle falls under a Business-to-Business-to-Consumer (B2B2C) framework. And, although our SaaS strategy has served us well, allowing Particle to reach a vast number of developer partners and their end-users, we believe it's time to reassess. In particular, to look at what our current business model represents for developers –our most important partners– and how we can best serve them while sustaining the network's growth.

Infrastructure projects in the Web3 space inhabit a unique, crucial layer in the ecosystem. They essentially act as the bridges between the decentralized, blockchain-based world and real-world users and developers, ensuring that data, transactions, and other information can flow seamlessly across the environments of Web2 and Web3. 

Supporting the above usually requires these projects to produce a sustainable centralized infrastructure, as fully decentralized solutions might not yet be robust enough to bootstrap the ecosystem. Consequently, infrastructure providers need to find economic models that can effectively co-exist with their hybrid nature.

Let’s take a quick look into the existing economic models in our space, their pros and cons, and illustrate how we arrived at our target model by combining the best features out of several of them.

Prevalent infrastructure economic models in Web3

When it comes to infrastructure providers and their models to try to create sustainable revenue, there are a couple of established verticals worth exploring:

Web2 infrastructure SaaS models 

Type 1: Charging per monthly active users (MAU)

One approach to revenue models is for infrastructure projects to charge developers based on the users they onboard. Currently, Magic.link uses this model, allowing developers to start for free and begin paying per Monthly Active Users (MAU) after they cross the 1,000 MAU threshold. Magic also provides custom packages for projects with monthly userbases over 20,000.

Particle Network’s original revenue model was also based on MAUs.

Pros and cons

For users, particularly when there is a free option available, this model might result in a frictionless path to begin their journey, only paying once they have bootstrapped a substantial user base. As such, it might be seen as a scalable way for teams calculate costs, as they are proportional to their project’s growth. However, if a project does not have a clear revenue strategy, this model might quickly turn into an eroding cost, somewhat forcing developers to scramble for profits or cover the costs themselves. 

As a provider, this model allows the infrastructure project to focus its business development (BD) efforts on acquiring large customers. As projects scale using the product, the model might also be a net positive for user retention, but at the cost of having to sustain a large free-user base with no guarantees. Furthermore, for certain types of projects (such as Magic and Particle) this method fails to effectively capture value as the network grows. The project’s value proposition becomes more attractive as more end-users benefit from its product, and the MAU model fails to capture this value. Additionally, the incentive to seek large customers might result in smaller players being under-supported.

Type 2: Tiered subscription models

Another common angle for infrastructure providers is to use a tiered subscription model. A good example of this is Infura, a provider of APIs enabling access to the Ethereum and IPFS networks. 

Like Magic, Infura offers a freemium subscription for beginners. However, instead of paying per user, teams can then upgrade to one of the different available packages, each allowing for a higher number of daily API requests.

Pros and cons

For the user, a tiered system like Infura’s might result in a substantial increase in price once they reach the limits of a package, forcing them to bump to a superior one. As such, they might prefer an MAU-based approach, paying per acquired user, or simply a model that proportionally charges them per interaction. A tiered model can also result in some features being out of reach for teams with fewer resources. For this reason, some providers might aim to combine this with a MAU approach, including an proportional fee per interaction additional to the package.

For providers, this method has similar pros and cons as MAU models. Both can be positive for retention and fail to accrue network effects, although subscriptions can also lead to desirable income predictability for providers.

Type 3: “Base + consumption” models

Some infrastructure providers, like fiat ramps, keep a straightforward, sales-based approach to generating revenue. In the case of these ramps, they typically charge applications a setup fee, plus a variable percentage of the transactions going through their infrastructure. As shown below, these might vary based on features and other factors.

Pros and cons

This model is very attractive for providers, as they get to experience linear growth via business development while retaining a base level of passive income generated by charging fees. The only possible downside from this perspective is that, arguably, this model generates a race to the bottom when it comes to prices and margins.

For projects utilizing infrastructure via this model, this results in predictability, albeit with the annoyance of paying more as they grow. However, since this model heavily depends on the nature of B2B relationships, it’s likely that projects can negotiate deals that better suit their preferences, or simply switch providers. Some projects may also opt to impose the payment of fees on end-consumers, resulting in a less attractive product but no commission payments.

Web3-native models

Type 1: Token-as-payment-currency models

Web3-native models allow infrastructure providers to take advantage of the unique capabilities of Web3. Within this model type, some providers choose to conduct regular SaaS strategies but with a tokenized economy.

As an example, let’s look at Ankr. Ankr provides projects with access to RPC endpoints and other infrastructure. Their business model is based on users spending in-app credits that they can obtain via fiat payments or via Ankr’s $ANKR token. Users can also stake $ANKR to earn platform fees, govern the platform, and participate in other ways.

Pros and cons

As a business model, this is not too different from a SaaS model, and as such developers might either find the additional Web3 capabilities an additional annoyance or a benefit, depending on their desire to participate in the network and govern the project. The freemium capabilities might also help bootstrap their projects. In some cases, such as Ankr’s, the system might work in a suboptimal way due to the costs of conducting business on-chain. To exemplify this, in Ankr’s case, all transactions are based on intermediate units (credits), rather than directly spending the tokens, possibly to reduce gas fees for users.

For infrastructure providers, some aspects of including Web3 features might result in the need for compliance efforts related to the token, which might not be entirely justifiable by the benefits. It could be considered that some of these benefits might only be ideology- and optics-related, ingraining the project into the Web3 ecosystem without it ceasing to be essentially a SaaS provider.

Type 2: Token-centric models

We can exemplify this through another well-known provider of infrastructure services in Web3: The Graph, an indexing protocol for organizing blockchain data and making it accessible. This project has opted for a different strategy centered around their native token, $GRT. Their token serves to align the incentives of different ecosystem players, distributing the profits generated by their services amongst them.

In this model, developers pay query fees in $GRT to access data for their applications. Other ecosystem players include:

• Indexers, who stake $GRT to provide indexing and query processing services to earn fees and rewards.
• Curators, who signal on useful data sources by depositing $GRT, indicating to Indexers what should be indexed. They also earn fees.
• Delegators, who delegate $GRT to Indexers, securing the network and earning rewards and fees.

This model allows The Graph to operate as a decentralized protocol. It’s worth noting that The Graph initially operated primarily as a centralized service –developers used it for free, with The Graph hosting data. This period focused on building a user base, refining the product, and establishing market fit, rather than on monetization.

The costs for developers, as indicated by The Graph, are proportional to usage. Developers can choose whether to set up an account where they pre-authorize the system to spend $GRT from their wallet or get it auto-billed in fiat from a credit card. The following is a sample of The Graph’s estimations of their costs:

Pros and cons

Not all token-centric models are the same. As such, certain assessments can only be made individually, although there are common trends and characteristics.

One attractive factor for users, without a doubt, is that a token-centric model usually opens the possibility for users to play multiple roles. Depending on the implementation, a token-centric ecosystem can be purely decentralized and permissionless, attracting users due to its security. This applies to our earlier example, The Graph. 

Some token-centric platforms might also allow users a voice in the protocol’s governance as primary participants and stakeholders. In token-centric designs, there are also typically no barriers to accessing data about the protocol, allowing users to spot opportunities. These models, however, come at the cost of the typical barriers of decentralized economies, such as exposure to token volatility. Similarly, some developers might prefer a model that does not involve the additional activities related to paying with tokens, such as acquiring them, covering gas fees, and making sure their accounts always have enough of a balance to pay for costs. Each application also needs to find a model to charge users (pay-per query in The Graph’s case) to sustain itself, and these models might not always be universally attractive. 

From the provider’s perspective, token-centric models open many opportunities, such as creating scalability, quality, diversity, participation, and security incentives. Incentivizing different participants, although it creates a technical knowledge barrier of entry, does carry the possibility of positive network effects to build a sustainable protocol. It also achieves the goal of accruing value (reflected in the token’s price) as the network grows. However, this comes at the cost of market pressures, governance complexity, and the regulatory uncertainty that surrounds a token-centric model. These last few factors can greatly vary based on the project’s jurisdiction, design, and other variables.

Learnings from the economies of L1s and other considerations

It’s worth pointing out that products aimed at developers can provide infrastructure without necessarily imposing costs on them. Smart contract Layer-1 and Layer-2 blockchains shine as examples of this. For the purpose of this article, let’s consider them separate architectures to “token-centric” models, as blockchains might retain desirable features (like higher potential for decentralization), but sacrifice adaptability and flexibility.

While the primary goal of smart contract blockchains is to onboard developers to build dApps that leverage their networks, these blockchains typically sustain themselves via protocol (gas) fees to the users of these applications, not developers –sometimes also adding burning mechanisms to appreciate the value of their tokens in the long run. These networks, besides the mentioned value accrual effect, also have the potential upside of enabling further options for their users, such as decentralized governance and additional token utilities.

Some projects innovating in the spheres of privacy and scalability without acting as L1/L2 solutions might still use their tokens as “gas” units. Examples of this can be found in projects deploying zkEVMs, L2s, or cross-chain solutions for their own use, like Immutable X and, as we’ll see below, Particle.

Another key consideration when looking into Web3-native models is that, depending on the project’s end goal, the common practice of charging users in fiat currency could be considered to be against Web3’s values, or simply impractical. Applied correctly, crypto payments might be able to better support microtransactions, creating more flexible and agile structures. 

As we present Particle Network’s revamped economy, the following chart summarizes the insights from our analysis:

Particle Network’s shift towards a token-centric economy

In light of the analysis above, it’s possible to distinguish a variety of opportunities in adopting each model’s strongest points. In our view, while there are a couple of areas in which other models might be superior (and valuable takeaways can be extracted from them), token-centric frameworks shine as the best by far, empowering the following:

• Value accrual via network effects: As more participants engage with the network, its value grows, which is reflected in the token's performance, attracting more users and delivering value to key stakeholders.
• Incentives alignment: Token-centricity takes different types of participants and incentivizes them to join the network. If incentives are properly designed, this helps bootstrap the network’s growth and create additional value for it, igniting a virtuous cycle. 
• Token utility: The ecosystem's native token can serve multiple purposes, from facilitating transactions and incentivizing services to granting governance rights. This utility, designed correctly, ensures activity and participation. In Particle Network's case, the primary use case for the native token, as you'll see below, is to facilitate cross-chain transactions.
• Meritocratic participation and decentralization: Properly implemented token-centric models can support a permissionless environment where anyone can join, contribute, and benefit based on their participation level. This openness is crucial for network growth and diversity.

Why a token-centric economy is the best fit for Particle’s B2B2C framework

Importantly, all the strongest points of the revenue models above are adaptable to Particle’s B2B2C approach. In fact, this approach allows Particle to be extremely flexible with its economic model. Where other infrastructure providers might struggle to function under a token-centric model, Particle can afford to take inspiration from successful models and adapt them to its own token-centric implementation.

Besides the above, Particle is also uniquely positioned to adopt a token-centric economy for the above reasons:

1. Strengthening the ties between Particle and its ecosystem partners

Within its B2B2C model, Particle’s customers play an active role in growing the network. Both sides have strong incentives to support each other’s growth: While dApps benefit from more users having access to Particle  (resulting in growth for their apps and additional utility for the network), Particle has a vested interest in their success onboarding and retaining users, pushing us to innovate and create superior experiences. Therefore, it makes sense for Particle to adopt a system that reduces pressure for developers and aligns economic incentives.

With the debut of its v2 and the multiple advanced features surrounding it, Particle takes inspiration from L1s and L2s and removes charges to developers. Builders will be able to use Particle to create their dApps for free. Meanwhile, Particle’s token will be used to pay and remove UX friction for certain activities, such as cross-chain transactions. With this, Particle creates a model that can attract more developers and grow its dApp ecosystem while creating an undeniable utility for end-users, driving accelerated growth.

2. Setting a foundation for Particle’s v2 product suite

Particle’s v2 launch will be accompanied by the release of functionalities like Omnichain Account Abstraction and confidential user authentications supported by the Particle Chain. Both additions will supercharge the features 15 million Particle Network users rely on, and can only come to full fruition via an integrated, token-centric framework. As such, this shift is not only a strategic choice but a foundational adaptation setting the stage for the project’s evolution.

The Particle Network token: Utility and benefits

As more dApps integrate Particle Network, this should create a positive effect that increases its demand while the utility for end-users also grows proportionally.

One of the Particle Token’s immediate utilities is for it to serve as a unified gas token, facilitating the execution of transactions in L1 and L2 blockchains, as well as across them. This will remove the need for users to own multiple gas tokens (such as MATIC or ETH) to interact with the multi-chain ecosystem, reducing friction and enabling true interoperability. 

In the context of a multi-chain ecosystem and cross-chain transactions, having a single token (as opposed to 10+) work as a unified gas unit greatly reduces users’ economic and cognitive load. Furthermore, Account Abstraction applications within the Particle ecosystem can also make it easier for users to pay for gas, or not pay for it at all, depending on individual configurations.

We will continue to release information on our token’s utility. In the coming weeks, we will also present a full deep-dive into its use cases in an upcoming article. Post-launch use cases for the token might also include the ability to incentivize end users through partnered dApps, allowing for special activations within the ecosystem to bootstrap activity and adoption.

In summary

We have made the decision to shift from a B2B revenue model to a token-centric economy. Instead of charging developers per monthly users, Particle will adopt an approach that is more suited to the accrual of network effects, making our products free for developers and teams. Within this new model, the Particle Network token will serve both as a value accrual and a unified gas unit, unleashing Particle v2’s capabilities. This change benefits not only Particle Network, but also everyone relying on its services.

Our ultimate goals are to keep accelerating the adoption of Web3 and serve developers in the best way possible. Evolving into a token-centric economy also opens the door for Particle to increasingly decentralize our operating structure, with advanced features and potential rewards for users.

Particle’s upcoming v2 will feature an Intent Fusion Protocol, zkWaaS (zero-knowledge wallet-as-a-service), Omnichain Account Abstraction support, and several more features to be announced. Our token-centric economic model will serve as the platform upon which all stakeholders, including us, will find incentives to jointly create a better, more coordinated, innovative environment.

About Particle Network

Particle Network powers chain abstraction, addressing Web3's fragmentation of users and liquidity. This is enabled by Particle's Universal Accounts, which give users a unified account and balance across all chains.

Website | Docs | Discord | Twitter