RUNE is the security budget, not a “DEX token”

THORChain is a Cosmos-SDK Layer 1 that executes native cross-chain swaps across multiple external chains without wrapped assets or centralized intermediaries. The key design choice is that every supported asset routes through RUNE as the hub asset, so the network’s throughput and safety both end up priced in RUNE.

In product terms, that means two things. First, users can swap BTC→ETH (or similar) by sending BTC to a THORChain vault address and receiving native ETH out, without ever needing to hold RUNE themselves. Second, liquidity is organized as continuous liquidity pools where each external asset is paired with RUNE (BTC-RUNE, ETH-RUNE, and so on).

RUNE’s “tokenomics” are therefore not mainly about retail supply narratives. They are about maintaining a credible, durable security budget that can continuously pay validator operators to custody large external-asset vaults with TSS signing, where a supermajority is required to act.

Security budget mechanics: bonding, caps, and the Incentive Pendulum

THORChain validators are “node operators” who bond RUNE to participate. Bond is not cosmetic. It is the economic backstop that makes it irrational for a quorum to steal, because they can be punished and because their bonded capital is at stake.

The network enforces a minimum bond via Mimir. On mainnet today, MINIMUMBONDINRUNE = 300,000 RUNE (value is expressed in 1e8 units in the Mimir endpoint). This is not a marketing number. It is a coarse lever on who can even enter the validator set, and it directly interacts with decentralization pressure and operator ROI.

THORChain also caps bonding influence so no single validator can dominate by simply bonding more. The docs describe this as “capped proof of bond,” and explicitly note there is no protocol-level delegation in the sense of liquid, permissionless staking to a validator. In the Incentive Pendulum implementation, this shows up as concepts like a “bond hard cap,” “total effective bond,” and “effective security bond,” which are used to compute reward shares while limiting the marginal reward power of the largest bonds.

The Incentive Pendulum is the core balancing engine. It splits “total rewards” between node operators and liquidity providers based on how much RUNE is bonded versus how much liquidity is being secured in vaults and pools. “Total rewards,” as specified in the dev docs, are block rewards plus liquidity fees within the block after the burn and system-income allocations (Dev fund, TCY share) are deducted.

Two security-relevant constraints matter more than the headline “2:1” narrative.

First: the Pendulum Reward Cap. If bonded security (“securing”) is less than or equal to secured liquidity (“secured”), the protocol can set liquidity provider rewards to zero. That is a blunt instrument, but it is honest. When the network is meaningfully undersecured, paying LPs to add even more at-risk liquidity is the wrong move for safety.

Second: the TVL Cap exists independently of the Pendulum. The dev docs describe a configurable TVL cap that rejects further liquidity additions when pooled liquidity exceeds a threshold relative to bonded RUNE. This is a direct admission that “incentives only” is not enough. Hard admission controls are part of the security budget toolkit.

Supply, allocations, and what “max supply” actually means for RUNE

THORChain’s economic model docs state there are 500,000,000 RUNE maximum, and that the full supply was created at genesis and distributed across categories including seed/IDO, developers, bootstrapping, and a protocol reserve. It also states that vesting has been completed.

In live market data, CoinGecko still labels Max Supply = 500,000,000, while showing Total Supply = 424,780,853 and Circulating Supply = 351,141,445 on March 6, 2026. The docs also describe RUNE supply as reduced by ongoing burns and present-day totals around ~425M.

Practically, you should treat “500M” as a historical genesis ceiling and “~425M and declining” as the relevant effective cap if the system is in a no-net-mint regime. The difference matters for security analysis. A shrinking supply can help holders, but it removes a classic escape hatch: inflation-funded security when fees are weak.

Genesis distribution (as documented):

Two burn-related events are explicitly called out in THORChain community writeups about supply. They report a BEP2/ERC20 “killswitch” removing 13.9M RUNE in July 2023 and a burn of 60M RUNE standby reserves in March 2024.

Emissions: the reserve is no longer a reliable security subsidy

From a security budget maximalist lens, the single most important change in THORChain tokenomics is the effective shutdown of inflationary block rewards. For contrast, compare this with OP tokenomics.

The Economic Model documentation gives the block-reward formula and notes that the EmissionCurve is currently set to 100,000, making block rewards minimal, on the order of ~720 RUNE per year. The live Mimir endpoint confirms EMISSIONCURVE = 100,000 today.

