Glossary

The transaction instruction string that communicates an intended THORChain action. Valid syntax, accepted size, and current action availability are separate checks: deprecated handlers can remain documented, and an invalid or unavailable action may refund rather than execute.

A THORChain L1 vanity-name and alias record with an owner, expiry, chain aliases, and optional preferred asset for affiliate-fee payouts. It can support affiliate tracking and fee collection, but it does not by itself prove current dynamic-fee attribution, route quality, or interface safety.

THORChain application-layer functionality built around CosmWasm contracts, Mimir-governed deployment permissioning, and scoped deployer, checksum, and contract controls.

Smart-contract technology used for THORChain app-layer functionality. Current deployer, checksum, contract, or global halt state must be read from live controls.

Continuous Liquidity Pool. THORChain pools price swaps from pool depth and slip, with RUNE paired against external assets.

Liquidity-provider purchasing-power risk when relative pool asset prices move. THORChain docs frame slip-based fees as reducing this risk, not removing it; current LP return claims still need live pool and earnings evidence.

A participant who supplies assets to a THORChain pool and receives pool-share accounting plus a share of pool earnings and final balances. Current deposit or withdrawal availability depends on live LP controls, lockup rules, outbound state, and chain state.

Accounting units used to track a provider share of a THORChain pool. Units explain proportional pool ownership and redemption accounting, not whether LP deposits or withdrawals are currently open or what a position will return.

The quote field for the minimum allowed input, priced in 1e8 units of the inbound asset. It applies the documented source-fee, destination-fee, and one-dollar floor with a gas-spike buffer; it is still a current quote value, not an execution guarantee.

A quote parameter that converts the expected output into a fee-aware minimum output in the generated memo. The swap reverts or refunds when output falls beyond that basis-point tolerance; unlike tolerance_bps, it accounts for swap and outbound fees, but it is not route or settlement proof.

A fee component associated with the outbound transaction and chain gas. Exact values are live protocol data, not static wiki constants.

An optional memo-defined interface or affiliate fee, usually expressed in basis points. It is distinct from protocol liquidity and gas-related fees.

ADR-026 experiment terminology for per-thorname, per-pair L1 minimum slip floors adjusted by TOR-denominated fee evidence. Live state is current-only THORNode evidence.

Liquidity controlled by the protocol rather than ordinary external LPs. Balances and PnL come from current accounting, while enabled pool scope comes from live `POL-<Asset>` Mimir keys; neither should be inferred from a fixed documentation count.

A RUNE-only participation mechanism with aggregate exposure to POL-enabled pools. Current value, potentially negative PnL/current-deposit fields, POL scope, and deposit or withdrawal availability need same-provider, height-pinned THORNode and Mimir evidence.

A historical reserve-subsidy mechanism for LP withdrawals. Official THORChain docs now say IL protection has been removed or ended, so do not describe it as currently available for ordinary liquidity providers.

A Cosmos bank asset type, often shortened to synth, denoted with `CHAIN/ASSET` and distinct from secured (`CHAIN-ASSET`) and trade (`CHAIN~ASSET`) notation. Synthetics were part of historical Savers mechanics; notation and documented memo handlers do not prove that minting, swapping, or Savers actions are currently available.

A permanently deprecated THORFi feature that used single-sided synthetic accounting. Official archived docs date deprecation to 2025-01-04; retained mechanics and memo references are historical evidence, not current deposit, yield, or redemption instructions.

A recovery-token framing associated with the THORFi unwind. Official sources describe 1 TCY per $1 of defaulted THORFi debt and warn that full recovery is market dependent, so current claim, staking, and value claims need fresh evidence.

A threshold-signature scheme family in THORChain's post-exploit migration plan. The June 2026 post-restart update still describes chain-by-chain DKLS/FROST migration as future work, not completed current implementation.

A signature construction related to the FROST direction discussed after the GG20 exploit. Official post-restart reporting describes evaluation and future chain-by-chain migration, not proof that current vault signing has moved to Schnorr/FROST.

