host-playground (paseo.li): Statements > Create Proof (authorized) fails with 'StatementProof: unknown error' — web-only, undocumented

[mordamax]

Web host (paseo.li): Statements › Create Proof (authorized) fails with StatementProof: unknown error — web-only

Web host: paseo.li (dot.li PWA shell).
Android signer: Polkadot Android v1.0.0-1253.
Desktop (for reference): polkadot-desktop v0.6.7.
Chain: Paseo Next v2 (people + bulletin via paseo-people-next-system-rpc.polkadot.io).
Test suite: host-playground-web in triangle-e2e (web.test.ts:393 Statements › Create Proof (authorized)).

Summary

createProofAuthorized (RFC-0010 statement-store path) returns a typed but opaque StatementProof: unknown error when invoked from the host-playground.dot iframe inside paseo.li. The same call passes immediately on Desktop and Android against the same chain, with the same Android signer. No matching upstream issue found in paritytech/* at filing time — distinct from the closed polkadot-desktop#581 (that one was Submit, not Create Proof; and was about expiry-window math, not proof construction).

The non-authorized Create Proof companion passes on web in 6.7 s (same describe, just-before this test). So the host SDK's path through statement-store is alive on web — only the authorized variant breaks.

Failing call

[signed-test:web] statement-store-create-proof-authorized: clicking run button
[signed-test] statement-store-create-proof-authorized:
  error — Error: createProofAuthorized failed: StatementProof: unknown error
[signed-test] statement-store-create-proof-authorized: tapped 0 android approval(s)

tapped 0 android approval(s) = the proof failed before any sign sheet was shown on Android. The error originates in the proof-construction path on the host side, not in the signing handshake.

Cross-platform matrix (CI run 28173825676)

Surface	Create Proof	Create Proof (authorized)	Submit
Desktop v0.6.7	✓ 3.5s	✓ 2.6s	✓ 6.9s
Android v1.0.0-1253 (Browse tab)	✓ 3.7s	✓ 994ms	✓ 4.1s
Web (paseo.li)	✓ 6.7s	❌ all 3 retries	❌ (see sibling issue)

Same chain, same Android signer, same allowance state. Web shell is the only differing variable.

What this isolates

• Not the chain — Desktop and Android both succeed on statement_create_proof_authorized against the same chain in the same CI minute.
• Not the Android signer — tapped 0 android approval(s) confirms the call failed before reaching the sign sheet; nothing for the Android side to handle.
• Not the SDK's basic create_proof — the non-authorized variant passes on web seconds before.
• Authorized-specific — the bug is in the authorized code path that adds the per-product DotNS-bound authorization on top of basic Create Proof.

Possible causes:

• Web shell's statement_create_proof_authorized wrapper drops or mis-encodes the DotNS authorization context.
• The error message itself (StatementProof: unknown error) is the SDK's catch-all rather than a typed reason — the host side may be raising a typed error that's getting flattened to "unknown" on the way out.

Reproduction

pnpm --filter @triangle-e2e/app-tests test:web --grep "Statements > Create Proof \\(authorized\\)"

against:

• Polkadot Android v1.0.0-1253 (paired signer)
• paseo.li (dot.li shell)
• Paseo Next v2

CI run 28173825676 / job 83448824963 — all 3 retries failed identically at ~5 s each.

Ask

• Localise where StatementProof: unknown error is being thrown on the web path — the typed error from the underlying SDK is being lost. Surface the real reason.
• Diff the statement_create_proof_authorized payload built on Desktop vs the one built on paseo.li for the same DotNS / topic.

Suggested target repo

Best guess: paritytech/product-sdk or paritytech/truhost (web PWA host wiring). Authorized proofs are wrapped by the host shell on top of the SDK's create-proof primitive; this looks like the wrapper layer or its serialisation.