Polkadot Desktop¶

Introduction¶

Polkadot Desktop is the workstation app where developers and users actually run Polkadot Products. Think of it as a specialized browser — but instead of typing a URL, the user types a .dot name, and instead of rendering arbitrary web pages, Desktop fetches a published Product bundle from decentralized cloud storage and runs it inside a sandbox where signing, storage, and outbound network requests are all mediated by the Host.

Desktop never holds the user's private key. The key lives on the paired Polkadot App on the user's phone. Desktop holds only a derived session public key, enough to identify the user and construct per-Product accounts. Every signing operation routes back to the App for user approval.

This section documents Desktop's developer-facing surface: how a Product runs inside it, how signing works end to end, how the permissions model enforces sandbox boundaries, and how Desktop exposes Statement Store, Preimage, and Pocket features to Products and users.

How It Works¶

From a Product developer's perspective, three properties define how Desktop behaves:

• .dot-name addressing: A published Product is addressed by its .dot name. Desktop resolves the name through dotNS, fetches the published bundle, and loads it in the sandbox. During development, Desktop's address bar accepts localhost:PORT as a whitelisted bypass so you can iterate against a local dev server. See Set Up Your Project.
• Sandboxed runtime: A Product runs inside a sandboxed container, not an arbitrary browser tab. It cannot make outbound network requests, access local storage, or sign transactions except through the Host API. See Permissions.
• Mediated signing: Every transaction a Product submits, whether dispatched through the Product SDK or directly through TrUAPI, goes through Desktop's signing modal and on to the paired App. There is no path for a Product to sign without user approval. See Signing.

Where Desktop Fits in the SDK Surface¶

Desktop both consumes and produces the TrUAPI surface:

• It consumes Host API methods from the App (signing, PoP proofs) and from infrastructure layers (Bulletin Chain, Statement Store, dotNS) when its own features (Pocket, Preimage, Statement Store mediation) need to talk to those layers.
• It produces the surface Products call into: chain interaction, local storage, account management, signing, statement submission, preimage submission, and so on. The Product SDK (@parity/product-sdk and friends) is a typed wrapper over that surface.

Where to Go Next¶