6.6.1 Treasury “surface area” and what it implies about governance capacity

Terra Classic’s effective financial governance is defined by a small set of on-chain balances and flows that function as the chain’s “operating budget” and “security budget”:

1. Community Pool (on-chain treasury)

• Holds protocol-owned assets used to fund development, operations, incentives, and one-off initiatives.

• This pool is governed by on-chain proposals (community pool spend / distribution semantics), i.e., governance is effectively the treasury committee (with all the known strengths and weaknesses of token-vote governance).

2. Oracle Rewards Pool (validator/oracle incentive reserve)

• Acts as a security-relevant budget line: it compensates validators for oracle voting, which underpins price-dependent modules and swap pricing assumptions.

• Functionally: if oracle economics deteriorate, validator participation quality can degrade (or become “checkbox voting” with weaker incentives), increasing tail-risk for any on-chain component relying on oracle integrity.

3. Protocol fee & tax routing (implicit treasury/incentive policy)

• How transaction taxes, swap fees, and other protocol revenues are split across burning, community pool funding, oracle incentives, and staking yields determines who gets paid to do what, and therefore which activities are sustainable.

Key takeaway: Terra Classic’s treasury story is not “how many tokens exist,” but whether the chain has a credible, consistent capital allocation function (budgeting, prioritization, audits, accountability). The evidence below indicates this function is currently weak or structurally constrained.

6.6.2 Community Pool: balance snapshot and what it can realistically fund

Balance snapshot (from Terra Classic documentation pack provided):

• Community Pool: ~186.34B LUNC and ~163.38M USTC (snapshot shown in materials).

• For context, the same pack lists an Oracle Rewards Pool balance of ~163.28M USTC (snapshot shown in materials).

• A large nominal LUNC balance is not automatically “funding power.” Funding power depends on:

  • feasible sell pressure (market impact constraints),

  • governance throughput (ability to approve budgets quickly),

  • compliance risk for off-chain execution (contracting, custody, payments),

  • and whether spend translates into measurable on-chain demand improvements (see 6.3).

Key takeaway: The treasury exists, but its ability to convert assets into sustained demand and security is the core variable—and it is primarily an operational/governance capability question, not a “balance” question.

6.6.3 Expenditures and investments: a dormant treasury, lumpy disbursements, and maintenance-heavy allocation

6.6.3.1 What the dashboard actually measures (and why it’s unusually revealing)

Truth Dashboard’s “Expenditures and investments” view is not a marketing-style treasury summary. It is closer to a capital allocator audit:

• Weekly Community Pool balances (LUNC + USTC) and “spend bars” anchored to pre-drop marker weeks.

• A mapped outflow table (proposal → recipient → amount → interval) with an “impact %” that expresses how large the drop is relative to the pool at that time.

• Treasury-behavior diagnostics: idle weeks share, median gap between spends, longest inactivity streak, top spend share, Gini coefficient, and a “bursty index.”

This is critical because it lets us evaluate two separate realities that most chains conflate:

1. How big the treasury is (stock), and

2. How it behaves as an allocator (flow + cadence + concentration + targeting).

6.6.3.2 The “not used” problem is visible in the utilization + inactivity metrics

Across the key analysis windows, the dashboard shows a treasury that is idle most of the time, and therefore not functioning like an operating budget.

2-year window (the most relevant window for “post-revival” execution quality):

• Outflow summary: ~4.835B LUNC out across 13 spend intervals; USTC outflow = 0 in this window.

• Max combined impact: 15.94%.

• Idle weeks: ~87.6% of weeks show zero outflow.

• Median gap between spends: 5.5 weeks; longest inactivity streak: 19 weeks.

Interpretation:

• When the largest mapped outflow over two years reaches only 15.94%, that implies that even in the “biggest spend moment,” at least ~84% of the pool remained un-deployed (by construction of the metric).

• Combine that with ~88% idle weeks, and the message is simple:
  the dominant treasury strategy is “hold funds and occasionally release a lump,” not continuous investment.

That is a strategic failure mode when (per 6.3) demand is structurally down: you need iteration loops, not sporadic payouts.

6.6.3.3 The “lumpy allocator” problem is confirmed by concentration statistics

