Parachain use case for pallet-people/PoP and questions on third-party consumption timeline

Hi all,

I’m building an open-source Substrate/Polkadot parachain template for cooperative and DAO governance infrastructure — essentially a “DAO incubator” chain that gives each incubated organisation its own governance instance, with three voting modes depending on decision type: token-weighted (conviction voting), reputation-weighted, and one-person-one-vote for constitutional-level decisions. Built on the OpenZeppelin generic-template, targeting Kusama first. Still in devnet/prototype stage as a solo developer.

One architectural detail that may be relevant to this community specifically: it’s likely each incubated DAO will end up as its own parachain rather than sharing a single chain, which means the platform’s aggregate parachain-slot demand scales with adoption — worth flagging since I know downstream demand signal is useful context for this work.

For the 1p1v track, Sybil-resistance matters a lot in the platform’s early bootstrap phase specifically — with only a handful of participants in the first cohorts, a small number of duplicate accounts could otherwise swing a constitutional referendum in a damaging way. I’ve been reading up on the Individuality / Proof-of-Personhood work (DIM1/DIM2) with real interest as a potential fit here, and noticed pallet_dummy_dim in polkadot-sdk as the current placeholder interface.

A few questions, as a genuine downstream consumer trying to plan around this:

  1. Is third-party parachain consumption of PoP results (e.g. via XCM-based origins, as mentioned in some of the docs) actually on the roadmap, or is the current focus solely on Polkadot-relay/People-Chain-native use cases for now?
  2. Roughly what stage is that at, and is there a better channel than this thread to follow as the interface stabilises — a tracking issue, mailing list, or similar?
  3. Would input from a concrete downstream use case like this be useful at this stage, or is it premature given where DIM1/DIM2 currently stand?

Happy to share more detail on the project if it’s useful context. Appreciate any pointers.

Update: spent some time actually running this end-to-end on a local devnet since my last post, rather than just planning it. Successfully completed a full registerWithFee flow (ring VRF proof + consumer registration), finalized on-chain.

Along the way I hit a couple of things worth flagging for anyone else trying this: polkadot.js’s standard Submit Transaction UI can’t currently submit extrinsics to this chain (it doesn’t yet support the v5 “general transaction” format this runtime uses), and there’s an undocumented minimum-digit requirement on lite usernames. Opened an issue with the details: Github bug report

Happy to share the script I ended up writing if it’d be useful for the examples folder.