host-playground (paseo.li): Statements > Submit fails with 'account full: submitted expiry < min' — likely regression vs closed polkadot-desktop#581

[mordamax]

Web host (paseo.li): Statements › Submit fails with account full: submitted expiry < min — same shape as the just-closed Desktop #581

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:415 Statements › Submit).

Summary

statement-store-submit from the host-playground.dot iframe inside the paseo.li PWA fails deterministically with the same chain rejection that paritytech/polkadot-desktop#581 tracked on Desktop. That issue was closed today (2026-06-25T11:46Z); the original report explicitly stated "Web passes, Desktop fails". We now observe the inverse — Desktop and Android both pass; the bug has surfaced on web. Looks like a regression introduced by whatever change closed #581, or the closure was premature.

Failing call

[signed-test] statement-store-submit: error —
  GenericError - Submit failed, account full:
    submitted expiry 7655334336702447616
    < min            18446744069433815040

Delta min - submitted ≈ 1.08e19 ns ≈ 343 years — the magnitude looks like a sentinel/uninitialised u64 (0xFFFF_FFFF_2EAD_AAAA ≈ 18446744069...) being compared against a real timestamp, not a small clock-skew. The Desktop #581 numbers were small-delta (~43 min). This is a different numeric pattern but the same chain reject code, suggesting the web shell now computes a valid expiry but the chain side reads a bogus min — or vice versa.

Cross-platform matrix (CI run 28173825676)

Surface	Create Proof	Create Proof (authorized)	Submit	Notes
Desktop v0.6.7	✓ 3.5s	✓ 2.6s	✓ 6.9s	clean
Android v1.0.0-1253 (Browse tab)	✓ 3.7s	✓ 994ms	✓ 4.1s	clean
Web (paseo.li)	✓ 6.7s	❌	❌ all 3 retries	this issue + sibling host-playground-web-create-proof-authorized-statement-proof-unknown.md

Same chain. Same Android signer. Only the web shell differs.

What this isolates

• Not the chain runtime — Desktop and Android both hit the same LitePeople collection on the same chain and pass.
• Not the Android signer — the web shard signs via the same paired Android device that Desktop uses.
• Not "fresh account vs full account" — the same identity passes Create Proof (3.7s on Android, 3.5s on Desktop, 6.7s on web) immediately before.
• The web shell's path to building the expiry field for statement_submit diverges from what the chain expects.

Reproduction

pnpm --filter @triangle-e2e/app-tests test:web --grep "Statements > Submit"

against:

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

CI run 28173825676 / job 83448824963 — Statements › Submit failed all 3 retries with identical error.

Triage

• Diff paseo.li shell's statement_submit payload (signed bytes + expiry) against the working Desktop path on the same chain at the same wall-clock moment.
• The sentinel-looking min 18446744069433815040 deserves a direct look — does the runtime read min_expiry from chain state, or did the web SDK forward a default-uninitialised u64?
• Confirm whether the fix that closed #581 shifted only the Desktop code path or also touched the shared SDK / shell-side encoding.

Ask

• Re-open or reference #581 — this looks like the same defect surfaced on the previously-passing surface.
• Surface a typed error from the chain (StatementSubmitErr::ExpiryOutOfWindow with the two values) instead of the opaque GenericError - account full.

Suggested target repo

Best guess: same repo as #581 (paritytech/polkadot-desktop) if the shared encoder lives there, otherwise paritytech/truhost (web PWA host) or paritytech/product-sdk (the layer that produces the encoded payload). The Desktop maintainers will know which.