Pocket Recipient
Introduction
Section titled “Introduction”Pocket is Polkadot Desktop's send flow, a feature that lets a Desktop user package a payment or asset transfer and route it to a recipient identified by their App identity. This page documents the App-side counterpart, covering how the Polkadot App receives a Pocket transfer initiated from Desktop and the user-visible flow inside the App.
The Desktop sender-side view is documented at Pocket Send Flow in Polkadot Desktop. This page is the receiver's view.
Conceptual Model
Section titled “Conceptual Model”From the recipient's perspective:
- A Desktop user (the sender) initiates a Pocket transfer addressed to the recipient's paired App identity.
- The transfer arrives at the App as a pending incoming item, surfaced to the recipient in the App's UI.
- The recipient reviews and either accepts or declines the transfer.
- On accept, the transfer settles to the recipient's account. On decline (or timeout), it does not.
The distinguishing property of Pocket relative to a plain Balances.transfer_keep_alive is the accept step. A standard transfer settles unilaterally, so the recipient cannot reject it. Pocket's two-sided flow gives the recipient a chance to refuse, which matters when the transfer is contextually meaningful (an in-band payment between users who know each other) rather than a balance change.
The Product-developer surface that bridges to Pocket is part of the open question above, including whether a Product can initiate a Pocket transfer programmatically, or only the Desktop UI can. Once resolved, the integration pattern will be documented here.
Where to Go Next
Section titled “Where to Go Next”-
Payment Method Group
The TrUAPI method group covering
Balances.transfer_keep_aliveand the Pocket peer-to-peer payment flow available to Products.