Even when the Community Pool does spend, the distribution is highly unequal across time—a handful of proposal-weeks dominate the whole story.

2-year window concentration (again, the most decision-relevant):

• Top spend share (1 / 3 / 5 weeks): 30.4% / 68.4% / 84.0%

• Gini coefficient: 0.59 (high inequality of spend across weeks)

• 80/20 spend weeks: 5 weeks account for ~80% of spend (dashboard’s derived indicator).

Meaning (not “governance aesthetics,” but economics):

• A lumpy allocator creates timing risk (projects wait for windows, then rush), political/narrative capture risk(each big spend becomes a referendum on factions), and reputation fragility (each lump must “work,” because there aren’t many small continuous programs to average outcomes).

• When you combine high inactivity with high concentration, you get a treasury that behaves like a vault—not like a budget.

6.6.3.4 What the Community Pool actually spent on (and why it supports the “wrong things” thesis)

If you look at the mapped outflow table in the corrected dashboard, the biggest and most frequent categories are overwhelmingly maintenance + plumbing, not user acquisition / product demand engines.

Below is a taxonomy using the dashboard’s own spend titles (examples are illustrative, not cherry-picked—these are some of the largest and most recent entries in the table).

A) Core protocol maintenance (necessary, but not growth)

Large spends are directed to:

• Cosmos SDK + IBC upgrades (e.g., “Upgrade to Cosmos SDK v0.53 with IBC v2 (Eureka)”) ~1.046B LUNC, impact 12.32%.

• Forked module removal (OrbitLabs phases), including a 500M LUNC tranche (impact 6.18%) and earlier “phase 1” work.

• Governance module work / audit / dev compensation (multiple small-to-mid entries).

Why this matters: these are “keep-the-chain-running” line items. They can be justified as table stakes, but they do not automatically create new demand. If this dominates spending, treasury becomes a maintenance subsidy, not a growth allocator.

B) Network plumbing externalities (relayers) — again, necessary, not growth

Example:

• Fund IBC relaying activity (~254.6M LUNC, impact 3.31%).

Relayers are infrastructure obligations for IBC-connected chains. Paying for them is not “investment alpha”; it’s preventing functional degradation.

C) Liquidity injections (symptom treatment)

The largest single 2-year impact event is explicitly liquidity provisioning:

• “Inject Liquidity for Terraswap DEX … Proposal 12171” ~1.468B LUNC, 15.94% impact.

• “Inject Liquidity for Garuda DeFi … Proposal 12171” ~792M LUNC, 10.21% impact.

Why this supports thesis:

Liquidity injections can improve tradability inside Terra Classic for a time, but they are often non-durable if not paired with:

• real user demand,

• distribution,

• product value that retains wallets,

• or ongoing incentives tied to measurable usage outcomes.

So they tend to be support operations—not demand creation. In capital allocator terms: these are frequently defensive spends.

D) Legacy USTC-era actions (important context, but mostly outside the 2-year “execution quality” window)

In the ALL window, the dataset includes massive USTC events early post-collapse (e.g., “Burn The Remaining UST in the Community Pool …” and the grants program entry), with very high impact % (95–99%).

These are historically important, but they do not contradict current argument: the question today is whether the treasury is being used to rebuild durable utility now—and the 2-year window shows it is not.

6.6.3.5 The two core problems, now backed by corrected metrics

Problem 1 —

Misallocation: spend is dominated by maintenance and defensive measures

From the spend titles and the largest-ticket items, the treasury’s revealed preference is:

• Upgrades, removals, audits, governance fixes, relaying

• plus episodic liquidity injections
  …with no visible programmatic category that looks like a sustained demand engine (e.g., continuous builder grants with KPI gates, user incentives with retention targets, BD/distribution with measurable conversion, etc.).

Put bluntly: capital is being used to keep Terra Classic technically alive and intermittently liquid, not to make it economically necessary.

Problem 2 —

Under-deployment: the treasury largely sits idle

This is not a vibe. The corrected dashboard prints it:

• ~87.6% idle weeks in the last 2 years, with a 19-week longest inactivity streak.