The threshold-signature implementation family used in the May 2026 exploit path. v3.19.1 patched the incident class, but official post-restart reporting still treats migration away from GG20 as future work; neither fact is present-day vault-safety proof.

A cryptographic component used in the GG20/ECDSA signing path discussed in the 2026 exploit report. The report ties malformed Paillier key material to the attack, so Paillier claims should stay attached to dated incident sources.

Multiplicative-to-additive signing-round terminology from GG20/ECDSA threshold signing. THORChain Exploit Report 2 says repeated failed MTA rounds leaked enough key-share material for the attacker to reproduce one vault key.

A Paillier-key property discussed in the official exploit report. Use it as incident-root-cause vocabulary, not as a standalone explanation of current THORChain cryptography.

A temporary recovery check introduced around the v3.19 restart to confirm validators' security keys before trading resumed. It is dated recovery evidence, not a standing guarantee of current vault or signing safety.

A liquidity withdrawal that takes one side of a pool rather than both sides proportionally. Availability can be controlled separately by live Mimir pause keys.

A trust label for live Midgard or THORNode data that should be treated as a fresh snapshot, not durable historical truth.

Operational parameter storage used by THORChain nodes. Halt, pause, enablement, and feature-control keys must be read from live THORNode state.

A node-governed runtime value. A Mimir may override a compiled constant or exist without a matching constant, so current behavior requires comparing the constants table with fresh live Mimir state rather than assuming every key is an override.

A current THORNode record containing an active Asgard address plus chain-specific router, gas-rate, dust, and pause fields. It must not be cached or reused across churns; re-fetch it immediately before constructing a transaction, and do not treat it alone as quote, signing, outbound, or settlement proof.

A short-lived THORNode simulation response for a specific swap request. It returns transaction inputs and estimates such as the inbound address, memo, expected output, fees, expiry, dust threshold, and recommended minimum input; it does not sign, broadcast, or prove settlement.

The quote response timestamp after which its inbound address, memo, estimates, and warnings must not be used. Official guidance treats quotes as valid for only ten minutes and says to request a fresh quote immediately before transaction submission.

A per-chain minimum inbound amount required for THORChain to process a transaction; amounts below it are ignored. Treat the exact value as live chain-specific evidence from a fresh quote or inbound-address response, not a static universal minimum.

An optional swap memo address for returning the inbound asset when execution refunds. It must be valid for the inbound asset chain; when omitted, or invalid in the quote flow, the refund falls back to the original sender. It selects a destination, not a refund cause or delivery proof.

A swap split into sub-swaps to reduce slip and allow pool rebalancing. With the advanced queue, market swaps auto-stream by default, interval 0 enables rapid execution, interval 1 or more spaces sub-swaps by blocks, and quantity 0 lets the network choose; live queue controls and transaction evidence still own actual behavior.

Validator signing failures or failed signing rounds. Exploit Report 2 says many deliberate MTA failures looked like ordinary node flakiness in isolation, so key-sign failure claims need dated incident context and current monitoring evidence.

A vault treated as unsafe or excluded after key-compromise evidence. Post-exploit upgrade notes discuss compromised-vault exclusion, but current vault status still needs live protocol and incident-source checks.

A THORChain vault controlled by the active validator set through threshold signing. Vault membership changes during churns.

The chain-client layer active nodes use to observe external-chain transactions and submit observations into THORChain.

A Cosmos bank asset minted from deposited L1 assets, representing shares of deposited-asset depth and usable by accounts, IBC, and CosmWasm. The high-level and developer docs differ on whether this replaces Trade Assets or Trade Accounts; neither wording proves module removal, conversion, or current availability.

A 1:1 L1-backed balance held outside liquidity pools in THORChain's trade-account module for fast trading flows. Trade assets use `CHAIN~ASSET` notation; enablement and route availability are live controls.

Threshold Signature Scheme. Validators jointly sign vault transactions without a single node intending to hold the complete private key; current scheme and safety claims require dated incident, release, and live evidence.