Mimir And Halt Controls

Mimir values are THORChain operational controls. They let the network change parameters, pause scoped actions, and schedule some controls without changing the protocol code every time. This article explains how to read those controls without turning a static docs page into a false current-status claim.

For current availability, start with /network#network-diagnostics. This page is the map for interpreting the evidence.

What Mimirs Can Prove

Mimirs can support a precise current-state claim when it names the action, scope, source, and checked height. Say "BSC trading is halted in this checked THORNode snapshot"; avoid turning an LP pause into "THORChain is paused" or a missing WASM halt into "this app is safe."

Mimir evidence is strongest when paired with the exact key, source freshness, block height, and the user action being discussed.

Control Families

The same word "halt" can apply to very different operations. Keep the families separate.

Ordinary swap controls

Use these when the claim is about base-layer swaps:

HALTTRADING and chain-scoped trading keys.
HALTSIGNING and chain-scoped signing keys.
Chain halt fields from inbound_addresses.
Quote errors from THORNode /thorchain/quote/swap for a specific route.
Streaming and memo-related controls such as StreamingSwapPause and HaltMemoless.

These are the controls that should drive phrases such as "ordinary swaps available", "some routes limited", or "route blocked".

LP, pool, loan, and churn controls

These controls matter, but they should not make ordinary swaps look globally halted:

PAUSELP and chain-scoped LP controls.
Pool-specific deposit controls.
PAUSELOANS.
HALTCHURNING.
RUNEPool controls such as RUNEPoolHaltDeposit and RUNEPoolHaltWithdraw.

If one of these is active, label the affected operation. Do not collapse it into "swaps paused" unless a swap control also supports that claim.

App Layer, secured-asset, and trade-account controls

App Layer and account-style flows have their own controls:

HaltWasmGlobal, HaltWasmDeployer-*, HaltWasmCs-*, and HaltWasmContract-*.
HaltOracle.
HaltSecuredGlobal, HaltSecuredDeposit-*, and HaltSecuredWithdraw-*.
TradeAccountsEnabled, TradeAccountsDepositEnabled, HaltTradeDeposit-<CHAIN>, and HaltTradeWithdraw-<CHAIN>.

These controls are scoped. A specific contract, code checksum, deployer, secured-asset flow, or trade-account action can be limited while ordinary swaps remain available. The trade-account deposit and withdrawal halt values are activation heights: the matching chain action is halted when the checked THORChain height reaches or passes the configured positive value.

See the App Layer deep dive for the full picture of WASM, oracle, secured-asset, and trade-account mechanics beyond halt controls.

Node and operator controls

Node operations use another family:

PauseBond.
PauseUnbond.
HaltRebond.
HaltOperatorRotate.

These keys affect node/operator workflows. They should not be used as route-availability proof unless the claim is about the relevant node action.

Active, Scheduled, Inactive, Absent

The dashboard should distinguish four states:

Active: the key or source field currently blocks the scoped action.
Scheduled: the value refers to a future or height-dependent control, so the claim depends on the checked block height.
Inactive: the key is known and present but does not currently block the scoped action.
Absent: the key was not returned by the source snapshot.

Absent is the easiest state to overread. A missing halt key is not full proof that every related operation is healthy. It only means that key was not present in the checked source response. Current availability still depends on inbound fields, pool state, route quote behavior, provider freshness, and whether the relevant key family is fully understood by the dashboard.

Scoped Keys And Normalization

Many halt controls are scoped rather than global. Scope can come from a chain suffix, pool, contract address suffix, deployer, checksum, or account-flow family.

When interpreting a scoped control:

Normalize the chain or asset name before comparing values.
Separate network-wide controls from chain-specific controls.
Render network-wide controls once instead of repeating them on every chain.
Preserve the exact raw key in collapsed diagnostics for auditability.
Avoid inventing a healthy status for unknown or malformed keys.

This is why a good diagnostics panel names the user-facing blocker first, then keeps raw Mimir keys in a disclosure. A reader needs "BSC: trading halted" before they need the exact key spelling.

Source Warnings And Review Keys

Operational source warnings should degrade the data-quality label even when the visible blocker is clear.

Examples:

A stale or unpinned source means the page should not present the data as a fresh snapshot.
A malformed Mimir value should be shown as a warning, not coerced to zero.
An unknown operation-like Mimir key should enter a review queue until the dashboard knows how to classify it.
Duplicate or conflicting scoped records should fail closed for that provider.

Unknown keys are not automatically active halts. They are a source-quality problem. The practical posture is: show the known current blockers, disclose the review queue, and avoid claiming complete coverage.

What To Verify Before Claiming

For each claim, identify its control family and exact key or source field; retain provider, checked time, height, data quality, and whether a network-wide control directly blocks that scope. Concrete routes need the current quote result rather than a chain-level assumption. Static docs explain design meaning only; Mimir does not establish future availability, wallet safety, uptime history, route quality, or the impact of every unknown key.

Memoless Cost And Halt Cycle (August 2026 context:)

The August 2026 memoless spam window shows why cost parameters and halt keys are different controls. Community reporting and live Mimir snapshots describe a halt, a re-enable with MEMOLESSTXNCOST raised to 200000 base units, a spam-driven re-halt, and HALTMEMOLESS=1 active after the v3.20.0 upgrade.

Read that cycle as three separate claims:

MEMOLESSTXNCOST=200000 is a parameter snapshot: the checked cost of memoless handling, subject to later votes.
HALTMEMOLESS=1 is the active control that blocks memoless handling while present; it is what made memoless flows unavailable, not the cost value by itself.
The v3.20.0 release notes include memoless ERC-20 handler and refund work, which is release evidence for the feature path, not proof of current availability.

Do not collapse this history into "swaps were down". Ordinary memo-based swaps continued whenever global and chain trading controls were clear; the incident record on the Governance page keeps the dated timeline.

The same v3.20 window carries two positive control changes worth separating from the halt cycle: POL System Income and POL Asset Whitelist Mimirs are described as operational in the official upgrade recap, and churn was set to resume after being blocked through the consensus-fault window. Operational Mimir claims still need a live snapshot check before present-tense use.