From 51ffc10caf8c07bf118ec8eaa77826d902a67598 Mon Sep 17 00:00:00 2001 From: Mr-X <118984549+EslaM-X@users.noreply.github.com> Date: Sun, 22 Feb 2026 19:28:47 +0200 Subject: [PATCH 1/8] feat(pirc1): propose Programmable Engagement Proofs (PEP) for fair allocation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Summary: Introduces Section 2.3 (Programmable Engagement Proofs) to the Core Design of PiRC1. Rationale: As an active Full-Stack Developer in the Pi ecosystem (AppDev @Map-of-Pi), I identified a potential gap in the current "Engagement" measurement logic. While Section 2.1 mentions measuring user activity, it lacks a standardized technical framework to prevent manipulation. Key Improvements: - Proposed a Verifiable Engagement Layer to ensure that PiPower is backed by authentic dApp interaction. - Introduced the concept of Signed Activity Payloads to mitigate Sybil Attacks and bot farming during the Participation Window. - Focused on bridging the gap between MERN-stack application logic and the Launchpad’s allocation mechanism. This addition aims to provide developers with a clear, secure standard for reporting user milestones, ensuring a fairer distribution for genuine Pioneers. --- PiRC1/2-core-design.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/PiRC1/2-core-design.md b/PiRC1/2-core-design.md index e95ddc1..6467c75 100644 --- a/PiRC1/2-core-design.md +++ b/PiRC1/2-core-design.md @@ -46,4 +46,14 @@ flowchart LR Pioneers -->|"Commit Pi (pay)"| Escrow ``` -Next: [`3-Participation`](3-participation.md) \ No newline at end of file +### 2.3 Proposed Extension: Programmable Engagement Proofs (PEP) +To standardize the **Engagement** measurement described in Section 2.1, I propose adding a technical layer for **Programmable Engagement Proofs**. + +As a Full-Stack developer building ecosystem solutions (e.g., Map-of-Pi), I suggest that the "Participation Window" should include a standardized API or SDK hook that allows projects to submit **Signed Activity Proofs**. This addresses several critical needs: + +* **Standardized Reporting:** dApps can report milestones (onboarding, feature use) in a unified format that the Launchpad can verify. +* **Sybil Protection:** By requiring cryptographic signatures from the App’s backend for each engagement milestone, we prevent automated bot manipulation of the engagement-ranked order. +* **Developer Experience:** A clear interface for MERN/Full-stack developers to "hook" their app logic into the PiPower calculation, ensuring that real utility translates directly to fair token allocation. + + +Next: [`3-Participation`](3-participation.md) From ca42ad220ed1b359c41f5d83e5d9935d93edb1f9 Mon Sep 17 00:00:00 2001 From: Mr-X <118984549+EslaM-X@users.noreply.github.com> Date: Sun, 22 Feb 2026 19:30:36 +0200 Subject: [PATCH 2/8] docs(pirc1): propose Weighted Engagement Framework (WEF) for section 3.3 I am proposing an extension to the Engagement Tracking logic (Section 3.2). Current logic relies on a general "Engagement Score" which is susceptible to automated farming. By introducing a "Weighted Engagement Framework," we allow developers to define high-value milestones (Proof of Utility). This ensures that the price-ranking mechanism favors genuine users who contribute to the app's growth, rather than bots. --- PiRC1/3-participation.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/PiRC1/3-participation.md b/PiRC1/3-participation.md index 9a9118a..273ebf4 100644 --- a/PiRC1/3-participation.md +++ b/PiRC1/3-participation.md @@ -19,4 +19,17 @@ $$ - At window close, participants are ranked highest-to-lowest based on the Engagement Score; this rank may have an effect on the effective price of the token in the Allocation Period. -Next: **4-Allocation [`Design 1`](<4-allocation/4-allocation design 1.md>) [`Design 2`](<4-allocation/4-allocation design 2.md>)** \ No newline at end of file +### 3.3 Proposed Refinement: Weighted Engagement Framework (WEF) +To ensure the **Engagement Score** mentioned in Section 3.2 reflects true utility, I propose a **Weighted Engagement Framework**. + +As a Full-Stack developer, I suggest that the Engagement Score should be a composite of: +1. **Proof of Activity (PoA):** Basic interactions (Logins, navigation). +2. **Proof of Utility (PoU):** High-value actions (e.g., contributing data, completing transactions, or reaching app-specific milestones). +3. **Consistency Factor:** Rewarding users who engage throughout the entire window, rather than burst activity at the end. + +**Technical Implementation:** +Projects should provide a `Manifest` of weighted actions to the Launchpad. This prevents "Engagement Farming" and ensures that the "Engagement-ranked order" truly rewards the most valuable users of the ecosystem. + + + +Next: **4-Allocation [`Design 1`](<4-allocation/4-allocation design 1.md>) [`Design 2`](<4-allocation/4-allocation design 2.md>)** From 5fe5c771b3ab738c82442cb4ad954a02bc6a93b9 Mon Sep 17 00:00:00 2001 From: Mr-X <118984549+EslaM-X@users.noreply.github.com> Date: Sun, 22 Feb 2026 19:31:39 +0200 Subject: [PATCH 3/8] Update ReadMe.md --- PiRC1/ReadMe.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/PiRC1/ReadMe.md b/PiRC1/ReadMe.md index 1339fa1..3514a93 100644 --- a/PiRC1/ReadMe.md +++ b/PiRC1/ReadMe.md @@ -19,3 +19,7 @@ Pi will review and consider community input from GitHub and high-level feedback - **Design 2** - [`4-allocation design 2`](<4-allocation/4-allocation design 2.md>) - [`5-tge-state design 2`](<5-tge-state/5-tge-state design 2.md>) + +--- +### 💡 Community Technical Contributions +* **Standardizing Engagement:** Proposals for **Programmable Engagement Proofs (PEP)** and **Weighted Engagement Frameworks (WEF)** have been drafted in Sections 2 and 3 to support developers in building secure, bot-resistant ecosystem applications. From 8bece08918acc98e526efbba4c4e82e1f563a26b Mon Sep 17 00:00:00 2001 From: Mr-X <118984549+EslaM-X@users.noreply.github.com> Date: Sun, 22 Feb 2026 19:33:23 +0200 Subject: [PATCH 4/8] feat(pirc1): suggest Dynamic Tier Transition (DTT) for smoother allocation I propose a technical refinement to the Step-Function discount model in Design 1. By introducing a "Dynamic Tier Transition," we can provide a more granular reward system that encourages continuous engagement rather than reaching a fixed percentile. This proposal also suggests a standardized SDK function to help developers integrate real-time price calculations into their Pi Apps. --- PiRC1/4-allocation/4-allocation design 1.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/PiRC1/4-allocation/4-allocation design 1.md b/PiRC1/4-allocation/4-allocation design 1.md index f5620c2..617fb20 100644 --- a/PiRC1/4-allocation/4-allocation design 1.md +++ b/PiRC1/4-allocation/4-allocation design 1.md @@ -151,4 +151,16 @@ xychart-beta - Starting LP spot price is $p_{list} = \frac{C}{T}$ - Highly engaged participants pay $0.909p_{list}$. Medimum engaged participants pay $0.952p_{list}$. Least engaged participants pay $p_{list}$ + +### 4.2 Proposed Technical Improvement: Dynamic Tier Transition (DTT) +The current tier model uses a "Step Function" for discounts (10%, 5%, 0%). While effective, it can create friction at the boundaries of each 1/3 percentile. + +**Developer Proposal:** +To ensure a better User Experience (UX) and prevent "Tier-farming" at the edges, I propose implementing a **Sigmoid-based Smoothing Algorithm** for the $t_i^{discount}$ calculation. + +**Benefits for dApp Developers:** +* **Granular Rewards:** Instead of broad tiers, developers can offer micro-incentives for every incremental increase in the Engagement Score. +* **API Standardization:** Providing a standard `getEffectivePrice(engagementScore)` function within the Pi SDK to help developers display real-time price benefits to users within their MERN apps. + + Next: [`5-tge-state`](<../5-tge-state/5-tge-state design 1.md>) From 1d799cd28a51b5ceceeff22d6aa123c91fee6d35 Mon Sep 17 00:00:00 2001 From: Mr-X <118984549+EslaM-X@users.noreply.github.com> Date: Sun, 22 Feb 2026 19:34:54 +0200 Subject: [PATCH 5/8] feat(pirc1): propose Dynamic Unlock Oracle (DUO) for Design 2 I am proposing a technical enhancement to the lockup mechanism in Design 2. By introducing a "Dynamic Unlock Oracle," we can transform static lockups into active engagement incentives. This allows dApp developers to reward long-term users with accelerated token utility based on real-world app interactions, aligning with the vision of creating real product innovations on Pi Network. --- PiRC1/4-allocation/4-allocation design 2.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/PiRC1/4-allocation/4-allocation design 2.md b/PiRC1/4-allocation/4-allocation design 2.md index f28251f..5920531 100644 --- a/PiRC1/4-allocation/4-allocation design 2.md +++ b/PiRC1/4-allocation/4-allocation design 2.md @@ -136,4 +136,15 @@ xychart-beta ``` -Next: [`5-tge-state`](../5-tge-state/5-tge-state%20design%202.md) \ No newline at end of file +### 4.2 Proposed Technical Extension: Dynamic Unlock Oracle (DUO) +The current design (Section 4.1) links lockup periods to the size of the discount. To further incentivize the ecosystem, I propose a **Dynamic Unlock Oracle**. + +**The Concept:** +Instead of a static time-based lockup, developers can implement a "Activity-Based Release" mechanism. For every verified milestone a user achieves in the dApp (e.g., in Map-of-Pi), a portion of their locked discounted tokens is released earlier. + +**Technical Benefit for MERN Developers:** +* **Retention Logic:** This gives developers a powerful tool to keep users engaged post-TGE. +* **Smart Contract Integration:** Using signed messages from the App's backend to trigger partial token releases from the Escrow-governed lockup. + + +Next: [`5-tge-state`](../5-tge-state/5-tge-state%20design%202.md) From 8a6993d5a0534ef636a386c30f49c7e1008edafb Mon Sep 17 00:00:00 2001 From: Mr-X <118984549+EslaM-X@users.noreply.github.com> Date: Sun, 22 Feb 2026 19:36:42 +0200 Subject: [PATCH 6/8] docs(pirc1): add Transparency API proposal for TGE stability I am proposing an addition to Section 5 regarding the post-TGE state. To leverage the mathematical security of the "Price Floor" and "Immutable Liquidity," we need a standardized way for developers to surface these metrics to users. By providing a Transparency API, we empower Full-Stack developers to build more trustworthy dApps that showcase the inherent security of the Pi Launchpad design. --- PiRC1/5-tge-state/5-tge-state design 1.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/PiRC1/5-tge-state/5-tge-state design 1.md b/PiRC1/5-tge-state/5-tge-state design 1.md index 6df5e57..6ccf37a 100644 --- a/PiRC1/5-tge-state/5-tge-state design 1.md +++ b/PiRC1/5-tge-state/5-tge-state design 1.md @@ -55,4 +55,17 @@ In the base case with no rewards ($T_{engage}=0$), this gives $p_{floor}=0.25\,p **Intuitively:** even to the extent of “everyone swaps every token of theirs back to the pool”, the pool cannot be drained because the Escrow Wallet that added the liqludiity initially is locked and cannot withdraw from the pool; the pool still retains nearly half of the entire initial participant commitment ($0.488C$ Pi) and all of the tokens in circulation ($2.05T$ tokens), which mathematically prevents the price to drop further than 23.8% of $p_{list}$ in this construct. + +### 5.1 Proposed Developer Utility: Transparency API & Real-time Floor Monitoring +To build trust within the ecosystem, it is crucial that Pioneers can verify the "Liquidity Lock" and the "Price Floor" directly within project apps. + +**Developer Proposal:** +I propose that the Pi SDK provides a standardized method (e.g., `getPoolStabilityMetrics()`) that allows dApps (like Map-of-Pi) to fetch and display: +1. **Escrow Lock Status:** A verifiable on-chain proof that the Escrow Wallet's signing authority is revoked. +2. **Dynamic p_floor Calculation:** Real-time calculation of the theoretical lower bound based on current circulating supply. + +**Impact:** +Integrating these metrics into the MERN stack frontend will enhance user confidence and distinguish Pi Network projects from traditional, high-risk Web3 launches. + + Next: [`Design 2`](<../4-allocation/4-allocation design 2.md>) From 1c1aca3352392e45a015f3423eeadcd82730d0a4 Mon Sep 17 00:00:00 2001 From: Mr-X <118984549+EslaM-X@users.noreply.github.com> Date: Sun, 22 Feb 2026 19:38:42 +0200 Subject: [PATCH 7/8] docs(pirc1): propose Liquidity Analytics Interface for Design 2 stability MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Proposed Enhancement for Section 5 (Design 2): As a Full-Stack developer, I recognize that the complexity of Design 2 (automated swaps and the 0.16 p_list floor) requires high levels of on-chain transparency to maintain Pioneer trust. I have proposed the addition of a "Post-TGE Liquidity Analytics Interface." This extension suggests providing standardized API hooks or SDK methods that allow developers to: 1. Programmatically verify the permanent locking of the Escrow Wallet’s signing authority. 2. Monitor the Constant-Product Invariant (k) to provide real-time assurance of the price floor stability. By surfacing these mathematical safeguards through a Transparency Dashboard, we enable dApp developers to provide verifiable proof of security to their users, aligning with Pi Network’s goal of creating robust, real-world Web3 products. --- PiRC1/5-tge-state/5-tge-state design 2.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/PiRC1/5-tge-state/5-tge-state design 2.md b/PiRC1/5-tge-state/5-tge-state design 2.md index 9cb46f9..e648b39 100644 --- a/PiRC1/5-tge-state/5-tge-state design 2.md +++ b/PiRC1/5-tge-state/5-tge-state design 2.md @@ -51,3 +51,15 @@ $$ Intuitively: even to the extent of “everyone sells everything”, the pool cannot be drained because the Escrow Wallet that added the liqludiity initially is locked and cannot withdraw from the pool; the pool still retains $0.4C$ Pi and $T$ tokens, which prevents the price to drop further in this construct. **Intuitively:** even to the extent of “everyone swaps every token of theirs back to the pool”, the pool cannot be drained because the Escrow Wallet that added the liqludiity initially is locked and cannot withdraw from the pool; the pool still retains nearly half of the entire initial participant commitment ($0.4C$ Pi) and all of the tokens in circulation ($T$ tokens), which mathematically prevents the price to drop further than 16% of $p_{list}$ in this construct. + + +### 5.1 Proposed Extension: Post-TGE Liquidity Analytics Interface +Design 2 relies heavily on automated swaps and constant-product invariants. To maintain the highest level of community trust, developers should be able to integrate real-time liquidity health metrics. + +**Developer Proposal:** +I propose the inclusion of a **Standardized Liquidity Event Log** within the Pi Block Explorer or via an SDK hook. This allows MERN-stack developers to: +1. **Verify the "signing authority 0" status:** Proving that the Escrow Wallet is permanently locked. +2. **Track the $x \cdot y = k$ invariant:** Monitoring the pool's health to ensure that the $p_{floor}$ remains mathematically intact. + +**Value Addition:** +By providing these hooks, Pi Network empowers developers to create "Transparency Dashboards" within their apps (like Map-of-Pi), providing Pioneers with real-time confidence in the ecosystem's mathematical floor. From 74c1dd787d822b110b90729c75e0512e5998d72a Mon Sep 17 00:00:00 2001 From: Mr-X <118984549+EslaM-X@users.noreply.github.com> Date: Sun, 22 Feb 2026 19:40:05 +0200 Subject: [PATCH 8/8] docs(pirc1): enhance vision with Utility-Driven Growth perspective MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Proposed refinement to the Vision section of PiRC1: As a developer building within the Pi ecosystem, I believe the "Product-First" approach is our greatest strength. I have proposed adding a focus on "Verified Utility Milestones" to ensure that token utility is deeply integrated into the dApp logic from day one. This addition emphasizes the transition from speculative launches to utility-driven ecosystems, providing a clearer roadmap for MERN-stack and Full-stack developers to align their products with Pi Network’s long-term goals. --- PiRC1/1-vision.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/PiRC1/1-vision.md b/PiRC1/1-vision.md index d453865..76f5d25 100644 --- a/PiRC1/1-vision.md +++ b/PiRC1/1-vision.md @@ -20,4 +20,14 @@ Pi Launchpad aims to provide: - **Unlock schedules** that align project and community interests. - **On-chain transparency** of the launch process ensured by immutable smart contracts. -Next: [`2-Core-Design`](2-core-design.md) \ No newline at end of file + ### 1.1 Developer Perspective: Scaling Utility and User Trust +To further realize the "Product-First" vision, I propose that the Launchpad should also focus on **Standardized Utility Frameworks**. + +As a Full-Stack developer (AppDev @Map-of-Pi), I suggest that the vision include: +- **Verified Utility Milestones:** Ensuring that "Immediate Utility" is not just a promise, but a series of verifiable on-chain actions within the app. +- **Developer-Community Synergy:** Promoting an environment where developers use the Launchpad not just for funding, but as a technical validator of their product’s ecosystem integration. + +By emphasizing **utility-driven growth** over speculative trading, we ensure that the Pi Network ecosystem remains the home of the most robust and practical Web3 applications. + + +Next: [`2-Core-Design`](2-core-design.md)