Stellar Index v0.44.3

[v0.44.3] — 2026-08-26

Tested against Stellar protocol 22.

Added

• /tx now shows the Soroban authorization-invocation tree. An
  InvokeHostFunction operation's decoded fields gain an authorizations
  tree — the nested SorobanAuthorizedInvocation structure from the op's auth
  entries (contract + function + args, recursively), rendered on the explorer
  /tx view as "Authorized invocations." This surfaces the nested contract-call
  structure the view previously omitted (a step toward the richer /tx detail
  stellar.expert shows). Decoded from the already-stored operation BodyXDR,
  so no schema change or backfill. It is the AUTHORIZATION subtree, not the
  full execution trace (that lives in the tx meta the lake does not store) —
  labeled as such. The full execution tree + Soroban resource metering remain
  a separate follow-up (they need tx-meta/resources the lake does not persist).
• Exploit-shaped detector for AMM self-pair swaps (post-2026-08-25
  Blend/Comet). A self-pair swap (token_in == token_out) on a curated AMM
  pool moves no value between distinct assets and has no honest purpose — it
  is the primitive the exploit ran ~390 times to walk a pool's spot price,
  and the freeze + divergence guards were blind to it because the self-pair
  rows decode to zero rows and never reach the served trades table. New
  counter stellarindex_amm_self_pair_swap_total{source} is incremented at
  the comet decoder's drop point, and a stellarindex_amm_self_pair_swap_burst
  alert (ticket) fires on increase[15m] > 10 — far above the historical-zero
  baseline. Detection only: it changes no serving or freeze decision, so it
  cannot create a false freeze. The counter increments only for LIVE (recent
  ledger close time) events, so a backfill or completeness re-derive of the
  historical exploit window does not re-fire the alert. Zero-seeded (F-0033)
  so operators can tell "armed" from "dead metric," and ships with
  false-positive + replay-suppression guard tests plus a runbook.

Fixed

• stellarindex_priceless_coverage_check_stale paged a perma-stale FALSE
  positive from the indexer and api instances. The
  ..._last_success_unix gauge is registered in the shared obs registry, so
  every binary exports it, but ONLY the aggregator runs the coverage sweep
  that sets it — on the other two it sits at unix 0 forever, so time() - 0
  crossed the 1800s staleness threshold on every evaluation. Scoped the alert
  expr to job="stellarindex-aggregator"; a genuinely-wedged aggregator
  (its own gauge stuck at 0) still fires, and a promtool case guards the
  non-aggregator-instance suppression.