You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Modding this template should be: fork → change something → redeploy. In practice the hard part isn't the code — it's a handful of invisible, irreversible facts that today only surface after a phone-signed, funded, ownership-binding deploy:
Who am I? The signer identity is never written to the repo or shown anywhere. You don't know which account you are until a deploy fails.
Is my name claimable? The template ships a hardcoded contract name that's already owned; there's no way to check before signing.
Does my mod even work? The only way to run the app end-to-end is a real deploy, so you can't verify a change before the irreversible step.
These were all hit in a single real mod+deploy session. The worst one isn't documented anywhere:
The identity/ownership trap (the one that actually blocks you)
pg deploy fails with:
✖ CDM package "@…/leaderboard" is already owned by 0x35cdb…, but the selected
signer maps to 0xcf8a…. Update the Cargo.toml package value to a name you own,
or deploy with the owner account.
The error points at renaming. But renaming doesn't help: renaming to a brand-new random name (@rps-<6 hex>/leaderboard) returned the same owner 0x35cdb. So it was never a naming collision — ownership is bound to the signer, and the registry attributes the name to a key you're not currently signing with. The real cause: the owner 0x35cdb and the active signer 0xcf8a are different keys that both display as the same Playground username (whiterabbit). You can be "yourself" and still not be the owner. There's nothing in the tooling to tell you this.
What would make it smooth (prompts the template/CLI should surface)
In order of when they should fire — full writeup with the failure each prevents in MODDER-PROMPTS.md:
Show the signer identity at pg mod/setup — "you're signed in as <handle> (0x…); names you deploy are owned by this account."
Ownership preflight before signing — "claiming @X under 0x…: free / owned by you / owned by someone else" — and lead with the signer fix, not a rename when it's owned. (Needs a registry getOwner(name) — none exists today.)
Identity reconciliation — warn when the owning key ≠ the current signer key even though the display name matches; if you deployed before, sign with the same account.
Funding/allowance preflight with the exact gap + faucet links, instead of raw InvalidTxError {"Payment"} / AccountUnmapped.
Signing readiness — "open the Polkadot app and keep it foregrounded; N approvals incoming" (per-tx push has a short timeout; otherwise it hangs at step 1).
Don't pg logout to fix a hang — it can discard the session that owns your names and re-pair you as a different key.
CLI/SDK/registry, Parity-side (can't be PR'd from the template): registry getOwner(name), signer-first error wording + identity reconciliation, non-interactive deploy, session-key signing so the per-tx phone QR/timeout goes away. Detailed in PARITY-ISSUES.md.
One-line summary
Tell the modder who they are, give them a name nobody owns, let them verify offline, and confirm ownership + funding before a single signature.
Today none of these are prompted, so every one is discovered after an irreversible deploy. Surfacing them turns modding into: name:new → verify at ?mock → deploy once.
The problem
Modding this template should be: fork → change something → redeploy. In practice the hard part isn't the code — it's a handful of invisible, irreversible facts that today only surface after a phone-signed, funded, ownership-binding deploy:
These were all hit in a single real mod+deploy session. The worst one isn't documented anywhere:
The identity/ownership trap (the one that actually blocks you)
pg deployfails with:The error points at renaming. But renaming doesn't help: renaming to a brand-new random name (
@rps-<6 hex>/leaderboard) returned the same owner0x35cdb. So it was never a naming collision — ownership is bound to the signer, and the registry attributes the name to a key you're not currently signing with. The real cause: the owner0x35cdband the active signer0xcf8aare different keys that both display as the same Playground username (whiterabbit). You can be "yourself" and still not be the owner. There's nothing in the tooling to tell you this.What would make it smooth (prompts the template/CLI should surface)
In order of when they should fire — full writeup with the failure each prevents in MODDER-PROMPTS.md:
pg mod/setup — "you're signed in as<handle>(0x…); names you deploy are owned by this account."?mock) so a mod is verifiable with no chain/phone/deploy. → PR Add offline dev mode (?mock): run & verify a mod with no chain, phone, or deploy #12@Xunder0x…: free / owned by you / owned by someone else" — and lead with the signer fix, not a rename when it's owned. (Needs a registrygetOwner(name)— none exists today.)InvalidTxError {"Payment"}/AccountUnmapped.pg logoutto fix a hang — it can discard the session that owns your names and re-pair you as a different key.What's already submitted vs what needs Parity
?mock.getOwner(name), signer-first error wording + identity reconciliation, non-interactive deploy, session-key signing so the per-tx phone QR/timeout goes away. Detailed in PARITY-ISSUES.md.One-line summary
Today none of these are prompted, so every one is discovered after an irreversible deploy. Surfacing them turns modding into: name:new → verify at
?mock→ deploy once.