• Even the largest 2-year outflow is only 15.94% impact, implying ≥84% of the pool remained unused even at the high-water mark of treasury action.

This combination is devastating in a down-demand environment (6.3):

• If usage is collapsing, a treasury must behave like an adaptive operator (continuous experiments, tight feedback loops, staged budgets).

• Instead, it behaves like a static reserve (hold → occasional lump).

6.6.3.6 What this means for 6.6’s broader thesis (treasury quality → investor outcomes)

Given 6.3’s demand collapse, the Community Pool should be the primary lever to fund:

• friction removal for builders,

• product ecosystems that create repeat usage,

• and incentives that are measured and iterated.

Instead, the corrected “Expenditures and investments” evidence supports a different conclusion:

Terra Classic’s Community Pool is acting like a dormant vault that intermittently funds maintenance and defensive actions, with high inactivity and high concentration, rather than a disciplined allocator funding durable demand creation.

Key takeaway: The treasury problem is not “insufficient funds.” It is (1) under-deployment and (2) maintenance-heavy targeting—a capital allocation posture that cannot realistically reverse a structural demand downtrend without an explicit operating-model change.

6.6.4 Oracle Rewards Pool depletion: a security-budget warning signal

6.6.4.1 Current state and short-horizon trend (what the chain is actually signaling now)

As of early Feb 2026, on-chain dashboards and monitoring snapshots show the Oracle Pool at roughly:

• ~50.0B LUNC

• ~162–163M USTC

Recent observations also indicate the pool is net-depleting (outflows > inflows). Community monitoring notes a ~2.5B LUNC decline over roughly a month (mid-Jan → early Feb 2026), implying an order-of-magnitude depletion pace in the ~70–100M LUNC/day range under recent conditions (variable with fee activity and oracle reward distribution).

6.6.4.2 Historical trajectory since 2022 (directional but unavoidable context)

A complete “one chart to rule them all” for Oracle Pool history is hard to source publicly in a single canonical dataset, but wallet tracking + community reporting converges on the same arc: a multi-year, persistent downtrend since the May 2022 collapse and the chain’s post-fork reality.

Directional reconstruction (best available synthesis, not a single primary chart):

• May–Dec 2022: materially higher balances (often discussed as “massive” relative to today; commonly framed in the ~200–500B+ LUNC-equivalent range in community discourse around “borrowing” for liquidity or repeg initiatives).

• 2023–mid 2024: steady drawdown with limited replenishment; commonly referenced as ~150–200B early in the period.

• Late 2024 (Nov–Dec): ~92–93B LUNC and ~317M USTC are widely repeated community datapoints; daily depletion often cited around ~100M LUNC/day at that stage, with staking APR frequently discussed in the ~7–8%band.

• Mid-2025 (Aug): ~63.9B LUNC

• Early 2026 (Jan): ~52B LUNC

• Feb 2026: ~50B LUNC and ~163M USTC

Interpretation (with appropriate caution): even with partial mitigation efforts over time, the Oracle Pool appears to have declined ~75–90%+ from post-crash-era magnitudes (LUNC side), and ~50–60% on the USTC side. The exact starting point depends on which post-collapse snapshot is chosen, but the direction is consistent: the system has been consuming security budget for years faster than it can refill it.

6.6.4.3 Why the pool depletes (mechanics, not opinions)

The oracle system distributes rewards to validators who submit votes within a defined accuracy band around the median. In Terra’s oracle design, the reward amount is explicitly tied to pool size, amortized over a distribution window. In other words: the protocol is designed so the pool can fund rewards over time, but it expects meaningful inflows from fees and swap activity to offset depletion.

Key elements (conceptual, protocol-level):

• Validators vote frequently (vote periods), and accurate voters receive rewards.

• Rewards scale with the current pool balance—as the pool shrinks, the absolute payout shrinks too. This creates a tapering effect (a form of exponential decay): it “lasts longer” as it gets smaller, but yields can become negligible.

• The pool’s sustainability therefore depends on whether fee inflows (swaps, market activity, other routed revenues) are large enough to offset what the oracle mechanism pays out. When on-chain demand is structurally down (as shown in 6.3), this is exactly where the system breaks: the refilling engine is weak while the distribution engine keeps running.