Community supply notes also state the reserve “stopped emitting block rewards” in February 2025. A separate tokenomics recap likewise says block rewards were “switched off entirely” in February 2025.

Those statements are directionally consistent with what you see on-chain: the EmissionCurve being pushed to 100,000 turns the reserve into a rounding error for emissions. That is good for dilution optics. It is also a hard constraint on long-term security spending if fees fall or if the network has to raise validator payouts to maintain honest participation.

Fees and fiscal flows: who gets paid, who gets burned, who gets undersecured

THORChain’s fee design is multi-part. The docs separate inbound L1 gas (paid by the user on the source chain), liquidity fees (slip-based, compensating LPs), affiliate fees (optional integrator fee), and outbound fees (destination-chain gas times a dynamic multiplier, covering protocol overhead). Transactions on THORChain itself also incur a Native Transaction Fee of 0.02 RUNE.

The important part for RUNE tokenomics is “system income” allocation. THORChain’s tokenomics page documents the current distribution as:

Those percentages are not just blog-level narrative. You can see the underlying knobs in the network constants and Mimir overrides. For example, the live Mimir setting SYSTEMINCOMEBURNRATEBPS = 500 implies a 5% burn. The network constants include DevFundSystemIncomeBps = 500 and MarketingFundSystemIncomeBps = 500, each representing 5% in basis points. The constants also include TCYStakeSystemIncomeBps = 1000, representing the 10% TCY revenue share.

From a security-budget standpoint, TCY is not a side quest. TCY is explicitly entitled to 10% of all system income when staked, with the share set by TCYStakeSystemIncomeBps.

That diversion has a direct mechanical effect: it reduces the share of system income available to the two actors that actually secure user funds day-to-day, validators and liquidity providers. If you like deflation, you should still be honest about the trade. Burns and external claimants both compete with validator ROI. If fees do not grow, something else has to give. Usually, that “something” is bond. For a separate case study to compare, see GRT tokenomics.

Governance and parameter control: minimalism, with powerful runtime levers

THORChain governance is intentionally narrow. The docs emphasize minimal governance to reduce coordination and collusion risk, while still supporting asset and chain listing/delisting, upgrades, and parameter management. For a broader evaluation framework, see our tokenomics methodology.

The real policy surface for tokenomics is Mimir. The developer docs describe “constants” whose values can be overridden via Mimir, and note that nodes can vote to change Mimir values. In practice, Mimir controls security-critical and economics-critical thresholds: minimum bond, emission curve, fee floors, halts, and a large set of operational risk switches.

This has two implications. First, “tokenomics stability” in THORChain is always conditional on node consensus. The effective monetary policy can change quickly, because the levers are runtime parameters, not multi-month governance pipelines. Second, the chain’s safety model treats supermajority behavior as the operational norm. For example, the tech docs describe 67% agreement for connected-chain transaction observation and finalization.

Finally, governance also includes formal design records. THORChain uses Architecture Decision Records (ADRs) to propose and document high-level changes. The ADR index lists major economic and security decisions, including the lending-era reserve burn (ADR-012) and the system-income burn lever (ADR-017).

Key tokenomics policy shifts (dates that changed the model)

November 2024: a 5% burn on system income is described as enacted starting in November 2024. The v3 release note also describes burning 5% of system income each block as a deflationary mechanism.

March 2024: community supply notes report burning 60M RUNE of standby reserves in March 2024. ADR-012 documents the “standby reserve” as 60,000,000 RUNE and proposes burning it.

February 2025: community documentation states block rewards were switched off entirely in February 2025, and supply notes say the reserve stopped emitting block rewards in February 2025. The network’s current EMISSIONCURVE setting of 100,000 is consistent with making reserve emissions negligible.

May 5, 2025: TCY launched as a claims token for THORFi creditors, with 10% of all system income paid to TCY stakers in RUNE.

August 2025 onward (proposal surface): a marketing-fund ADR proposes allocating 5% of protocol revenue to marketing, with the exact percentage controlled by node Mimir. Regardless of proposal status, the current constants already include a marketing-fund system-income allocation of 500 bps (5%).

Risk analysis: fee-constrained security is now the whole game

Once you remove meaningful issuance, you remove the protocol’s ability to buy security during fee drawdowns. That is not automatically “good tokenomics.” It is a conscious choice to make security spending pro-cyclical with demand. For practical building blocks, see our design components.

