PiNetwork · EslaM-X · Feb 22, 2026 · Feb 22, 2026 · Feb 22, 2026 · Feb 22, 2026
diff --git 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)
+  ### 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)
diff --git 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)
+### 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)
diff --git 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>)**
+### 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>)**
diff --git 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>)
diff --git 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)
+### 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)
diff --git 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>)
diff --git 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.
diff --git 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.