This is why the Oracle Pool is best described as a security budget that reflects real economic throughput. When it trends down for long periods, it is a measurable symptom of insufficient on-chain fee generation.

6.6.4.4 Why this matters: Oracle Pool depletion is a chain security and functionality risk

Oracle incentives exist because oracle work is a public good with private costs. If incentives compress, the system risks sliding into lower-quality equilibria:

a.) Validator ROI compression and participation quality risk

If rewards fall while operational costs remain, validator economics deteriorate. This can lead to:

• reduced operational investment (monitoring, redundancy, uptime)

• weaker participation discipline (including oracle voting becoming “checkbox behavior”)

• validator churn or increased reliance on external revenue sources

b.) Oracle quality degradation → market module fragility

Oracle feeds underpin price-dependent logic. If oracle quality degrades, downstream risks rise:

• slower responsiveness during volatility

• greater dispersion in oracle submissions

• higher probability of edge-case failures in price-reliant modules

c.) Staking APR compression → delegator psychology and liquidity reflex

Staking APR is already low versus historical post-2022 ranges, and it is directionally linked to the same underlying economic constraint: weak on-chain fee generation. When APR compresses alongside weak price performance, delegators are more likely to:

• unstake (especially if the perceived opportunity cost rises)

• sell into liquidity windows

• rotate to ecosystems with stronger yield credibility and/or stronger growth narratives

This is how a “slow pool problem” can become a liquidity and confidence problem.

6.6.4.5 Why this matters: Staking APR is already low (net yield math):

With staking APR around ~4.1% in the same snapshot, commission becomes a first-order driver of investor outcomes.

Illustratively (gross APR × (1 − fee)):

• 20% fee → ~3.28% net APR

• 12.5% fee → ~3.59% net APR

• 8.8% fee → ~3.74% net APR

• 0% fee → ~4.10% net APR

At these levels, the absolute net-yield differences look small in percentage points, but they are material in relative terms(e.g., 3.28% vs 4.10% is ~25% less yield), which influences:

• Delegator behavior (fee-chasing and churn),

• Validator profitability (who can staff/operate professionally),

• Network resilience (whether operators maintain robust infra despite shrinking reward pools elsewhere).

6.6.4.6 What has been tried (and what the persistence of depletion implies)

The community has explored multiple approaches to slow or offset depletion—primarily by redirecting flows (tax/fees) or restoring fee-producing on-chain activity. Some secondary reporting notes that burn tax routing has been discussed/structured to split proceeds across burn, Community Pool and Oracle Pool.

Regardless of the specific routing ratios at any point in time, the empirical outcome is the same: the Oracle Pool is still net-depleting in 2026, which implies that mitigation to date has been insufficient relative to the scale of demand collapse documented in 6.3.

6.6.4.7 Key takeaway

The Oracle Rewards Pool is a real-time “stress gauge” for Terra Classic’s economic security. A multi-year downtrend—now sitting around ~50B LUNC—signals that the chain’s fee engine is not producing enough sustained throughput to fund core security incentives. Even if the pool is theoretically “long-lived” due to tapering mechanics, the practical risk is that rewards become too small to sustain high-quality validation and oracle participation, increasing systemic fragility precisely when the ecosystem needs credibility and execution capacity the most.

6.6.5 Staking APR compression and validator economics: investor yield vs chain security

6.6.5.1. Current staking APR is ~4.24% (snapshot).

From an investor-outcomes standpoint, staking APR is often framed as “yield.” But at L1 level it is also a security budget:

• Lower sustainable rewards (net of validator commission) can reduce validator ROI, which may:

  • increase reliance on external revenues (MEV, off-chain arrangements),

  • discourage professional operations,

  • or contribute to validator churn—especially if the token price is also weak.

6.6.5.2. Validator commission (“Fee”) distribution and why it matters for investor outcomes and chain security:

Validator commissions (listed as “Fee” on Validator Info) directly determine net delegator yield and shape validator operating economics—i.e., who can sustainably fund infrastructure, monitoring, upgrades, incident response, and oracle reliability over time.

What the data shows (commission dispersion):

