OB-115: Reconcile ledger confirmation with delayed indexer data

[IbrahimIjai]

Priority: P0 · Size: L · Area: real-time · Depends on: OB-004, OB-005, OB-108, OB-112

Scope: Track confirmed transaction evidence and wait for the agreed ledger,
cursor, or entity version before considering account views caught up. Use bounded
retry and a visible syncing state instead of treating one refetch as sufficient.

Acceptance criteria:

• A confirmation followed by several older indexer responses does not make a new order disappear or restore a closed position as current.
• Catch-up refreshes all affected views, while timeout leaves a truthful confirmed-but-syncing state with a data-refresh action, not a resend suggestion.

Season context

Build a standard order book trading experience for SO4 on Stellar: a compact watchlist and market header, a large chart, an adjacent order book/recent-trades panel, a right-hand order ticket, and account tables below. Preserve SO4's brand and shared design tokens. Keep verified perpetuals capabilities; do not add Pro mode, EVM wallet connection, new margin modes, TWAP, or spot/perps transfers solely to imitate the reference layout.

An order book layout does not establish an executable order book. Matching, resting depth, partial fills, signing, and settlement need verified sources; account orders, oracle prices, pool liquidity, and illustrative data are not substitutes for executable depth. Preserve geometry during loading and live updates. Motion should clarify state changes, with reduced-motion, focus, touch, and interruption behavior included.

Extend the existing custom @workspace/ui/components/toast implementation; do not install Sonner or a second toaster. Use TanStack Query for scoped caching, targeted refresh, and explicit indexer catch-up after confirmed transactions.

Common completion rules

• Follow AGENTS.md, including reproduction and regression
  coverage for bug fixes, the full ordered commit gate, and integration checks for
  web/indexer changes. Do not weaken checks. Dependency/build changes require the
  clean-room verification specified there.
• Use existing components and named design tokens from
  packages/ui. Token changes include the corresponding
  DESIGN.md documentation. No parallel theme or toast system.
• Use explicit MSW handlers for network tests. Include relevant success, empty,
  stale, and failure behavior; keep timers and streams deterministic. Visual work
  includes desktop/mobile and reduced-motion review, with relevant theme coverage.
• Include a user-visible changelog entry when required by the repository's
  entry format. Documentation changes
  follow apps/docs/CONTRIBUTING.md.
• Distinguish wallet approval, submission, ledger confirmation, order acceptance,
  execution/partial fill, and indexer catch-up. A transaction confirmation must
  never falsely imply that a resting order has filled.
• Use targeted invalidation after confirmed changes, and explicitly handle
  inactive queries when their views next open. Invalidating an active query marks
  it stale and triggers background refetch; it does not prove an indexer has
  caught up. See TanStack Query invalidation.
• Cache freshness and retention are separate choices. Define them by data class,
  rather than treating a long staleTime as a real-time strategy. See
  TanStack Query defaults.
• Measure speed on the baseline device/network profile in OB-010. Initial field
  targets are p75 LCP ≤ 2.5 s, INP ≤ 200 ms, and CLS ≤ 0.1, reported separately
  for landing and trading and for mobile/desktop. Lab results are diagnostics,
  not a substitute for field percentiles. See Web Vitals.

Priority key: P0 = prerequisite/correctness; P1 = core experience; P2 = later polish. Size: S/M/L describes relative scope, not a delivery-time promise.

[zeey-247]

@zeey-247 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hello, I've read the issue description and I clearly understand what's needed. I'd be glad to take it on.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @zeey-247 to this issue.

[chukwuebuka19]

@chukwuebuka19 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Gm maintainer(s)
let me take this off your plate ASAP

ℹ️ Repo Maintainers: To accept this application, review their application or assign @chukwuebuka19 to this issue.

[drips-wave]

Congratulations, @chukwuebuka19! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.

🧑‍💻 @chukwuebuka19: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