RUNEPool And POL Evidence

RUNEPool lets RUNE providers participate in protocol-owned liquidity (POL). That makes it easy to overstate: a single RUNEPool number can describe current accounting, but it does not prove future yield, safety, route health, or that deposits and withdrawals are available after the checked block.

Use this as an evidence ladder for RUNEPool/POL claims, not as wallet instructions.

Mechanism: RUNEPool is aggregate exposure to POL-enabled pools, not a user-selected single pool.
Current accounting: /thorchain/runepool can show global POL, provider, and reserve fields such as value, pnl, and current_deposit in RUNE base units.
Current availability: Mimir and network diagnostics can show whether RUNEPool or its deposits and withdrawals are halted.
Pool scope: POL-<Asset> Mimir keys identify the live pool set; it is not a static guarantee or fixed count from an overview page.

If the question is "can I deposit or withdraw now?", start with /network#network-diagnostics. If the question is "what is the position worth?", use the live RUNEPool/POL snapshot, the current THORNode RUNEPool endpoint, and the checked time attached.

RUNEPool Versus LP Positions

RUNEPool is not the same thing as a normal LP position:

Ordinary LP: the user owns liquidity units in one pool and may add or withdraw with pool-specific, chain-specific, asymmetric, and memo-shape constraints.
RUNEPool provider: the user supplies native RUNE into a RUNEPool accounting system that shares aggregate exposure across POL-enabled pools.
Protocol-owned liquidity: the protocol side of the aggregate position can move between reserve, pending, and deployed units.

Official developer docs describe RUNEPool participants as exposed to RUNE plus all POL-enabled assets in aggregate. That makes "RUNEPool yield" shorthand risky. Better wording is: "The checked RUNEPool snapshot reports provider value/PnL under the current POL accounting model."

Evidence Ladder

Use Network diagnostics for operation state, a same-provider same-height RUNEPool read for accounting, current Mimir for the POL pool set, and the per-provider endpoint only with an intentionally shareable address. Treat missing or malformed money fields as unavailable, never zero; a skipped source makes the claim partial.

Availability Checks

RUNEPool current-use claims need operational evidence:

RUNEPOOLENABLED answers whether RUNEPool is enabled by current Mimir state.
RUNEPool deposit and withdrawal halt controls answer whether the action appears paused in the checked snapshot.
RUNEPoolDepositMaturityBlocks can affect when a provider is allowed to withdraw after deposit.
RUNEPoolMaxReserveBackstop can constrain withdrawals when reserve backstop limits would be exceeded.
Source warnings, stale blocks, unpinned sources, and malformed Mimir values should degrade the claim even when a known blocker is visible.

Do not collapse these into "THORChain is paused." Say "RUNEPool deposits are halted", "RUNEPool is disabled", or "RUNEPool status needs source review" when that is what the evidence supports.

Accounting Checks

The global RUNEPool endpoint can report three accounting buckets:

pol: protocol-owned-liquidity totals such as deposited RUNE, withdrawn RUNE, current value, PnL, and current deposit.
providers: aggregate independent-provider units, pending units, pending RUNE, value, PnL, and current deposit.
reserve: reserve-side units, value, PnL, and current deposit.

Those fields are RUNE-denominated base-unit values. A dashboard can display them if it keeps source freshness and field availability visible. It should not turn a missing pnl or value into zero, and it should not use one current snapshot as proof that RUNEPool is profitable, safe, or outperforming ordinary LP positions.

The developer docs also state that current_deposit is rune_deposited - rune_withdrawn and can be negative. A negative value is therefore valid accounting evidence, not a parser error or an instruction to clamp the field to zero.

A valid endpoint does not prove that deposits are open, that every POL pool is deep, or that checked PnL predicts future yield. RUNEPool, POL, ordinary LP positions, secured assets, trade accounts, and archived Savers/Lending remain distinct; public position queries also need address-privacy review.

Reserve Income Direction (August 2026 Context)

Two August 2026 governance threads affect how reserve income interacts with POL, but neither is a settled accounting change yet:

See the Incentive Pendulum deep dive for how reserve income interacts with the bond-to-stake reward allocation.

ADR-027/ADR-029 (REVSHARE) proposes paying per-thorname shares of attributed swap liquidity fees out of reserve system income before other splits run. Numbering differs by source: the thornode repo files it as ADR-027 (Proposed) and merged MR #4779 points to that doc, while official blog posts label the same mechanism ADR-029 and report the vote as passed. Cite the source you used; live payout Mimirs remain absent at last check.
A community vote on redirecting the system-income burn toward the POL reserve was reported after the v3.20.0 upgrade. Treat it as an open proposal until release notes, Mimir keys, or official docs confirm the outcome; do not rewrite the burn or POL funding model from chatter alone.

For either thread, keep the evidence order: dated ADR or release first, then live Mimir and RUNEPool snapshots. A vote headline is not an accounting invariant.