5.5.1. What this section covers (and what it doesn’t)

Sections 5.2–5.4 established who holds power, who participates, and who can sustain operations economically. This section answers a different question:

Does Terra Classic governance reliably convert decisions into delivered outcomes, and is there a functioning accountability loop?

It covers:

• Governance outputs at scale (proposal volume, type mix, pass/reject/veto rates).

• The execution-critical subset (software upgrades, IBC client updates, parameter changes, treasury spends).

• What these patterns imply about execution capacity and accountability maturity.

It does not evaluate the technical quality of each upgrade (Chapter 4 covers protocol health) or provide a full treasury audit (covered later where community pool is treated holistically).

5.5.2. The governance-to-execution model (how outcomes should work)

A mature L1 governance system typically behaves as a closed loop:

1. Signal & problem definition (proposal has a clear objective and measurable success criteria)

2. Decision (vote)

3. Execution (code change, parameter change, spend delivery, operational changes)

4. Verification (proof the change occurred; metrics tied to success criteria)

5. Postmortem & learning (if it fails: why; what changes)

Terra Classic’s core question is whether governance is mostly “decision theater” (many votes, weak delivery) or a real management system.

5.5.3. The scale reality: a huge volume of governance, but most is not actionable

The proposals dataset (voting-stage only, since May 2022) shows 1,711 proposals reaching voting.

Table 5.5-A — Outcome distribution (voting-stage proposals since May 2022)

• Rejected: 1,406 (82.17%)

• Passed: 155 (9.06%)

• Vetoed: 149 (8.71%)

• Voting period: 1 (0.06%)

Interpretation (objective):

• Terra Classic governance produces a very high volume of proposals, but only ~1 in 11 proposals pass.

• The combination of very high rejection + meaningful veto suggests either (a) low-quality proposal throughput (spam/low-effort), (b) governance gatekeeping dynamics, or (c) both.

This matters because high-volume governance does not equal high-capacity governance. In many systems, too much low-quality throughput becomes an execution tax on the few contributors who actually review, discuss, and implement.

5.5.4. The type mix exposes the core dysfunction: governance is dominated by text proposals

Proposal type mix is crucial. Only some types are execution-binding (software upgrades, IBC client updates, parameter changes, spending). Most text proposals are signaling artifacts and can be necessary — but if they dominate the system, it is often a symptom of weak delivery structures.

Table 5.5-B — Proposal type mix (voting-stage proposals since May 2022)

• TextProposal: 1,508 (88.14%)

• CommunityPoolSpendProposal: 70 (4.09%)

• ParameterChangeProposal: 37 (2.16%)

• ClientUpdateProposal: 10 (0.58%)

• MsgSoftwareUpgrade: 9 (0.53%)

• SoftwareUpgradeProposal: 8 (0.47%)

• (others small)

Interpretation (objective):

• Governance throughput is overwhelmingly text-based.

• Execution-binding proposals (upgrades + IBC client updates + parameter changes + spends) are a small fraction of total voting-stage proposals.

This is one of the strongest measurable indicators that Terra Classic has a governance load problem: a tiny execution-critical core is surrounded by a huge volume of signaling proposals.

5.5.5. The execution-critical subset performs “better” — but that’s not the same as being managed well

When we isolate execution-critical types, the pass-rate picture becomes very different.

Table 5.5-E — Pass-rate for execution-critical proposal groups

• Software upgrades: 17 passed / 17 total (100%)

• IBC client updates: 9 passed / 10 total (90%)

This is important. It means Terra Classic is capable of coordinating around core technical governance actions — particularly upgrades — when they are packaged as on-chain governance items.

However, two critical caveats apply:

1. Passing is not the same as institutional maturity.
   A chain can pass upgrades and still be organizationally fragile if delivery depends on a few actors and lacks transparent milestones, staffing clarity, and verification.

2. These are tiny counts relative to total governance throughput.
   The system can be “functional at the core” while still being dysfunctional as a governance institution.

