walletOfflineQueueSupportedProvider top-level property
HOST SEAM: whether the host's custody model supports the OFFLINE send
queue (#327). Queuing persists the intent NOW and SIGNS later — so a custody
model whose signing credential exists only inside an authorized window
(per-send passphrase/biometric) historically could not serve it at all, and
the send form must not offer "save for later" it cannot honour: override to
false and the affordance is HIDDEN (an honest absence beats a queue that
faults at drain). UX honesty, not a safety boundary — if a queue does slip
through on such custody, the drain fails typed, the send stays visibly
parked ("saved & pending") and cancellable; no funds move.
A PROMPT-PER-SPEND HOST MAY NOW SET THIS true (FR-23-b / #361). The
parked-sends surface offers "Send now", which signs a parked row inside your
WalletSendAuthorizer.authorizeSpend bracket
(WalletSession.authorizeParkedSend) — the queue drains at a user-present
moment instead of an unattended one. Set it true once you serve that call.
It stays a HOST-SET capability rather than one derived from "an authorizer is wired" (maintainer decision D2, 2026-07-25): wiring the seam is not proof you can STAGE a credential on demand, and this flag's whole job is the honesty rule "never advertise a queue that cannot drain". You know your custody; the package does not.
The swap deposit has a superficially similar deferred shape but its gate is the swap enablement config, not this flag — and since FR-23-a it signs in-bracket at execute, so it needs no queue support at all. The BACKGROUND drain also pauses whenever the host's SYNC policy is off (it rides sync passes), so the send form additionally gates the affordance on walletSyncPolicyProvider (see its MONEY COUPLING note).
WHAT "Send now" DOES AND DOES NOT ESCAPE (#400 R1 — this paragraph used to
overclaim). The SIGNATURE is genuinely user-driven and owes nothing to the
pass schedule. The BROADCAST does not: the signed group goes to a detached
best-effort kick (bounded retry, then it gives up), and the durable re-send
behind it — resubmit_queued_sends's ReBroadcast arm — runs only after a
COMPLETED SYNC PASS. Under a sync-off policy there are no passes, so a kick
that exhausts its retries leaves a signed, note-spending transaction that
nothing will re-send. The parked surface says so on the signed outcome
(walletParkedAuthorizeSentSyncPaused) rather than pretending otherwise. Sync
STATE matters too: a wallet whose tip cannot advance may be unable to build
the transaction at all, which surfaces as the honest "not ready to send yet",
never as a failure.
"Send now" is NOT gated on this flag (#400 R9, deliberate). The flag
governs the ENTRY — whether the send form offers to save a payment for later.
It does not govern the EXIT of a row that is already committed. A host can
flip it to false with parked rows already saved (or inherit them from a
restore), and a committed send must keep both of its exits — drain and
cancel — or the user's money has nowhere to go. On custody that truly cannot
stage a credential the attempt fails typed and honestly ("not ready to send
yet", the row untouched); that is strictly better than removing the only
non-destructive way out. A row that is already MID-SIGNATURE hides the button
for the different reason that the SDK verb would refuse it outright.
Implementation
final walletOfflineQueueSupportedProvider = Provider<bool>((ref) => true);