Skip to content
⬡
THORChain Wiki
\u2190 All Deep DivesEdit this page on GitHub \u2192
Deep DiveCurated

The Incentive Pendulum

Automatic reward balancing between node bond security and pooled liquidity, with current APY and health claims kept live-source dependent.

About this article's sourcing
CuratedChecked 2026-07-14·
THORChain economic model
retrieval details
Source retrieved 2026-07-14Official Incentive Pendulum, emission, and reserve-flow design; its original 500M maximum-supply framing must not be presented as the newer tokenomics page's current approximate supply.
+3 sources
Network security and governance
retrieval details
Source retrieved 2026-07-14Official security/governance overview for the Incentive Pendulum and approximate 2:1 bonded-security-to-liquidity target; live ratios and reward splits need current evidence.
THORChain Docs
retrieval details
Source retrieved 2026-07-05Official documentation root used for curated protocol background; it still describes GG20 at review time, but current safety and migration state require dated incident and release sources.
Midgard v2 Network
retrieval details
Source retrieved 2026-07-05Current-only network totals; pair with visible source freshness before treating values as live.

Use this article for: A mechanism guide for explaining THORChain incentive balancing without turning design incentives into live yield, APY, revenue, or price claims.

Verify elsewhere before claiming: Current Midgard health, visible metric source, earnings intervals, APY calculation, reward distribution, token value, and whether the claim is a design incentive or measured outcome.

Stats decision panelDynamic-fee trackerNetwork diagnosticsCurrent source mapWhy these checks

The Incentive Pendulum

The Incentive Pendulum is THORChain's reward-balancing mechanism. It adjusts reward distribution between node operators and liquidity providers based on the network's bond and liquidity posture.

Use it to understand incentive alignment. Do not use it as proof of current APY, fair value, route competitiveness, or network health without live data.

This design balances security capital and liquidity capital through reward allocation, moving rewards toward the comparatively under-supplied side; 2:1 is a commonly cited design target. It does not prove any current-state health, yield, price, or route claim.

The Core Problem

THORChain needs two things to function:

  1. Security — Enough bonded RUNE to secure the network via node operators.
  2. Liquidity — Enough pooled capital, including the RUNE side paired with external assets, to support useful cross-chain markets.

If either side gets too low, the system becomes vulnerable or unusable.

How the Pendulum Works

Official docs describe the mechanism in terms of bonded RUNE versus pooled liquidity or staked capital. Because those pages use slightly different shorthand, treat 2:1 as a design target rather than a license to substitute any one dashboard field for the full ratio.

  • When bonded security is low relative to pooled liquidity: The model shifts more of the reward allocation toward node operators.
  • When pooled liquidity is low relative to bonded security: The model shifts more of the reward allocation toward liquidity providers.

This creates a self-correcting feedback loop — the "pendulum" swings toward whichever side the network needs most at any given time.

Official docs frame the target around bonded security versus pooled liquidity, commonly described as a 2:1 bond-to-stake ratio. That target is design framing; live bond, pooled RUNE, reserve, APY, and reward-split values should be read from current source-labeled data.

Why It Matters

Without this mechanism, maintaining healthy bonding and liquidity ratios would require more manual intervention. The Incentive Pendulum is designed to make reward allocation adaptive as market conditions change.

Practical Effects

  • The intended direction is toward whichever side the model treats as comparatively under-supplied.
  • A current reward split, bond ratio, or APY must be read from current source-labeled data rather than inferred from market regime.
  • The economic-model page still carries original 500M maximum-supply framing, while the newer tokenomics page gives an approximate 425M and burning supply. Neither number is an output of the pendulum, and the two source contexts should remain visibly separate.

The Incentive Pendulum is best treated as an incentive-alignment mechanism rather than a guarantee of network health or returns.

Evidence Ladder

Separate design sources from live economics: official docs explain the model; source-labeled stats supply pooled RUNE, reserve, bonding APY, node count, and earnings coverage; Network diagnostics supply the operational state. Do not upgrade a design source into health, yield, price, or route proof. For how RUNE settlement interacts with the pendulum-driven reward allocation, see the RUNE Settlement deep dive.

Common Misreadings

  • "The pendulum exists, so the network is healthy." The mechanism is a design control. Health still depends on current bond, liquidity, node, source, and operational state.
  • "High bonding APY proves bonding is the best return." APY is current-only, source-dependent, and not realized yield or investment advice.
  • "The 2:1 target means the ratio is always exactly 2:1." The target describes an incentive direction, not a guarantee that market behavior will keep the ratio fixed.
  • "More LP rewards mean every route is attractive." Reward allocation does not prove pool depth, slippage, quoteability, settlement, or chain availability for a specific route.
  • "Reward split proves protocol revenue lift." Reward distribution and revenue attribution are different claims and should not be mixed without source-backed earnings data.
  • "Bond rewards and LP rewards are equal." The 2:1 target is a design ratio for incentive alignment, not an outcome. Actual reward splits depend on current bond, pooled liquidity, and the pendulum active state; equality is not guaranteed.

Current APY, realized yield, RUNE value, route quality, and revenue attribution are separate claims. Check source health, provider identity, and live operations before treating a reward number as actionable.

Glossaryeconomicsrewards
Reader paths for this article

Use these paths to connect this explainer with the current-state checks needed before making live protocol claims.

View all paths
Swap Economics

Readers comparing settlement, slip, liquidity, rewards, and fee signals.

Step 6 of 7

Verify Before Claiming

  • Current liquidity depth, APY, and earnings coverage from live Midgard snapshots.
  • Current RUNEPool enablement, provider PnL, POL-enabled pool scope, or deposit/withdraw availability.
  • Whether a fee claim is ordinary fee mechanics or the ADR-026 dynamic-fee experiment.

Continue This Path

Continue with Slashing and Economic Security before treating this path as complete.

Swap Economics step 6/7
Previous in pathStreaming Swaps And RefundsNext in pathSlashing and Economic Security
Liquidity Actions

Readers deciding how to describe LP adds, withdrawals, pool-deposit pauses, asymmetric withdrawals, or LP metrics without making wallet-flow claims.

Step 6 of 6

Verify Before Claiming

  • Current LP action, pool-deposit, asymmetric-withdrawal, RUNEPool, and source-warning state.
  • Whether the claim is about availability, memo shape, RUNEPool/POL accounting, pool data, historical transaction evidence, or future yield.

Continue This Path

This is the final article in this path; use the follow-up checks before making live or current-state claims.

Liquidity Actions step 6/6
Previous in pathMidgard And THORNode Data
Path completeMove to the follow-up checks above.

Browse All Deep Dives

Article library order, separate from reader-path order.

Previous in libraryStreaming Swaps And RefundsNext in libraryThreshold Signatures (TSS)

Related Reading

RUNEPool And POL EvidenceHow to read RUNEPool and protocol-owned-liquidity evidence without turning current accounting into yield, safety, or availability claims.