5.5.6. Upgrade & client-update cadence: governance can move the chain, but the pipeline is narrow

The upgrade/client-update master list extracted from governance shows a long run of software upgrades and IBC client updates passing over time.

Table 5.5-D — Execution-critical proposal list (software upgrades + IBC client updates)

This table provides a governance-backed record of:

• Major chain upgrades (v1.1.0 through v3.6.1) passing governance

• Multiple IBC client reactivations/unfreezes (Cosmos Hub, Osmosis, Axelar, Juno, Kujira, etc.)

Interpretation (objective):

• Terra Classic’s core L1 can be maintained through governance-authorized upgrades.

• IBC connectivity actions have been repeatedly handled via governance.

But: this list is not a proof of operational excellence; it is proof of minimal functionality: the chain is not dead, and the governance mechanism can still ship code when someone shows up to do the work.

5.5.7. The accountability gap: “decision density” is low even when pass rates are high

The KPI story from 5.3 matters here: participation is structurally weak. In such systems, two governance failure modes are common:

1. Thin decision core
   A small number of validators and contributors carry most decisions and most execution work.

2. Diffused responsibility
   When outcomes are delayed or unverified, there is no reliable “owner” who must answer “what happened?”

This section’s governance outcome data reinforces that structural picture:

• Most proposals are text proposals and mostly rejected/vetoed.

• The execution-critical subset passes at high rates, implying that “real” governance actions are a narrow track.

Investor implication: The chain can keep running while still failing to build the kind of institutional governance capacity that attracts serious partners and sustained development.

5.5.8. Treasury and spending proposals: decisions exist, but accountability must be explicit

Spending proposals are where governance most resembles “company management,” because it allocates scarce resources.

The proposals dataset shows:

Table 5.5-F — Community Pool spend proposals: outcomes (voting-stage only)

• CommunityPoolSpendProposal: 15 passed, 53 rejected, 2 vetoed (70 total)

• MsgCommunityPoolSpend: 13 passed, 4 rejected, 2 vetoed, 1 in voting (20 total)

Interpretation (objective):

• Spend proposals are not automatically rubber-stamped; many are rejected.

• However, the governance dataset alone does not prove that passed spends were delivered with measurable impact, because delivery verification typically requires off-chain reporting: milestones, receipts, artifacts, and post-delivery measurement.

Accountability standard this report will apply (later expanded in the Community Pool chapter):

Every passed spend should have a minimum viable accountability packet:

• named owner(s)

• milestones + timeline

• deliverables + acceptance criteria

• public status reporting

• completion proof

• postmortem if delayed/fails

If this packet is absent, the governance decision may still be valid — but it is not institutionally mature.

5.5.9. A simple governance maturity diagnostic (qualitative, evidence-led)

Based on the evidence spine in this chapter, Terra Classic governance displays:

Strengths (verified by data):

• The chain can coordinate and pass core protocol actions (software upgrades, IBC client updates) at very high pass rates.

• Parameter changes and spending proposals do pass, indicating governance is not purely symbolic.

Weaknesses (verified by data and structure):

• Governance throughput is dominated by text proposals (88.14%) with a high rejection rate.

• The execution-critical path is narrow in volume (tiny count vs total governance).

• The broader governance system therefore looks like “a small delivery lane inside a large debate lane.”

This diagnostic does not claim malice. It describes a management system that is not optimized for execution.

5.5.10. Key takeaways for investors

1. Terra Classic governance is active but inefficient.
   A very high volume of proposals reaches voting, but ~82% are rejected and ~9% pass.

2. Most governance is signaling, not execution.
   Text proposals are ~88% of voting-stage proposals.

3. The execution-critical lane works, but it is narrow.
   Software upgrades and IBC client updates have high pass rates, demonstrating baseline functional governance — but not institutional maturity.

4. Accountability is the missing connector.
   For investors and partners, the key question is not “can a vote pass,” but “does a passed decision reliably turn into measurable delivery with transparent owners and verification.”