# Retiring-vault migration stalls the entire vault for ~3000 blocks on any single stuck migrate — make the pending-migrate guard per-asset (preserving gas-migrated-last-per-chain) **Component:** `x/thorchain` (`NetworkMgr.migrateFunds`, vault churn/migration) **Version observed / confirmed:** mainnet `v3.20.2` (source verified at tag `v3.20.2`, commit `0bf1f22cd`) **Severity:** Medium — no funds lost, but a retiring vault can be blocked from draining any of its assets for up to ~3000 blocks whenever one asset's migrate is stuck; delays churn completion and leaves a retiring vault lingering. ## Summary `migrateFunds` gates new migration scheduling at the **vault** level: if *any* in-flight txout from a retiring vault carries a `TxMigrate` memo, the vault is skipped entirely and **none** of its assets are re-scheduled until the stuck migrate ages out of the stale window (`SigningTransactionPeriod × 10 = 300 × 10 = 3000` blocks). So one stuck migrate (e.g. a chain whose keysign is failing) freezes the migration of every other asset in that vault — including assets on unrelated, healthy chains. The migration accounting already deducts in-flight migrates from the vault's spendable balance, so scheduling migrates for *other* assets is safe and cannot double-spend. The guard can therefore be narrowed from **per-vault** to **per-asset**, while keeping the existing "migrate the chain's gas asset last" invariant that prevents token-strand. ## Current behaviour (code) `x/thorchain/manager_network_current.go` — the per-vault stall (`migrateFunds`, ~line 726): ```go if vaultsWithPendingMigrate[vault.PubKey] { ctx.Logger().Info("Skipping migration scheduling while migrate transactions are still pending", "vault_pubkey", vault.PubKey) continue // <-- skips the entire per-coin scheduling loop for this vault } ``` `vaultsWithPendingMigrate[vault]` is set true for **any** pending `TxMigrate` outbound from the vault (~line 611), and the same pass already deducts each pending migrate's coin **and** `MaxGas` from the vault's spendable balance (~lines 605–618): ```go if memo, memoErr := ParseMemo(...); memoErr == nil && memo.IsType(TxMigrate) { vaultsWithPendingMigrate[toi.VaultPubKey] = true } for _, coin := range append(common.Coins{toi.Coin}, toi.MaxGas...) { availableCoins = availableCoins.SafeSub(coin) // in-flight migrate already reserved } ``` Stale-retry window (`~line 596`): `staleMigratePendingBlocks := signingTransactionPeriod * constants.StaleMigratePendingSigningPeriodMultiplier` with `StaleMigratePendingSigningPeriodMultiplier = 10` (`constants/constants.go:44`) ⇒ **3000 blocks** before an unobserved migrate is pruned and retried. Relevant intervals: `FundMigrationInterval = 360`, `ChurnMigrateRounds = 5`. ## Why narrowing it is safe Because `availableCoins` already subtracts every pending migrate (coin + MaxGas), a migrate scheduled for a *different, non-stuck* asset draws only from the remaining balance and cannot conflict with the in-flight one. The per-vault `continue` is stricter than the accounting requires; its real purpose is to stop the **same** partially-migrated asset from being re-scheduled every `FundMigrationInterval` (pile-up), which a per-asset guard preserves. ## Invariant that MUST be preserved — gas asset migrates last per chain The retiring vault needs its chain gas asset to pay the L1 fee for migrating that chain's tokens. `migrateFunds` already guards this (~line 848): ```go // ... await for all non-gas assets to have left the vault before we // transfer the remaining gas asset to stop this scenario from happening if nth >= migrationRounds && vault.CoinLengthByChain(coin.Asset.GetChain()) > 1 && coin.Asset.IsGasAsset() { continue } ``` This was added for the historic ETH-strand incident (last round: a token migrate failed but the gas migrate succeeded, leaving tokens with no gas to move them). A per-asset optimization must keep this: a stuck token stays physically in the vault, so `CoinLengthByChain(chain) > 1` remains true and the chain's gas asset is held. Timing already aligns — a migrate only becomes "stuck" as it approaches the 3000-block stale window, which is ~8 × `FundMigrationInterval`, well past `migrationRounds` (5), so `nth >= migrationRounds` is already true when it matters. ## Proposed change 1. Replace the per-vault `vaultsWithPendingMigrate[vault]` skip with a **per-(vault, asset)** pending set: in the per-coin loop, skip only assets that already have a pending migrate; let the rest schedule normally. 2. Keep the gas-last guard, and preferably **generalize** it: hold a chain's gas asset whenever that chain still has a non-gas coin present/stuck, rather than gating on `nth >= migrationRounds` — same effect today, robust if the round/interval constants change. 3. No change to the 3000-block stale-retry path; the stuck asset still waits on its own timeout — it just no longer holds the rest of the vault hostage. **Result:** healthy assets (and other chains) drain on schedule; the vault retires as soon as the healthy assets clear; only the genuinely-stuck asset waits on its timeout, with its chain's gas held back to guarantee it can still be moved. ## Live example (2026-09-15) Last retiring vault `…573m6k` holds `GAIA.LQDY`, `GAIA.ATOM` (gas), and `BASE.ETH` (dust). GAIA keysign is currently unreliable, so a stuck GAIA.LQDY migrate blocks the whole vault under the per-vault guard. With the per-asset change, `BASE.ETH` (a different, healthy chain) would migrate immediately, `GAIA.ATOM` would be held (gas-last), and only `GAIA.LQDY` would wait — instead of all three stalling together.