• Commission levels span from 0% (marketing-led / “low fee” validators) up to at least 20% among major operators.

• High-voting-power validators can sit at the top of the commission range. In the snapshot, DutchLUNC and Allnodes show 20% fees, KuCoin LUNC Node shows ~12.5%, and LUNCLIVE shows ~8.8%.

• A large portion of the long tail clusters around “round” retail-friendly points (commonly 2.5%, 5%, 10%), consistent with competitive fee signaling rather than differentiated service tiers.

Why this matters when staking APR is already low (net yield math):

With staking APR around ~4.1% in the same snapshot, commission becomes a first-order driver of investor outcomes.

Illustratively (gross APR × (1 − fee)):

• 20% fee → ~3.28% net APR

• 12.5% fee → ~3.59% net APR

• 8.8% fee → ~3.74% net APR

• 0% fee → ~4.10% net APR

At these levels, the absolute net-yield differences look small in percentage points, but they are material in relative terms (e.g., 3.28% vs 4.10% is ~25% less yield), which influences:

• Delegator behavior (fee-chasing and churn),

• Validator profitability (who can staff/operate professionally),

• Network resilience (whether operators maintain robust infra despite shrinking reward pools elsewhere).

Economic interpretation (security budget vs “marketing fee” equilibrium):

• High-fee, high-stake validators can remain economically viable even as gross APR compresses—especially if they also benefit from scale efficiencies. This tends to stabilize incumbents, but it can also reduce the incentive to aggressively compete on service quality if delegators are sticky.

• Zero/low-fee validators often operate as acquisition engines (auto-compound, “0% fee”, airdrops) and can temporarily attract stake; however, sustaining professional operations at near-zero margin usually requires eitherexternal revenue or subsidization—both of which can be fragile in prolonged low-activity regimes.

How to connect it back to the report’s core claim (“economic gravity”):

When (a) gross staking APR is compressed and (b) incentive reserves like the Oracle Rewards Pool are under pressure, commission dispersion becomes a visible symptom of a chain trying to fund security and operations in a low-throughput environment. Commission is not a footnote—it is part of the chain’s de facto operating model.

Key takeaways:

- The combination of (a) compressed APR and (b) a depleting oracle incentive reserve is consistent with a chain operating under economic gravity: low real usage → low fee engine → shrinking security/incentive budgets.
- Terra Classic’s validator commission structure indicates a market split between scale incumbents charging up to ~20% and promotional low-fee operators competing for stake. With staking APR around ~4.1%, this dispersion meaningfully impacts net investor yields and reinforces the broader conclusion: low real usage translates into tighter incentive budgets, making validator economics (and therefore governance + security) more brittle over time.

6.6.6 Investor outcomes: why treasury quality matters more than “announcements”

Investor outcomes on Terra Classic are the composite of four interacting regimes:

1. On-chain utility regime (weak)

• Demand, fees, and usage indicators are structurally down (6.3), implying weak organic cashflow-like value drivers.

2. Off-chain trading regime (still present)

• As established in 6.4, markets can show meaningful off-chain volume even when on-chain utility is near-zero.

• This supports speculative tradability but does not automatically fund the chain.

3. Treasury allocation regime (inconsistent / lumpy)

• The Truth Dashboard evidence indicates slow, concentrated, episodic spending.

• This is precisely the pattern that struggles to rebuild sustained usage because it under-produces:

  • continuity,

  • iteration loops,

  • and reliable “ec .

4. Security-budget regime (tightening)

• Oracle pool depletion + low APR = tightening incentive budget.

So what do investors actually “get,” in practical terms?

• They get a tradable asset with periodic narrative-driven liquidity bursts (off-chain).

• They do not get strong evidence of a compounding on-chain economy that would justify systematic re-rating without a structural operating-model change (treasury + incentives + product distribution).

Key takeaway: Terra Classic currently behaves closer to a speculative market asset with residual chain activity than a growing L1 economy. Treasury execution quality is one of the few levers that can change that classification over time.

6.6.7 Governance participation quality is a treasury risk, not a “process” footnote

The governance participation snapshot in the Truth Dashboard shows structural participation gaps that translate directly into treasury governance risk (approval quality, accountability, and capture surface).

