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.

1. Mechanism: RUNEPool is aggregate exposure to POL-enabled pools, not a user-selected single pool.
2. Current accounting: /thorchain/runepool can show global POL, provider, and reserve fields such as value, pnl, and current_deposit in RUNE base units.
3. Current availability: Mimir and network diagnostics can show whether RUNEPool or its deposits and withdrawals are halted.
4. 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)

The following describes August 2026 governance context, not a claim that POL funding remains an open proposal today:

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

• REVSHARE review, 27 October 2026: the pinned repository ADR-027 remains labelled Proposed, and implementation MR #4779 is merged. The official Q3 report, published 23 October, calls it ADR-029, reports August approval and describes a planned 20% SwapKit trial starting when SwapKit is ready. This updates the REVSHARE evidence within this historical section; neither that report nor merged code proves current payout settings, trial activation or payments. No live Mimir observation was made for this review.
• A community vote on redirecting the system-income burn toward the POL reserve was reported after the v3.20.0 upgrade. By September 1, Discord reporting said POL was already deployed and working. This supersedes August-only open-proposal framing, but does not independently establish the current funding percentage, allocation algorithm, or burn setting. The targeted review was performed on September 30, 2026; check dated releases and current Mimir/RUNEPool evidence before making present-tense accounting claims.

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.