Because PiRC is making economic guarantees (especially “committed Pi becomes liquidity”). A backend can enforce policy, but a contract can enforce invariants that are harder to break and easier to audit.
No. PiRC requires the critical value paths to be onchain:
- commitments custody,
- liquidity seeding,
- liquidity lock,
- and distribution rules.
Engagement scoring and UI can stay offchain (ideally with verifiable outputs).
Compute engagement tiers offchain, then publish a Merkle root onchain. Users claim with a proof. Anyone can recompute the tree from the underlying data and compare to the root.
In a PiRC-aligned contract design, no. The contract should not have a function that transfers committed Pi to the project. The committed Pi leaves escrow only through DEX liquidity seeding (and potentially refunds on cancellation).
A liquidity lock contract holds the LP position and does not expose a withdrawal path for the project.
- PiRC Design 1 listing/clearing price: (p_{list}=\frac{C}{T})
- Base allocation: (t_i^{base}=c_i\cdot\frac{T}{C})
- AMM constant product: (x\cdot y=k), spot price (p=\frac{x}{y})