From the participation dashboard (validator.info-derived snapshot):

• Average validator non-participation per proposal: 59.6 (and “average proposals not voted: 59.6”).

• ~39.99% of all votes are “did not vote.”

• Validators with 100% non-participation control 13.38% of total voting power.

• The dashboard’s own interpretation: 94 of 149 validators have <50% non-participation, meaning a substantial fraction participates in fewer than half of proposals (as phrased in the snapshot).

This matters for 6.6 because a community treasury is only as credible as its oversight bandwidth:

• If a meaningful slice of voting power is held by habitual non-voters, then spending proposals are often decided by a smaller “active governance subset” than the chain’s decentralization optics imply.

• That subset can be high-quality (best case) or factional/coalitional (worst case). In either case, treasury legitimacy becomes dependent on a minority’s consistency, not the network’s broad deliberation.

Key takeaway: Treasury outcomes reflect the behavior of the “governance-active” minority, not the nominal validator set. Non-participation is not neutral—it concentrates decision power and weakens treasury accountability.

6.6.8 Validator economics and voting behavior create misaligned incentives for treasury stewardship

The “Current validators dashboard” snapshot adds another dimension: economic incentives and voting behavior co-exist in the same table, making it easier to discuss “who gets paid” vs “who participates.”

From the validator snapshot excerpt:

• Top voting power examples: DutchLUNC 14.73%, Allnodes 10.21%, KuCoin LUNC Node 5.3%, etc.

• The table includes monthly income estimates (e.g., DutchLUNC ~$3.42K, Allnodes ~$2.37K in the snapshot) alongside governance behavior columns like “Did not vote (1Y / 2Y)”.

Even as an offline snapshot, this is extremely valuable for 6.6 because it allows for statement (carefully, without over-claiming):

• Treasury control is shaped by stake concentration (voting power) and by whether high-power validators actually vote.

• Where large validators (or exchange-linked validators) show high non-participation in governance snapshots, the treasury inherits a structural weakness: those who could be the strongest oversight actors often behave as passive infrastructure.

Separately, the Terra Classic documentation excerpt have on-hand reinforces that the protocol includes mechanisms intended to discourage certain centralizing behaviors (e.g., the DynComm module for dynamic commission floors tied to delegation concentration).

That helps frame a key argument for 6.6:

• The chain already “admits” at protocol design level that validator economics can create undesirable equilibria.

• Therefore, treasury design should assume the same: economic incentives can degrade governance quality, unless counter-measures exist (process + tooling + incentives).

Key takeaway: Treasury stewardship is downstream of validator incentives. A system where voting power, income, and voting behavior diverge (high-power passive actors + smaller active actors) increases capture risk and reduces accountability for large spends.

6.6.9 Red flags and minimum-viable fixes (what “good” looks like for a post-crisis L1)

Red flags supported by evidence:

• Treasury spending is rare (idle ~89% of weeks) and lumpy (Gini ~0.55).

• Oracle incentive reserves trend downward (screenshot evidence) while on-chain demand is weak (6.3), implying structural funding pressure.

• Current yiel ), limiting how much “yield narrative” can compensate for weak usage.

Minimum-viable treasury operating model (MV-TOM) for Terra Classic:

1. Programmatic budgeting

   • Quarterly budget envelopes approved once, executed continuously.

   • Replace one-off “big spends” with staged milestones and enforceable deliverables.

2. Treasury reporting discipline

   • Standard format: objective, KPI target, budget, milestone dates, audit trail, post-mortem.

   • Every spend mapped to one of: security, developer experience, distribution/BD, or liquidity/market structure.

3. Security budget protection

   • Treat Oracle Rewards Pool health as a first-class KPI (like block time).

   • Build explicit policies for replenishment pathways tied to real usage (not purely symbolic taxes).

4. Investor outcomes framing

   • Stop treating “spend” or “burn” announcements as outcomes.

   • Track: cost per active wallet retained, cost per developer activated, cost per $ of sustained fees.

Key takeaway: Without a repeatable capital allocation process (not merely “a treasury”), investor outcomes remain dominated by off-chain sentiment cycles rather than on-chain compounding.