Troubleshooting¶
Named entries for the failures developers hit most while building and deploying Polkadot Products. Each one states the cause and the resolution.
no allowance set for account¶
Cause: Allowances are granted per account. This error means the account that actually signed the request has no allowance — almost always because the allowance was granted to a different account than the one signing. Common ways this happens: you funded a dev key but signed with your phone account (or the reverse), or your Product derived its per-app account under a different productId than the one you granted the allowance under (for example, running from localhost, which derives under playground.dot, versus a <name>.dot.li URL, which derives under <name>.dot).
Resolution:
- Determine which account actually signs. A Product running inside a Host can read its product account address (SS58 and H160) through the
signerpackage; surface it in your dev UI. See Accounts and Signing. - Grant the allowance (or storage authorization) to that account. See Get TestNet Tokens.
- Keep the
productIdconsistent between where you request the allowance and where you sign, so the same account is used throughout.
The App Seems Frozen After an Action¶
Cause: Signing happens on your phone, and there is no push notification telling you the phone is waiting. After you trigger a signable action, the interface can look stuck while an approval prompt sits unopened in the Polkadot App.
Resolution: Open the Polkadot App and check for a pending approval. Approve or reject it there, and the flow continues. When building, show a non-blocking "check your phone" state after any signable action rather than a spinner that looks frozen. See Sign and Submit Transactions for designing around cross-device signing latency.
The Deploy Pauses for About a Minute¶
Cause: During playground deploy, there is a deliberate pause of about 60 seconds between reserving and finalizing your DotNS name. This is DotNS's commit-reveal window, which prevents someone from front-running your name.
Resolution: Wait. The deploy is not stuck. The next approval appears in the Polkadot App once the window elapses.
The Name Requires Proof of Personhood¶
Cause: Short and premium DotNS names are reserved for accounts with Proof of Personhood. A base name of 6 to 8 characters needs a personhood tier — Lite if it ends in a two-digit suffix, Full if it does not — and a base of 5 characters or fewer is reserved for governance.
Resolution: Choose a base name of 9 characters or more, which registers with no personhood check; add a two-digit suffix to drop a 6-to-8-character name from Full to Lite; or obtain a personhood tier in the Polkadot App. See Register a .dot Domain.
The Name Is Already Registered¶
Cause: DotNS names are first come, first served.
Resolution: Choose a different name. Re-deploying a name you already own is fine and does not conflict.
Uploads Are Rejected or Host storage unavailable¶
Cause: Two different problems share this symptom. Storing on the Bulletin Chain requires an explicit storage authorization on the signing account — without it, the store is rejected regardless of your token balance. Separately, Host storage unavailable means code that needs a Host is running outside one.
Resolution: Request a storage authorization for the signing account (see Get TestNet Tokens), and confirm you granted it to the account that actually signs (see the allowance entry above). For Host storage unavailable, run your Product inside Polkadot Desktop, or use the SDK's dev and testing paths for out-of-Host development.
The App Does Not Appear Right After Deploy¶
Cause: On-chain state takes a short time to propagate after the deploy transaction finalizes, and the web gateway resolves your name through an in-browser light client.
Resolution: Wait a few seconds and refresh. A curl or script against the gateway URL returns a generic gateway shell, not your app — open it in a real browser to see the resolved Product. If it still does not resolve after a minute, confirm the deploy finalized and check network status with the developer community.
Connecting to a Chain Throws Outside a Host¶
Cause: The chain-client routes every connection through the Host and has no direct-WebSocket fallback, so it throws when no Host provider is present.
Resolution: Run your Product inside a Host. For out-of-Host development and tests, use the SDK's testing fakes rather than a live connection. See Read On-Chain Data.
| Created: September 2, 2026