THORChain is explicit that rewards to validators and liquidity providers now come from fees, with burn and other system-income allocations reducing what remains for security and liquidity incentives. The Incentive Pendulum then reallocates the remaining reward pie to correct imbalances between bonded RUNE and secured liquidity.

Top 3 risks

  1. Security budget drawdown in a fee slump (dominant risk). Trigger: sustained decline in system income (swap volume, fee rates, or both) while burns and fixed basis-point allocations still apply. Mechanism: lower net rewards to node operators reduce the ROI of bonding, so bonded RUNE trends down, while the network may still be securing meaningful vault liquidity; at the extreme, the Pendulum Reward Cap can zero LP rewards to discourage liquidity growth, but that does not automatically restore bond. Who bears it: end users (execution safety, liveness risk), LPs (rewards volatility), and RUNE holders (reflexive risk via lower trust in custody security). Measurable indicators: falling bonded RUNE, rising vault-liquidity-to-bond ratios (Pendulum state drift), and persistent low EmissionCurve-driven issuance leaving no emission backstop.
  2. Parameter risk from powerful runtime governance. Trigger: contentious conditions (market shock, exploit response, liquidity flight) that motivate rapid Mimir changes. Mechanism: changes to fee floors, halts, emission curve, or bonding thresholds alter incentives faster than capital can reallocate safely, creating discontinuities in validator participation or liquidity provisioning. Who bears it: integrators and power users first (quote stability, routing), then LPs and node operators (sudden yield regime shifts). Measurable indicators: abrupt shifts in Mimir values (especially EmissionCurve, MinimumBondInRune, fee-related Mimirs) and elevated usage of halt flags.
  3. Security dilution from non-validator revenue claims. Trigger: expanding or sticky system-income allocations to burns and third-party claimants (for example TCY’s 10% share). Mechanism: even if gross fees are stable, the net share available to validators and LPs compresses, lowering the protocol’s ability to pay for bond and liquidity depth; the Pendulum can only re-split what remains, it cannot create new budget. Who bears it: node operators directly (lower income) and users indirectly (weaker security margins). Measurable indicators: system-income allocation parameters (burn rate, TCY share, fund bps) and declining bonded-RUNE persistence during flat fees.

Dominant risk: fee-constrained security has no “Plan B” anymore

THORChain is choosing a hard line. Minimal emissions. Deflation via burn. Revenue share carve-outs. All of that can be coherent, but only if the remaining net system income is sufficient to keep bond high across cycles.

The mechanical issue is that security in THORChain is not abstract. Validators custody external assets in vaults and need to be continuously compensated to run complex infrastructure, manage external-chain full nodes, and sign outbounds under threshold signature schemes. The chain also relies on supermajority behavior for observation and finalization in connected-chain flow. This is an expensive security model. It is worth it when volume is there. It gets fragile when incentives compress.

In an issuance-funded model, the protocol can subsidize validator income while it waits for fees to mature. THORChain has largely removed that lever by setting EMISSIONCURVE to 100,000, making reserve emissions negligible. The docs themselves frame current block rewards as minimal. So the system is now fee-first in a very literal sense.

That shifts the burden onto two adaptive mechanisms.

One is the Incentive Pendulum, which can redirect rewards toward nodes when the network becomes underbonded. This helps, but it is not magic. The Pendulum cannot increase the absolute reward pool. It only reallocates the net pie after burns and system-income allocations are removed.

The other is admission control. The Pendulum Reward Cap can zero LP rewards in unsafe states, and the TVL cap can reject further deposits if pooled liquidity grows beyond safe proportions. Those are defensive tools. They reduce the rate at which the network takes on additional liabilities. They do not directly increase bond if validators are still underpaid relative to their operational and tail-risk costs.

The cleanest way this risk shows up is as a “slow leak,” not an instant crisis. Fees soften. Reward expectations reset lower. Some operators churn out. Bond trends down. Once bond trends down, the network must either (a) accept lower secured liquidity by enforcing caps and discouraging LPs, or (b) accept thinner security margins. Both harm product competitiveness. Neither is free.

That is the trade-off THORChain has made by moving to fee-only economics while keeping a burn and adding additional system-income claims. The model can work. It just has less slack than many holders want to admit.

If you are doing tokenomics consulting or token economy design work around fee-only security models, the THORChain case is a useful reference point because the constraints are explicit and on-chain tunable via Mimir.



This article is part of our Tokenomics Deep Dive series.