research how to find a persons paraId (best to find it in polkadot js) - ONLY READ CODE

[poppyseedDev]

When a person purchases a paraId, is this written somewhere in the state, or is there some event that happens, that we can track to mark that change, and if so which event?

Write implementation details for other developers or yourself, this issue requires only searching in substrate.
Try to be as through as possible in your desciption.

on polkadot js this functionality looks like:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/parachains/parathreads

Question is how can we get these two values of individuals paraId.

---

An example issue resolve could look like this:

To implement it you should interact with the following functions:

It works in the following way:

• person should buy the core, then call this extrinsic
• to visualize do ....

If you want to take this issue on, comment underneath.

[poppyseedDev]

@phillux

[poppyseedDev]

I think this is as easy as checking events when you do registrar.reserve on the relay chain, but creating an indexer solely for this is unwanted

[jynbil1]

✋ I looked through the runtime storage and how Polkadot.js Apps implements this screen. The short answer is: there is no direct account -> paraId[] storage map. The reliable source is registrar.paras, which is keyed by ParaId and stores ParaInfo { manager, deposit, locked }. To find a person's ParaIds, iterate that map and filter entries where paraInfo.manager equals the account.

Implementation details:

1. Query all registered/reserved ParaIds:

const entries = await api.query.registrar.paras.entries()

const ownedParaIds = entries
  .map(([{ args: [paraId] }, optInfo]) => {
    if (optInfo.isNone) return null
    const paraInfo = optInfo.unwrap()
    return {
      paraId,
      manager: paraInfo.manager.toString(),
      deposit: paraInfo.deposit,
      locked: paraInfo.locked,
    }
  })
  .filter((entry) => entry && entry.manager === accountAddress)

2. To display status for those IDs, query:

api.query.paras.paraLifecycles(paraId)
api.query.paras.currentCodeHash(paraId)
api.query.paras.heads(paraId)
api.query.paras.upcomingParasGenesis(paraId)

paraLifecycles tells you whether it is a parathread/parachain-style lifecycle entry. currentCodeHash tells you whether the ID already has code. heads / upcomingParasGenesis give the currently active or pending head data.

3. For event-driven updates, subscribe to registrar events:

api.events.registrar.Reserved   // { para_id, who }
api.events.registrar.Registered // { para_id, manager }
api.events.registrar.Deregistered
api.events.registrar.Swapped

On Reserved, add para_id under who. On Registered, add/update para_id under manager. On Deregistered, remove it. On Swapped, refresh both affected IDs because any local account -> paraId cache can become stale.

This matches the runtime source: polkadot/runtime/common/src/paras_registrar/mod.rs defines ParaInfo { manager, deposit, locked }, Paras<T> as the ParaId -> ParaInfo storage map, and the Registered, Reserved, Deregistered, and Swapped events.

It also matches Polkadot.js Apps:

• packages/page-parachains/src/useOwnedIds.ts reads api.query.registrar.paras, extracts manager, filters against local accounts, and then checks api.query.paras.currentCodeHash.multi.
• packages/page-parachains/src/Parathreads/useThreadInfo.ts combines paras.heads, paras.upcomingParasGenesis, paras.paraLifecycles, and registrar.paras.
• packages/page-parachains/src/Overview/useParaInfo.ts also uses registrar.paras as the source for the ParaInfo shown in the parachains overview.

For Lastic, I would implement this as a small hook, probably useOwnedParaIds, and reuse it in the assignment UI:

type OwnedParaId = {
  paraId: number
  manager: string
  hasCode: boolean
  lifecycle: string | null
  name?: string
}

Then in AssignModal, replace the free-only "To para ID" number field with a searchable select:

• default section: "Your ParaIds", from registrar.paras filtered by the active account;
• display label: paraId - known name, using network_list[network].paraId[paraId]?.name when available;
• secondary text: lifecycle / has code / reserved or registered status;
• selecting an item sets the existing task value to that paraId;
• keep manual numeric entry as a fallback for unknown IDs.

That would also unblock #172: the modal can recommend the user's own ParaIds first, and the My Cores page can display assigned tasks as Task: 2000 (Karura) instead of only a bare number when the name is known.