Signing¶

Introduction¶

The Signing method group lets a Product submit a signed transaction. The Host on the other side does not sign. It mediates by rendering the signing modal, forwarding the payload to the paired Polkadot App, waiting for the user's approval on their phone, and returning the result as a signature, rejection, or timeout.

The Product SDK wraps this as tx.signAndSubmit(signer) on a Polkadot API (PAPI) transaction object plus a signer returned by SignerManager.getSigner(). From the Product's perspective, it is a single awaited promise. Underneath, it is a TrUAPI dispatch and a round trip to the user's phone.

Conceptual Contract¶

The group covers:

• Submitting a payload for signing: The Product hands the Host a pre-built, account-bound transaction. The Host renders the signing modal and forwards the payload to the paired App.
• Watching the result: The Host returns the outcome — signature obtained (Host then broadcasts), explicit user rejection (HostRejectedError), or session timeout (TimeoutError).
• Surfacing status transitions: Through PAPI's submitAndWatch companion surface, the Product sees status events (signing, broadcasting, in-block, and finalized) as the transaction progresses.

The default contract is the one that makes the model trustworthy: every transaction requires a per-request approval on the phone, with no session-scoped consent and no path for a Product to obtain a signature without the user approving the specific payload they were shown. This per-request flow is what a Product gets unless an Auto-Signing resource has been explicitly allocated.

Auto-Signing¶

The shipping @parity/truapi wire carries an Auto-Signing capability on top of the per-request default. A Product requests it as an allocatable resource through host_request_resource_allocation; the user must explicitly grant the allocation, and the Host scopes what it covers. Polkadot Desktop ships this as signing-bot-autopair, which pairs a signing bot so that allocated transactions are signed without a per-transaction prompt. Auto-Signing is opt-in, user-granted, and bounded — it does not remove the approval requirement for ordinary signing; it replaces it, within the allocated scope, with an up-front consent the user can revoke.

For the full mediated-signing flow (the three-actor model, the ChainSubmit permission, failure-mode UX), see the Signing in Polkadot Desktop reference.

Where to Go Next¶