Pocket¶

Introduction¶

Pocket is Polkadot Desktop's peer-to-peer send flow. From the sender's side, Pocket is a UI in Desktop that lets a user package a payment or asset transfer addressed to another real person. The recipient is identified by their personhood identity in Polkadot's network, not necessarily by their account address. The receiver sees the incoming transfer in their paired Polkadot App and can accept or decline.

This page is the sender's view. The App-side receiver view is documented at Pocket Recipient.

Conceptual Model¶

Three properties distinguish Pocket from a plain Balances.transfer_keep_alive:

• Personhood-aware addressing: Instead of (or alongside) an SS58 account address, the sender can address a transfer to a recipient identified by their personhood. The sender does not need to know the recipient's account up front. The recipient resolves to the right address inside their App.
• Two-sided confirmation: A standard transfer settles unilaterally, so the recipient cannot refuse it. A Pocket transfer arrives at the recipient's App as a pending item; the recipient explicitly accepts or declines. On accept, it settles; on decline (or timeout), it does not.
• Split UX: The sender UX lives in Desktop, and the receiver UX lives in the App. The two sides of the flow are deliberately on different devices: the sender packages the transfer at a desk, the receiver approves on their phone with the same per-transaction approval model that gates every signed action.

What the User Sees¶

From the sender's side in Desktop:

1. The sender opens Pocket from Desktop's UI and selects a recipient (by personhood identifier, contact name, or address).
2. The sender enters the amount and any optional memo.
3. The sender confirms in Desktop, which triggers the standard signing modal and routes a per-transaction approval to the sender's own paired App.
4. After the sender approves on their App, Desktop dispatches the Pocket transfer.
5. The recipient sees an incoming Pocket item in their App and either accepts or declines (see Pocket Recipient).

For everyday merchant-style payments where the payer is responsive in a browser or a Product, and the merchant wants the funds settled, use the standard Balances.transfer_keep_alive flow. Pocket is the right tool when the recipient identity matters more than the recipient address, and when accept-decline semantics fit the interaction.

Where to Go Next¶