2026-05-03

How Do PiRC1 Compliant Projects Pass Review? Entry Requirements for an Ecosystem Project

The most fundamental rule of PiRC1 is simple: **No live application, no token issuance qualification.** But this statement hides many questions: How is a "live application" defined? Who conducts the review? What is the review process? What restrictions apply after approval? This article breaks down these questions one by one. --- ## Entry Requirement One: Must Have a Functioning Application This is the most fundamental difference between PiRC1 and most cryptocurrency token standards. Pi co-founder Chengdiao Fan emphasizes that the purpose of tokens is not "for the tokens themselves," but to accelerate user acquisition, enhance engagement, and facilitate service delivery. This "product-first" principle aims to prevent shell issuances that prioritize fundraising over functionality. In other words, you must provide an application that users can actually operate and use to be eligible to apply for token issuance. This application doesn't need to be a finished product, but it must at least have a usable product prototype – otherwise, no matter how beautifully specifications and visions are written, they will always remain empty talk. To be honest, there are currently no clear guidelines on what constitutes a "truly usable app." Establishing criteria for "real use cases" or "actual needs" is inherently complex, requiring a robust evaluation framework, and the transparency of these decisions is crucial for maintaining trust among developers and users. We can only wait for the core team to release more details. --- ## Entry Requirement Two: KYC-Verified Developer Identity Pi's KYC verification network adds an extra layer of accountability to the entire system, where both developers and users operate under verified identities, rather than anonymously. This design has a direct effect: projects issuing tokens on Pi can be held accountable, at least at the identity level. This is completely different from the numerous anonymously operated projects in the Ethereum ecosystem. This is similar to corporate regulations in the real world; at least you can know who is responsible for the application. However, it's uncertain whether this approach meets the expectations of many individual developers – many developers prefer their information not to be easily disclosed, which could potentially affect their willingness to participate. This is also one of the issues with PiRC1's strict requirements, which might limit smaller teams who must bear development costs themselves before seeking funding. --- ## Review Process: Who Decides if a Project Can Issue Tokens? Here's a question many people are still unclear about: Is PiRC1's review centralized or decentralized? Pi Launchpad is currently released on the testnet because it introduces many new concepts unfamiliar to Pioneers and uses mechanisms different from typical Web3 token issuances. It's launched on the testnet first to allow the community to familiarize themselves with the process before the mainnet officially goes live. However, it is believed that the testnet is merely for miners to trial the process, and the number of projects on the mainnet at launch remains unknown. There is currently no updated information regarding the exact review process, nor is it clear what documents need to be prepared. Who decides if an application is eligible? How are disputes resolved? What mechanisms ensure fairness and consistency? These questions are crucial for PiRC1's long-term credibility. The core team's disclosure of information in this area is not yet transparent enough. --- ## Four-Stage Process: The Complete Path from Application to Token Issuance for a Project PiRC1 divides token issuance into four core pillars, forming a complete token issuance cycle. **Step One: Application and Preliminary Review** Developers, businesses, and Pioneers can submit feedback and applications via GitHub or Google Form to participate in the PiRC1 framework's review process. Applications must demonstrate an existing, functioning application and a clear token utility – specifically, what problem the token solves within the application and how it integrates into product features (e.g., payments, rewards, governance, etc.). The specific criteria for preliminary review are not yet fully public, making this one of the least transparent aspects of PiRC1. **Step Two: Staking Collateral** After a project passes preliminary review, it must stake Pi as a financial commitment. This staked amount is locked during the project's operation and may be forfeited in case of violations. The method for calculating the staking amount has no official explanation yet; it is speculated to be related to project scale or token issuance volume. **Step Three: Escrow Period** The Pi committed by miners enters an escrow wallet and cannot be accessed until predetermined conditions are met. From a Pioneer's perspective, the Launchpad provides a transparent and merit-based channel for token acquisition. Pioneers can choose to participate in different projects, acquire tokens through the issuance mechanism, and then use these tokens within the product. The exact length of the escrow period is not yet clearly defined. **Step Four: Liquidity Establishment and Market Launch** Once all conditions are met, the liquidity pool is officially established. The Pi obtained from token issuance by the project is not taken by the issuing project but flows into a liquidity pool paired with the ecosystem token, establishing a healthy liquidity foundation from the outset. Tokens then begin trading on Pi DEX. --- ## After Approval: What Other Restrictions Apply to Projects? Token issuance is not the end; PiRC1 still imposes ongoing requirements on launched projects. PiRC1 introduces a model where token issuance and ecosystem rewards are closely tied to verified activity. This means mere participation is not enough; it must be connected to real applications or functional use cases within the network. In plain terms, project teams cannot just issue tokens and then abandon them. The Engage-to-Earn algorithm continuously monitors user activity within ecosystem applications. If your application doesn't have real users, the priority of token distribution will decrease, and its visibility within the ecosystem will also be reduced. This incentivizes projects that are serious about long-term development – you must continuously optimize your product and maintain user activity. However, for developers with few users in the early stages of a project, this is also significant pressure: you might pass the review and establish a liquidity pool, but if early user growth is too slow, you will be at a disadvantage in the competition. --- ## Current Gray Areas: What Questions Remain Unanswered? To be honest, several aspects of PiRC1 are currently unclear, and these are issues OrbitWatch continues to track: **What is the minimum threshold for a 'functioning application'?** How many active users are needed? How much functional completeness? Currently, there's only the vague statement 'has a working application,' with no specific quantitative standards. The community has suggested that evaluation criteria must be transparent and consistent to prevent questions about the screening process. **How long does the review take?** How much time is needed from application submission to official launch? There is no official explanation for this question. For developers, not knowing the waiting time makes product planning very difficult. **What happens if a project fails or stops maintenance?** If an approved project later ceases maintenance or even collapses, can the miners' Pi locked in the liquidity pool be retrieved? This is the most direct risk for miners, and there is currently no clear mechanism explaining it. **Will review standards change over time?** PiRC1 itself is still evolving and is currently in a Request for Comment (RFC) state. Review standards may be adjusted in the future. Will different rules apply to projects approved earlier versus those applying later? --- ## OrbitWatch's Tracking Plan We will continue to track the following indicators to observe the actual implementation of the PiRC1 compliance review mechanism: * Progress of community feedback on GitHub and Google Form, especially discussions regarding the transparency of review standards. * The types and applications of the first batch of projects approved after Pi Launchpad officially opens on the mainnet. * The actual waiting times for review and the community's reaction to fairness. * Whether the official team releases more complete application document requirements and review processes. These gray areas do not mean PiRC1 is a bad design, but they are issues that anyone wishing to participate in or develop on the Pi ecosystem needs to continuously monitor. OrbitWatch will provide updates as soon as new information becomes available. --- **Further Reading** - [Full Analysis of PiRC1](/en/protocol/pirc1) - [Detailed Explanation of PiRC1 Liquidity Pool Mechanism](/en/protocol/pirc1/pirc1-liquidity-pool) - [PiRC1 vs ERC-20: How Does Pi's Token Standard Compare to Ethereum's?](/en/updates/2026-05-01) --- *Data sources: Pi Network Official Blog (minepi.com/blog), PiRC GitHub, crypto.news, coinfomania, hokanews. All analysis does not constitute investment advice.* *OrbitWatch is an independent Pi Network ecosystem observatory and is not affiliated with the official Pi Network.*

• •PiRC1 mandates a "product-first" approach, requiring a functioning application and KYC-verified developer identity for token issuance, a key differentiator from other crypto standards.
• •The token issuance process is a four-stage journey: application, staking Pi collateral, an escrow period, and liquidity establishment, with ongoing requirements for project engagement and user activity.