## Summary `MsgSwap.State.FailedSwaps` and `MsgSwap.State.FailedSwapReasons` are appended to on every failed swap attempt and are never capped, truncated or pruned. With `StreamingLimitSwapMaxAge` now at 5,256,000 blocks (~1 year) on mainnet, a limit swap that can never succeed accumulates these arrays for its entire lifetime. This is consensus state, not just a query artifact: it is persisted via `SetAdvSwapQueueItem`, so every node stores it, it lands in the app hash, state sync and snapshots, and `FetchQueue` unmarshals it on every block. ## Evidence (mainnet, 2026-08-03) Two limit swaps currently on the queue: ``` A1DE3FCAE77FC313165E59F9C511783A4E9ED0AEE5DD9AA7E70D8C1226863973 failed attempts 10,129 entry size 2.15 MB blocks_since_created 53,263 time_to_expiry_blocks 5,202,737 523DA9F843CADC5A4FD57546F745520BD951F4BFBCCADD60F7FFEF1924EE21EC failed attempts 10,129 entry size 2.15 MB ``` Every failure is the same, and is not transient: ``` fail to withdraw from trade: 2 errors occurred: * internal error * insufficient trade asset balance for ETH~DAI-0X6B175474E89094C44DA98B954EEDEAC495271D0F: requested 12606772297, available 0 ``` The order is funded from a trade account whose balance is zero. It cannot succeed on any future block, and has ~5.2M blocks of TTL left. Cost per failure is ~212 bytes (reason string averages 194 chars, plus the `uint64` in `FailedSwaps`). Observed accumulation is 0.19 failures/block for this swap. ## Impact `/thorchain/queue/limit_swaps` currently returns **4.7 MB in 2-9 s** for **18 limit swaps** — 99.5% of the payload is `failed_swap_reasons`. `limit=10` still returns 4.27 MB, so pagination does not help. `/thorchain/queue/swap/details/{tx_id}` for a single affected swap is 2.3 MB / 1.4 s. Projections at the current 1-year TTL: | scenario | append rate | one year | | --- | --- | --- | | observed zombie above | 0.19 / block | **~212 MB per swap** | | discovered + failing every iteration | 3 / block (`ADVSWAPQUEUERAPIDSWAPMAX=3`) | **~3.3 GB per swap** | | queue saturated with such swaps | `MaxSwapsPerBlock` 100 x 3 iterations | **~334 GB / year** | The default `StreamingLimitSwapMaxAge` constant is 43,200; mainnet mimir overrides it to 5,256,000, so the exposure window grew ~122x without the arrays gaining a bound. ## Root cause `x/thorchain/manager_adv_swap_queue_current.go:852` ```go msg.State.FailedSwaps = append(msg.State.FailedSwaps, msg.State.Count) msg.State.FailedSwapReasons = append(msg.State.FailedSwapReasons, handleErr.Error()) ``` and the streaming equivalent at `x/thorchain/manager_swap_queue_current.go:202`. Neither site bounds the slice. Note the guard immediately above only skips *market* swaps on iteration > 0, so a limit swap can append once per rapid-swap iteration. There is also no cost to the creator: a failed swap does not consume the deposit, so the number of zombies is limited only by how much of the per-block budget they can occupy. Creating one does not require malice — placing a limit order funded from a trade account and then withdrawing that balance produces exactly the state above. ## Reducing the TTL does not remediate this `getTTL` reads `StreamingLimitSwapMaxAge` **at insert time** and the expiry height is materialised into the TTL index by `SetLimitSwapTTL`. `processExpiredLimitSwaps` then only looks up `GetLimitSwapTTL(ctx, currentHeight)`, an exact-height match. Lowering the mimir therefore applies to newly created limit swaps only. Swaps already on the queue keep the expiry height written at creation and continue accumulating until it is reached. The `State.Interval` cap at `manager_adv_swap_queue_current.go:669-675` is likewise applied only on insert. ## Suggested fixes Any one of these bounds the growth; they are listed cheapest first. 1. **Cap the arrays.** Keep the last N failures (ring buffer). N=32 keeps the diagnostic value at ~7 KB worst case. 2. **Store a count plus the most recent reason** rather than every string. Repeated failures are almost always identical — 10,129/10,129 here share a prefix. 3. **Expire after K consecutive failures.** This also removes zombies that can never fill, rather than leaving them on the queue for a year. A store migration would be needed to prune the entries that already exist, since lowering the TTL will not reach them.