Terra Classic’s post-May-2022 developer activity must be interpreted differently than “normal” L1 ecosystems. In most competitive L1s, developer activity is a blend of (1) core protocol evolution (new capabilities and products), (2) maintenance (upstream compatibility, security patches), and (3) ecosystem enablement (tooling, documentation, integrations). On Terra Classic since the crash, the observed pattern is unusually concentrated in maintenance and survivability work, with a multi-team handoff history, inconsistent continuity, and limited product expansion on L1.

7.1.1. What “developer activity” means on Terra Classic post-crash

“Developer activity” is one of the most abused narratives in crypto. In many ecosystems it is reduced to GitHub commits, repo stars, or vague “building” claims. That is a weak proxy even for healthy chains; for a post-crash chain like Terra Classic it can be actively misleading.

This report therefore treats developer activity as delivered capability under severe constraints—measured by what was actually shipped, how it changed the chain’s operational envelope, and whether it plausibly converts into durable usage.

7.1.1.1 The baseline (and why it fails here)

In industry research, “active developers” is commonly approximated as developers who make code contributions within a time window (e.g., monthly active devs), typically via Git repositories.

That measurement is useful for macro comparisons across large ecosystems, but it breaks down on Terra Classic for structural reasons:

• Fork economics: a large share of “work” is backporting or adapting upstream Cosmos SDK / IBC changes rather than net-new invention. That can look like “lots of activity” while still being primarily maintenance.

• Repo fragmentation: work can happen across forks, private repos, and vendor repos; public commit counts can undercount real work or overcount shallow changes.

• Incentive distortion: in a chain where funding is politically contested, teams may optimize for visible deliverables (releases, upgrades) rather than the less visible work that creates long-term compounding (tooling, documentation, devrel, integration QA).

• Outcome mismatch: even genuinely strong engineering can coexist with near-zero on-chain demand if the work is not productized into reasons to transact (covered earlier in Ch. 6).

So “developer activity” must be redefined to match Terra Classic’s actual post-crash operating mode.

7.1.1.2 Terra Classic’s two regimes of developer activity: “keep it alive” vs “make it matter”

Post-2022, Terra Classic development clusters into two fundamentally different regimes:

Regime A —

Continuity / survival engineering (“keep it alive”)

Work that prevents failure, restores baseline functionality, and keeps parity with the broader Cosmos stack:

• emergency stabilization and chain restart

• validator ops continuity and testnet coordination

• security patches and exploit remediation

• version upgrades (core binaries), dependency parity work (SDK/IBC/Tendermint/Comet)

• parameter and module adjustments required for chain safety and basic economics

This is real developer activity, and it is often high-impact—but it mostly produces “the chain still runs”, not growth.

This is exactly how early post-crash contributions by Terra Rebels are characterized in the L1 team ledger: revival from a near-dead state, existential fixes mmunity ownership.

Regime B —

Product / demand engineering (“make it matter”)

Work that creates new reasons for users/builders to transact:

• new L1 primitives that expand addressable product space (e.g., new market structure, new collateral logic, new fee engines)

• integrated incentive programs that measurably increase retained activity (not one-off spikes)

• developer experience that reduces time-to-ship (SDKs, templates, stable APIs, reliable infra)

• distribution and onboarding systems (wallet UX, indexing, docs, partner integrations)

Terra Classic’s core constraint is that most funded L1 work has been Regime A, and very little has successfully crossed into Regime B (or, where proposed, it often remains in development rather than shipped and used).

The “L1 dev teams ledger” explicitly frames the majority of L1 work since 2022 as stability, parity, and upgrade delivery—vital, bu product formation.

7.1.1.3 What counts as “developer activity” in this report (operational definition)

For Chapter 7 (Builders, Products, and Real Adoption), developer activity is counted only when it is evidence-backed in one of these ways:

1. Shipped mainnet capability
   A released upgrade or deployed module that changes what users/builders can do on-chain (not just narrative intent).

2. Shipped operational capability
   Tooling and infrastructure that measurably reduces friction (e.g., stable relaying, consistent endpoints, indexers, wallet functionality)—especially when it affects reliability for all apps.

3. Verifiable delivery under governance mandate
   A proposal-funded mandate with clear scope and evidence of delivery. This includes “maintenance-only” work, but it is labeled as such.

4. Ecosystem enablement with traceable downstream impact
   For example: restoring or improving IBC functionality, making CosmWasm execution safer/faster, or removing blockers that prevent dApps from launching.

5. Sustained team continuity
   In a post-crash ecosystem, continuity is itself a measurable output. High turnover forces relearning costs and erodes delivery velocity.

The L1 teams ledger provides unusually concrete material for (1), (3), and (5): named teams, periods of activity, and the recurring reality that teams form, issolve or rotate.

7.1.1.4 The “governance-shaped engineering” constraint

In many chains, core development is guided by a product organization (even if decentralized). In Terra Classic, development is heavily governed by:

• validator voting dynamics

• community pool politics

• episodic budget approvals

• reputational risk for requesting funding

This matters because developer activity is not merely an engineering function—it is a capital allocation + accountability function.

A clear symptom is the ecosystem’s documented culture of volunteerism as a moral expectation, and resistance to paid work—even for chain-critical tasks. The “Builders and Incentive Alignment” document describes recurring tension where funding proposals are opposed on principle, creating pressure for builders (including L1 maintenance contributors) to avoid backlash.

That cultural constraint changes what developer activity means in practice:

• It increases reliance on a small set of committed individuals.

• It increases delivery risk (burnout, sudden exit, unpaid work stopping).

• It discourages professional vendor engagement and long-horizon planning.

• It biases the ecosystem toward “patching” rather than building repeatable programs.

So developer activity must be interpreted as capacity under social and governance constraints, not merely “how many people code.”

7.1.1.5 A concrete taxonomy for Terra Classic post-2022 work

To avoid vague “builders are building” claims, Terra Classic developer activity is categorized as follows:

Category 1 — Chain resurrection & existential fixes (2022–early 2023)

Work that re-enabled survivability and basic chain operation.

This is where Terra Rebels had the highest leverage: “revive ed existential fixes, and provided foundational continuity at near-zero cost.

Category 2 — Structured maintenance & parity upgrades (2023–2024)

The move from volunteer era into paid L1 maintenance.

The Joint L1 Task Force profile describes a governance-funded maintenance regime focused on upgrades, IBC work, testnet coordination, and stability.

Category 3 — Continuity gaps, team turnover, and re-onboarding costs (2024–2026)

The ledger’s narr transitions and discontinuities: member departures, disbandments, repo handoffs, and new teams picking up partially completed mandates.

In a low-demand chain, this produces a compounding drag: every transition consumes scarce time and attention that could otherwise go into growth-building.

Category 4 — “App-layer activity” that doesn’t translate into L1 product activity

Some projects labeled “L2” in community discourse are not L2 scaling systems at all, but base-layer apps (e.g., lending protocols writte s/Luncverse evidence pack explicitly notes this mismatch: “not a Layer 2 solution,” but a base-layer protocol or NFT/metaverse concept.

This matters because “builders” can exist without the chain itself gaining new L1 products.

7.1.1.6 The critical distinction: delivery ≠ adoption

A chain can be competently maintained and still be economically stagnant.

The “developer activity” story becomes misleading if it implicitly claims that shipping upgrades equals recovery. In Terra Classic’s case, prior chapters establish that demand/fees/usage remain structurally weak; therefore, the relevant question is not “is there development?” but:

• Is the development producing new, defensible reasons to transact?

• Is it producing reliable, measurable adoption in Tier A projects (TVL, volume, active users)?

• Is it increasing the chain’s ability to attract external builders (not only internal loyalists)?

The Terra Classic DeFi footprint snapshot (via DeFiLlama export) shows how many “na h zero or near-zero TVL, illustrating why “ecosystem size” and “development narratives” must be cross-checked against measurable use.

7.1.1.7 Key takeaway (definition locked for the rest of Chapter 7)

On Terra Classic post-crash, “developer activity” primarily means continuity engineering: keeping the chain operational, compatible, and safe under centive constraints. This is necessary work, and it has been delivered by successive teams with varying professionalism and continuity.

However, continuity engineering is not the same as product engineering, and not the same as adoption engineering. The chain’s recovery hinges on whether developer activity can shift from “keeping it alive” to “making it matter,” which requires: stable funding norms, professional delivery cadence, and measurable outcomes tied to real usage—not merely upgrades.

7.1.2. Chronology of L1 delivery: from volunteer survival to multi-team maintenance

Terra Classic’s L1 delivery since May 2022 is best understood as a sequence of operating regimes—each defined less by “developer activity” in the abstract and more by (a) who had the mandate and capacity to ship, (b) what class of work was economically rational to fund, and (c) what governance could reliably execute. Across all regimes, the dominant pattern is maintenance-led delivery: keeping the chain alive, compatible, and secure—rather than shipping new L1 “products.”

7.1.2.1 Regime 1 — “Chain survival” (mid-2022 → late-2022/early-2023): emergency volunteer delivery

Primary team: Terra Rebels (with later partial rebrand/shift into non-core tool/infrastructure work via Hexxagon).

Context (delivery constraint):

Post-collapse, the chain’s first requirement was existential: restart and stabilize a network that had lost its original sponsor and whose economic design (especially around minting/stablecoin dynamics) became a systemic risk factor. In this regime, “developer activity” is synonymous with incident response + protocol triage: making the chain safe enough to keep running and letting validators and holders coordinate around a baseline.

Work profile (what shipped / why it matters):

• Urgent stabilization and parameter/protocol fixes that allowed the chain to operate post-crisis (including disabling high-risk mechanics and re-establishing safe operation).

• Foundational groundwork for later burn/tax mechanics and a community-controlled operational posture.

• Infrastructure autonomy thread (adjacent to core L1): decoupling from Terraform Labs backends and running community-owned tooling/endpoints. This is not “new product” delivery; it is operational independence—a prerequisite for any later ecosystem recovery.

Operating reality:

Volunteer delivery can be fast in crisis, but it tends to be fragile: it relies on informal coordination, and it is vulnerable to interpersonal conflict and unclear accountability. The record explicitly notes internal drama/splits and subsequent team transitions.

Interpretation (what this regime proves vs what it doesn’t):

• Proves: Terra Classic could survive without its original sponsor, and community-led development could produce high-impact emergency fixes.

• Does not prove: a repeatable, professionalized delivery engine exists. Survival-mode output is not the same as sustained product evolution.

Key takeaway: The “Rebels era” is the chain’s highest-leverage delivery phase, but it is structurally a crisis-response chapter, not a scalable development model.

7.1.2.2 Regime 2 — “Funded maintenance” (late-2022 → March 2024): JL1TF professionalizes upgrades but exposes single-team fragility

Primary team: Joint L1 Task Force (JL1TF / L1TF), formed from ex-Rebels members and additional contributors; first formally funded L1 team.

Why this regime exists:

Once the chain is “alive,” the next threat is technical obsolescence. Cosmos-based chains must regularly upgrade (SDK/Tendermint/IBC) to remain secure, interoperable, and developer-compatible. That means structured testing, testnets, coordinated upgrades, and release discipline—work that is hard to sustain via volunteerism alone.

What changed operationally (relative to volunteers):

• Governance-funded mandate: a real budget signal that L1 maintenance is an ongoing cost center, not a one-time rescue.

• More structured release work: v1.x → v2.x era upgrades, testnet coordination, and compatibility/security maintenance.

Work profile (class of delivery):

• Core upgrades and parity work (v1.0.5, v1.1.0, preparations for v2.0.x series including Cosmos SDK and Tendermint versions).

• IBC and oracle stability work to keep interchain functionality and price-dependent modules functioning.

• Governance and database research (e.g., discussions around storage/DB performance and governance mechanisms), mostly maintenance/technical debt reduction rather than product expansion.

Failure mode that mattered:

JL1TF’s disbandment in March 2024 (after member departures across 2023) demonstrates a recurring Terra Classic pattern: single-team dependency risk. When one team is the primary maintainer and that team collapses, the network inherits a continuity gap and governance must scramble to replace operational capacity.

Interpretation (what JL1TF achieved vs what it implies):

• Achieved: meaningful maintenance delivery that reduced obsolescence risk and kept the chain viable through 2023–2024.

• Implies: governance can fund maintenance, but without robust accountability and redundancy, delivery continuity remains brittle.

Key takeaway: JL1TF moved Terra Classic from “survival” to “maintenance,” but its exit forced the ecosystem to learn that professional delivery requires redundancy, not hero teams.

7.1.2.3 Regime 3 — “Successor turbulence” (late-2023/early-2024 → mid-2024/2025): Genuine Labs overlap, partial delivery, and abandonment risk

Primary team: Genuine Labs (funded via governance, beginning with proposals in late 2023).

What this regime signals:

This is the “handoff gap” period: governance attempts to replace a disbanded or weakening core team quickly. The resulting delivery risk is predictable: tooling fork sprawl, partial/incomplete features, and blurred ownership of long-running initiatives.

Work profile and evidence of scope:

• Security upgrade packages (noted as deployed).

• v3.0.1 upgrade work (SDK v0.47 integration timeframe indicated).

• “Tax2Gas” discussed/attempted but not fully delivered by the team.

• Genuine maintained their own forks (wasmd, cometbft, etc.), which is a common maintenance posture but increases ecosystem coordination costs when ownership is unstable.

The critical datapoint (delivery continuity):

The profile states no activity since mid-2024 (last GitHub activity May 2024) and frames this as effective abandonment with successors taking over.

Interpretation (why this matters beyond “drama”):

• When a funded team exits without clean completion/transition, Terra Classic pays twice:

  1. Direct cost: funding spent on partially realized output.

  2. Opportunity cost: successor teams must untangle forks, re-validate work, and re-establish release confidence.

Key takeaway: Genuine Labs illustrates why “developer activity” cannot be assessed by announcements or proposals alone; handoff quality and sustained repo-level throughput are what protect a chain from maintenance debt compounding.

7.1.2.4 Regime 4 — “Multi-team maintenance” (2024 → 2026): specialization emerges (BLV Labs) while Orbit Labs drives major modernization

Primary teams: BLV Labs (specialist modules) + Orbit Labs (core modernization and major SDK/IBC migrations).

This is Terra Classic’s most structurally “mature” development posture since the crash: instead of relying on a single team to do everything, work begins to split into specialized lanes.

A) BLV Labs — targeted governance/tax modules (parallel contributor model)

Work profile (specialized delivery):

• Governance module enhancements aimed at spam reduction and deposit stability (deployed ~Sep 2024 in the timeline table).

• Wallet whitelisting / tax exemption module (Prop 12161) with completion reporting June 10, 2025 and follow-up funding June 15–27, 2025.

• Contributions to v3.5.0 mainnet upgrade (upgrade success Aug 17, 2025; proposal submitted July 28, 2025).

Quality signals (how “maintenance” was executed):

• Public reporting habits (updates, technical docs, testing artifacts), clean merges into classic-terra repos, and no reported breakages post-deployment.

Pace signal:

The timeline notes a clear taper after Aug 2025 (e.g., ratelimit module idea posted Aug 23, 2025 with no visible completion by Feb 2026). That is not necessarily failure; it may indicate shifting priorities or reduced funding appetite. But it reinforces a core point: multi-team capacity helps only if work pipelines remain active and incentivized.

B) Orbit Labs — modernization, unforking, and the major SDK/IBC upgrade path

Work profile (heavy infrastructure modernization):

• Forked modules removal (mid-2024 → Jan 2025 Phase 1 completion), aligning with upstream Cosmos rather than maintaining Terra-specific forks.

• Cosmos SDK v0.50.x series contributions (2025).

• Major Cosmos SDK v0.53.x + IBC-go v10 migration (late 2025 → ongoing Feb 2026): implementation completed Dec 9, 2025; rebel-2 testnet upgrade successful by ~Jan 11, 2026; breaking-change compatibility layer resolved Jan 13–16; stable testing by Jan 22; Phase 1 funding approved Jan 30, 2026; Phase 2 ongoing.

Funding discipline (why it matters for delivery):

• The profile describes phase-based funding with a concrete Phase 1 figure (~$40k equivalent) and milestone alignment (Phase 1/2). This is closer to a professional procurement pattern than open-ended quarterly funding—and it reduces governance risk by tying payment to verifiable artifacts.

Pace relative to Cosmos norms:

The document explicitly compares typical Cosmos timelines (module additions 1–4 months; major SDK migrations 4–12 months) to Orbit’s observed pace—reaching stable testnet in ~1–2 months post-implementation and mitigating breaking changes quickly.

Interpretation (what the multi-team era really is):

• The chain’s delivery engine becomes more professional in execution mechanics (phased milestones, specialization, heavy upstream alignment).

• But the content of delivery remains largely maintenance: upgrades, parity, unforking, spam resistance, tax mechanics, tooling stability. Even when the work is excellent technically, it does not automatically create net-new user demand (that is treated elsewhere in the report).

Key takeaway: The 2024–2026 era is the best evidence that Terra Classic can sustain a modern Cosmos maintenance program—but it is still overwhelmingly a maintenance program, not an L1 product innovation program.

7.1.2.5 Cross-era synthesis: what the chronology implies about delivery capacity

1) Terra Classic repeatedly reconstitutes L1 capacity—but continuity is expensive.

Each team transition (Rebels → JL1TF → Genuine → multi-team) imposes coordination overhead and trust reset costs. The chronology includes at least one major “abandonment” episode and one formal disbandment, both of which create institutional memory loss and re-validation work.

2) The chain’s “shipping” has been rational—but narrowly scoped.

Given depressed on-chain demand (covered elsewhere), allocating scarce coordination bandwidth to upgrades and parity is defensible: without it, the chain becomes progressively unbuildable. The chronology shows heavy emphasis on SDK/IBC modernization and governance hardening, consistent with that logic.

3) The maturity jump is procedural more than product-based.

The multi-team era improves execution mechanics (specialization, phased funding, better reporting). However, the delivered outputs remain mostly in the categories of:

• security and compatibility,

• technical debt reduction,

• governance robustness,

• operational tooling.

That is a necessary foundation, but it is not sufficient to claim “ecosystem growth” in a usage sense.

7.1.2.6 Key takeaway

From May 2022 to February 2026, Terra Classic’s L1 delivery evolved from volunteer survival → funded maintenance → handoff turbulence → multi-team maintenance specialization. The strongest evidence of progress is modernization capacity (especially in the Orbit Labs era). The strongest evidence of limitation is that nearly all delivery remains maintenance-led, meaning L1 “developer activity” has primarily prevented decay rather than generating new L1 product-driven adoption.

7.1.3. What was actually shipped: maintenance dominates the L1 backlog

A recurring debate in the Terra Classic ecosystem is whether “development” since mid-2022 has been a story of progress or merely survival. The evidence from the L1 delivery ledger shows a consistent pattern: most shipped work has been maintenance, in the strict L1 engineering sense—upstream parity, security posture, operational continuity, and guardrails for governance and protocol economics—rather than the creation of new L1-native products.

This section classifies what was shipped, maps it to delivery streams/teams, and explains why the backlog structurally skews toward maintenance.

7.1.3.1 A practical taxonomy of “shipped work” on Terra Classic L1

From May 2022 through early 2026, shipped L1 work clusters into five buckets:

1. Core protocol survival and continuity

• Chain restart and basic viability work immediately after the collapse—restoring functional block production and minimum viable operations. This was largely volunteer-driven early on and later transitioned into paid maintenance structures.

2. Upstream parity and modernization

• Migrations and compatibility work to keep the chain aligned with the moving target of the Cosmos stack (SDK, consensus, IBC). This includes removing legacy forks and migrating to newer Cosmos SDK + IBC versions.

3. Security and reliability upgrades

• Security upgrade packages, patching, and stabilization releases that reduce exploit/obsolescence risk.

4. Governance hardening and anti-spam controls

• Engineering changes designed to reduce governance spam and stabilize proposal economics (e.g., dynamic deposit pegging and governance module enhancements).

5. Economic/fee plumbing and operational friction reduction

• Changes to fee/tax mechanics and exemptions (e.g., tax-to-gas concepts; governance-controlled tax exemption/whitelisting), intended to make the chain operationally workable or reduce unintended economic drag.

Interpretation discipline: None of these buckets are “bad.” In a post-crash chain, they are necessary. The key point is that they largely optimize infrastructure and continuity, not new user-facing L1 products.

Key takeaway: The L1 backlog has been dominated by “keep the chain current and safe” work, not “ship new primitives that create demand.”

7.1.3.2 What each delivery stream actually produced

A) Volunteer survival + tooling autonomy (2022–early 2023 and spillover)

• Terra Rebels (and the later Hexxagon successor branding) focused heavily on infrastructure autonomy: forking and running community-owned wallet/front-end and independent endpoints (LCD/FCD/API), plus maintenance of those services. This is ecosystem-critical plumbing, but it is not “new L1 product” development.

B) First funded “core maintenance” structure (late 2022–March 2024)

• The Joint L1 Task Force phase formalized paid maintenance: upgrades (v1.x → v2.x progression), IBC/oracle stability, testnet coordination, and general parity work to keep Terra Classic viable. This created continuity, but the net output is still primarily technical upkeep and risk reduction.

C) Short-lived professional team with incomplete feature follow-through (early–mid 2024)

• Genuine Labs (explicitly linked in the ledger to Notional Labs backgrounds) delivered important upgrades (security packages, v3.0.1/SDK integration) but failed to complete longer arc items (notably the Tax2Gas path as described in the ledger) and then ceased activity mid-2024.

• The result: maintenance was partially done, but the “feature layer” did not mature into a stable L1 capability. This also reinforced the chain’s dependence on whoever could continue maintenance afterward.

D) Multi-team era: modernization + targeted modules (late 2024–2026)

• Orbit Labs became the dominant modernization stream: removing forked modules, Cosmos SDK upgrade series (0.50.x), and the major Cosmos SDK v0.53.x + IBC-go v10 migration with testnet stability and compatibility mitigation work. This is high-value “keep the chain current” engineering.

• BLV Labs specialized in governance hardening and tax friction controls: governance module enhancements (spam reduction/dynamic deposit pegging) and tax exemption/whitelisting mechanisms, plus contributions to v3.5.0. Again: critical maintenance + guardrails, not product creation.

Key takeaway: Across teams and eras, the shipped outputs are overwhelmingly “protocol upkeep + guardrails + compatibility,” with very limited “new L1-native product” surface.

7.1.3.3 Why this still counts as “activity” but not “product delivery”

It is possible for a chain to have high developer activity and still have low product throughput at the L1 layer.

• Upgrading Cosmos SDK / IBC, removing legacy forks, and maintaining endpoints are activity (engineering work, risk reduction, and operational continuity).

• But these upgrades generally do not create new reasons for new users to arrive, because they are enablers rather than value propositions. They reduce breakage risk and enable interoperability; they don’t automatically create new demand.

This distinction becomes decisive when the surrounding report already documents structurally low on-chain demand: if demand is down, maintenance-only delivery can stabilize the system yet fail to reverse adoption trends.

Key takeaway: Maintenance activity is necessary for survival and compatibility, but it is not sufficient as an adoption engine.

7.1.3.4 Why maintenance dominates structurally

The L1 backlog bias toward maintenance is not accidental; it is an equilibrium produced by constraints repeatedly visible in the delivery record:

1. Post-crash technical debt + ecosystem compatibility debt

• Terra Classic must continuously “catch up” to upstream Cosmos changes to stay compatible with wallets, relayers, tooling, and IBC expectations. Modernization streams (Orbit’s work) directly reflect this obligation.

2. Delivery continuity risk (team churn / abandonment)

• The ledger documents that at least one professional team stopped mid-stream, leaving incomplete arcs (e.g., Tax2Gas) and forcing succession by other teams. This naturally pushes governance to prioritize “must-not-fail upgrades” over speculative new product work.

3. Governance surface area: the chain must defend itself from governance friction

• Governance spam and parameter fragility are existential time sinks; it is rational (even if unfortunate) that a chain under stress invests in anti-spam and governance economics stabilization first. BLV’s governance work reflects this.

Key takeaway: The “maintenance dominance” is a rational response to technical and governance constraints—but it also locks Terra Classic into a loop where adoption cannot recover without a deliberate shift toward product and distribution.

7.1.3.5 So what should readers conclude?

Evidence-supported conclusion: Since May 2022, Terra Classic L1 delivery has been largely a sequence of maintenance programs (parity, security, governance hardening, fee/tax plumbing, infrastructure autonomy) executed by successive teams with improving professionalism in the multi-team era.

Interpretation (what it implies for adoption): A chain can “run well” and still stagnate economically if its roadmap remains dominated by upkeep. Without an intentional pivot to product primitives, incentives, and distribution mechanisms (handled elsewhere in Chapter 7 and Chapter 6), L1 developer activity will continue to be visible while real adoption remains structurally constrained.

Key takeaway: The L1 has been maintained—and in places meaningfully modernized—but maintenance has been the dominant output, not new L1-native product creation.

7.1.4. Funding models, continuity risk, and accountability signals

Terra Classic’s post-crash L1 delivery has been constrained less by “developer talent exists / doesn’t exist” and more by how development is funded, governed, and operationally secured over time. Across 2022–2026, the chain cycled through multiple funding regimes—each with distinct trade-offs in continuity, accountability, and delivery incentives.

7.1.4.1 Funding regimes observed on Terra Classic L1 (2022–2026)

Regime A — Volunteer / donation-led survival work (2022–2023)

Immediately after the May 2022 collapse, L1 and critical infrastructure work leaned heavily on volunteer coordination, donations, and informal sponsorships. This model prioritized speed and survival: restore basic functionality, keep the chain usable, and remove dependencies on Terraform Labs where possible. Infrastructure autonomy work (e.g., community-owned Station and backend endpoints) is explicitly described as a major thread of this era.

Core strengths

• Low cash outlay; politically easy to approve because it “protects the pool.”

• Rapid emergency response and morale-driven momentum.

Core weaknesses

• Continuity risk is structurally high (burnout, drift, internal fragmentation).

• Accountability is informal: no standard procurement, no enforceable milestones, no service-level obligations.

Regime B — “Single prime contractor” funded revival (late 2023 → mid 2024)

The next phase attempted to professionalize: fund a smaller team with known Cosmos competence and deliver a clear set of protocol upgrades. This “single-team” model is explicitly noted as transitional and effective at reducing obsolescence risk—but also as exposing the chain to a single point of failure if the team stops.

A concrete example of the failure mode exists: Genuine Labs is documented as being formed via governance (Prop 11940, Dec 2023), operating ~6–9 months, and then ceasing activity mid-2024, with last GitHub activity around May 2024 and no credible resumption through 2026. The work list includes partial upgrades and a Tax2Gas effort that did not complete under that team’s execution window.

Implication: even if deliverables are partly achieved, a sudden stop forces successor teams to absorb unfinished work, re-test assumptions, and rebuild trust—creating hidden time-cost and governance fatigue.

Regime C — Multi-team, modular “pay-per-job” maintenance (mid 2024 → 2026)

After the system experienced single-team fragility, Terra Classic’s L1 delivery shifted toward a multi-team model: different groups handling discrete modules, upgrades, and maintenance tracks in parallel.

Two major documented examples:

• BLV Labs: focused on governance/spam mitigation and tax-related modules; worked via proposal-based disbursements; produced clear deliverables and is characterized as relatively transparent and efficient for its scope.

• Orbit Labs: positioned as the leading core L1 team by early 2026, focusing on major migrations and compatibility work (e.g., SDK v0.53 path, IBC-go v10.3.0 / IBC V2), delivered in phased milestones with testnet evidence and structured rollouts.

Implication: this model reduces the catastrophic risk of “one team disappears,” but it still requires a governance layer capable of prioritization, integration discipline, and standardized acceptance criteria. Without that, multi-team work becomes “parallel maintenance” rather than a coherent product roadmap.

7.1.4.2 What the funding history reveals about continuity risk

Continuity risk on Terra Classic is not theoretical—it has already occurred and shaped governance behavior.

(1) The chain has seen real “delivery discontinuity” events

Genuine Labs is described as having effectively abandoned work mid-stream (no ongoing activity after mid-2024, no handover, no consistent final reporting).

This is a textbook continuity failure mode for decentralized procurement: governance can approve budgets, but it struggles to enforce continuation or orderly exit.

(2) The community adapted—but largely into “maintenance resilience,” not “product ambition”

The multi-team era (Orbit + BLV + others) is documented as a response that improved resilience and reduced chronic delays seen previously.

However, the work focus that gets funded remains heavily skewed toward upstream compatibility, governance safety, and technical debt reduction, which helps chain survivability but does not automatically create new demand.

(3) Procurement structure itself creates continuity pressure

Proposal-by-proposal funding (PPJ or phase-based) incentivizes teams to:

• narrow scope into fundable “chunks,”

• over-emphasize visible deliverables (upgrades, modules),

• under-invest in longer-term productization (developer experience, ecosystem distribution, user-facing primitives), because those are harder to approve and harder to measure inside governance debates.

This is a structural bias: the funding mechanism is optimized for “ship patches and upgrades” rather than “build a product strategy.”

7.1.4.3 “Accountability signals” that are measurable in this ecosystem

To keep Chapter 7 evidence-driven, accountability here is treated as a set of observable signals, not moral judgments.

Signal A — Deliverable completion and post-delivery reporting

• BLV Labs is explicitly described as having strong transparency relative to peers, completing scoped deliverables (e.g., governance upgrades, whitelisting module) with reporting/testing artifacts.

• Orbit Labs is described as exceeding standard practices in pace and execution for complex upgrades (testnet stability, phased rollouts, compatibility layer work).

• Genuine Labs is described as weak on late-stage accountability: delays, internal issues, and then silence with no meaningful final reporting.

Signal B — Funding tied to milestones vs. broad retainers

• Orbit’s work is represented as phase-based and milestone-aligned (e.g., SDK v0.53 Phase 1 noted as ~US$40k equivalent via Prop 12213, Jan 2026), which is closer to conventional delivery governance.

• Genuine Labs is described as PPJ with modest disbursements (examples cited: ~US$16k early 2024; 256M LUNC ~US$30k June 2024), but the model did not prevent mid-stream abandonment.

Signal C — Governance “trust trajectory”

Teams that produce consistent outputs with clean reporting tend to gain easier approvals; teams associated with delays or discontinuity tend to face rejections and political scrutiny. The documentation explicitly notes trust erosion and the need for better accountability after earlier phases.

7.1.4.4 The “free work” norm as an incentive distortion (and why it matters for L1 continuity)

A separate but decisive factor is cultural: persistent pressure toward unpaid work in parts of the community and validator discourse. The Builders & Incentive Alignment evidence pack describes:

• volunteerism being valorized as a badge of legitimacy,

• resistance to paid development via the Community Pool,

• funding proposals receiving aggressive opposition framed around “grift risk,” burn-prioritization, or “volunteers exist,”

• builders being incentivized to signal that they work for free to avoid backlash.

This is not just a social problem; it is a delivery-system problem:

• It selects for developers who can subsidize the chain, not necessarily those best equipped to deliver at scale.

• It converts necessary operational work (relaying, upgrades, infra maintenance) into personal sacrifice, which increases burnout probability and discontinuity risk.

• It pushes L1 procurement toward a narrow subset of “politically safe spends” (maintenance and upgrades) while making proactive capability building (dev funds, sustained product work) harder to approve.

The evidence pack also notes that while funding can occur for tightly scoped work (including large approvals), ongoing builder incentives remain contentious, generating a persistent “prove first for free” dynamic.

7.1.4.5 What this implies for “software delivery” versus “ecosystem building”

The funding model and accountability pattern explain a critical observation that recurs across Chapter 7:

• Terra Classic has developed a workable maintenance pipeline (multi-team upgrades, governance hardening, compatibility work).

• But the same system has weak capability for product-oriented investment, because:

  1. procurement is governance-heavy and episodic,

  2. the cultural center of gravity often privileges “spend avoidance,”

  3. success metrics are easier to prove for upgrades than for adoption-building.

This is why developer activity on Terra Classic can be real and non-trivial while the chain still struggles to produce new, measurable L1 “products” beyond staking.

7.1.4.6 Key takeaway

Terra Classic’s post-crash L1 delivery has moved from volunteer survival to a more resilient multi-team maintenance model, but continuity remains structurally exposed to governance friction and incentive misalignment. Accountability is strongest where funding is milestone-bound and reporting is consistent (Orbit/BLV examples), and weakest where teams can exit without a formal handover (Genuine Labs example). The dominant funding equilibrium optimizes for keeping the chain alive, not for building product-led adoption engines.

7.1.5. The “vendor selection” constraint: global talent, weak institutional scaffolding

“Developer activity” on Terra Classic is not constrained only by talent availability. It is constrained by how the chain is structurally able to select, contract, fund, and retain that talent—especially after the May 2022 collapse. In other words: Terra Classic’s bottleneck is not merely “finding developers,” but operating a credible procurement + accountability system in a governance-led environment.

This section defines that constraint, documents how it appears in Terra Classic’s post-crash L1 delivery history, and explains why it has repeatedly produced discontinuity, maintenance-heavy roadmaps, and slow product progress.

7.1.5.1 Vendor selection in a governance-led chain is procurement, not “community vibes”

In a typical L1 with an operating entity (foundation/company), vendor selection looks like:

• defined scope → request for proposals → due diligence (legal entity, references, capability)

• milestone contract → acceptance criteria → payment rails → ongoing reporting/audits

• continuity planning (handover clauses, repos, documentation, access control)

In Terra Classic, vendor selection is primarily executed via token-vote governance and community processes, which structurally changes the procurement function:

1. Governance becomes the tender board.
   Funding is commonly tied to proposals; proposal framing and narrative legitimacy become gating factors for who gets selected and paid.

2. Budgeting becomes episodic and political.
   Instead of continuous operating budgets with standard payment cycles, vendor funding is frequently packaged into time-boxed proposals and multi-sig disbursements (e.g., quarterly).

3. Accountability shifts from contract enforcement to social enforcement.
   In the absence of robust procurement scaffolding, the system relies more heavily on reputational feedback loops, forum debates, and validator voting discipline—tools that are weaker than enforceable deliverables when the stakes are high.

Key implication: even if Terra Classic has a capable vendor available, the chain’s ability to select and retain that vendor depends on governance throughput, cultural norms, and payment legitimacy—not only on competence.

7.1.5.2 Evidence of thin institutional scaffolding in the post-crash L1 team history

The L1 delivery ledger shows a repeated pattern: teams form, secure a mandate, deliver essential maintenance, and then dissolve or rotate—often due to governance friction, burnout, privacy/doxxing concerns, or funding continuity constraints.

A concrete example is the Joint L1 Task Force (JL1TF/L1TF), presented as the first formally funded “professional” post-volunteer L1 team. Its documented composition and evolution illustrates the structural issues:

• Global, partially pseudonymous membership and mixed commitment levels (full-time + part-time), including contributors connected to broader Cosmos ecosystem work.

• Resignations driven by privacy/doxxing concerns and gradual attrition leading to disbandment.

• Quarterly community-pool funding via a multi-sig structure (Terra Grants Foundation), rather than a stable multi-year operating mandate.

This is not an argument that the individuals lacked skill; rather, it demonstrates a procurement reality: Terra Classic can stand up teams, but struggles to institutionalize them—and that makes vendor selection fragile.

7.1.5.3 Geography and “legitimacy surface”: why proven vendors are hard to attract and retain

A recurring characteristic of Terra Classic’s post-crash staffing is reliance on globally distributed contributors and smaller teams—sometimes with unclear institutional backing.

The L1 ledger explicitly describes globally distributed contributors and identifies leadership and contributors across different regions (including Vietnam) in the JL1TF period.

This matters because “vendor selection” has two layers:

• Technical capability (Cosmos SDK/Tendermint competence, ability to upgrade safely)

• Institutional capability (legal entity, contracting, accountability, continuity, insured operations)

Where institutional capability is thin or unclear, the chain inherits predictable risks:

• delivery dependency on a small number of individuals

• weak enforceability of timelines and acceptance criteria

• higher probability of abrupt exits (burnout, reputation attacks, opportunity costs)

The same ledger contrasts later teams (e.g., Orbit and BLV) as delivering faster and more reliably than earlier eras, while still highlighting how much performance variance Terra Classic has experienced across teams over time.

Key implication: the procurement constraint is not that “developers don’t exist,” but that the chain’s operating environment makes it hard to contract with institutional-grade vendors consistently.

7.1.5.4 The “free work” norm acts as an anti-procurement force

Terra Classic also exhibits a cultural dynamic that directly degrades vendor selection outcomes: pressure toward unpaid work and hostility toward paid development, especially for ongoing or forward-looking initiatives.

The “Builders and Incentive Alignment” evidence pack documents:

• a long-running expectation of volunteerism (post-crash revival identity),

• resistance to paid development from the Community Pool framed as anti-grift protection,

• and repeated public debates where builders highlight unpaid work history to establish legitimacy or avoid backlash when seeking funding.

It includes specific references to:

• builders stating they provided years of work “for free,” and

• disputes over modest funding requests for infrastructure-like work such as IBC relaying.

Why this is a vendor-selection constraint (not just “community drama”):

• credible firms generally do not join environments where payment legitimacy is socially contested

• professional vendors expect predictable remuneration, scope control, and acceptance criteria

• a “prove it for free first” norm selects for hobbyists, true believers, or underpriced labor—not consistently for institutional-grade teams

This does not mean volunteer contributions are bad. It means a chain that must compete with other ecosystems for talent cannot treat “free work” as a sustainable procurement strategy.

7.1.5.5 Conflict-of-interest risk: validators as decision-makers, infrastructure operators, and builders

The vendor constraint is amplified when the same actors appear across:

• governance voting power,

• validator operations (infrastructure),

• and private L2/product efforts.

The Classic Chaos Podcast research pack describes this as a structural misalignment: validators effectively become principal decision makers while also having incentives to pursue L2 ventures, which can reduce incentives to professionalize L1 delivery and procurement.

This does not require malicious intent to produce harm. It creates an environment where:

• procurement is harder to standardize (because decision-makers are not a neutral “buyer”)

• accountability is harder to enforce (because oversight capacity is fragmented)

• vendor selection can drift toward convenience, relationships, or narrative alignment

7.1.5.6 What this constraint explains in practice

This “vendor selection constraint” helps explain several macro outcomes observed across Terra Classic’s post-crash delivery:

1. Maintenance dominates because it is easier to justify.
   Security patches, version upgrades, and technical debt retirement are easier to vote through than risky product initiatives; they also carry clearer “don’t break chain” legitimacy.

2. Continuity breaks are common because teams are hard to institutionalize.
   Attrition and disbandment events are not anomalies—they are consistent with procurement systems that lack durable contracting and professional governance execution.

3. Professional vendors are harder to attract because the procurement environment is unstable.
   When funding is episodic, culturally contested, and politically mediated, high-quality vendors self-select out.

4. Delivery becomes path-dependent on a few “known” contributors.
   This increases bus factor risk and creates fragile single points of failure.

7.1.5.7 Key takeaway

Terra Classic’s L1 delivery constraints are not only technical. They are institutional:

The chain operates with global talent, but without sufficiently strong procurement scaffolding to reliably select, contract, and retain institutional-grade vendors. This produces predictable outcomes: team churn, governance-mediated execution risk, and a backlog dominated by maintenance rather than compounding product delivery.

7.1.6. What the evidence implies: Terra Classic is maintained, but not meaningfully “built” as a product platform

7.1.6.1 The maintenance signal is strong (and explains why the chain still runs)

Evidence (delivery pattern, 2022–2026): The post-crash L1 delivery record is dominated by survival work (restart, security patches, chain parity upgrades, IBC/oracle stability, governance module tweaks) and ongoing infrastructure/tooling upkeep (Station/finder forks, endpoints, relaying support).

Interpretation: This is meaningful work: it preserves baseline chain viability and prevents obsolescence. It also defines the ceiling of what “developer activity” has meant on Terra Classic: not roadmap-driven product creation, but continuous maintenance to keep the lights on. When maintenance is the dominant output, “activity” can look healthy in commits/upgrades while still producing little new demand (which is consistent with the demand/fees picture established earlier in Chapter 6).

Key takeaway: The chain’s persistence is itself evidence of sustained maintenance capacity—but maintenance capacity is not the same thing as platform-building capacity.

7.1.6.2 “Multi-team” does not automatically mean “institutional strength”

Evidence (team succession + discontinuities): The L1 timeline shows repeated transitions across groups (volunteer era → funded task forces → later teams), plus periods where continuity was threatened by departures, disbandment, or effective abandonment of workstreams (e.g., teams ceasing activity mid-implementation).

Interpretation: In mature L1s, multi-team delivery tends to be modular and additive (multiple teams building in parallel against a stable product strategy). On Terra Classic, multi-team delivery has behaved more like relay replacement: teams substitute for one another to keep core maintenance moving. This is a resilience pattern—but also a signal that the chain lacks durable institutional scaffolding (vendor selection, contracting, performance monitoring, long-lived technical ownership) that would convert “teams exist” into “platform is being built.”

Key takeaway: The L1 is maintained by succession, not built by compounding teams.

7.1.6.3 The product platform gap: “staking as the only native product” is not an insult—it’s a classification

Evidence (scope of shipped work): The documented output emphasizes upgrades, compatibility, security, and operations. It does not present a clear sequence of new L1 product primitives launched post-crash (i.e., new native demand engines with measurable adoption), and it repeatedly frames delivered work as maintenance, parity, and technical debt reduction rather than new product surfaces.

Interpretation: This implies Terra Classic functions more like a maintained staking substrate than a product platform. A “product platform” requires at least two compounding loops:

1. A platform loop (new primitives → more builders → more apps → more usage → more fees), and

2. A distribution loop (marketing/BD, integrations, liquidity programs, developer funnel).

Chapter 6 already established weak on-chain economic throughput; Chapter 7’s L1 delivery record explains a major upstream cause: engineering spend/time has prioritized survival and parity, leaving the platform loop underpowered.

Key takeaway: Without shipping new primitives or a credible path to them, Terra Classic’s L1 value proposition stays structurally narrow.

7.1.6.4 Incentives and governance behavior reinforce maintenance dominance

Evidence (governance + incentives narrative): The “L2 Paradise, L1 Purgatory” framing and associated governance observations describe a system where validators hold disproportionate influence, participation quality is uneven, and incentives can push effort toward L2/private benefit rather than shared L1 platform improvements.

In parallel, builder funding dynamics show persistent tension around paid work: volunteerism is culturally rewarded, while requests for systematic funding often face backlash and high friction. This is documented as an ecosystem-wide incentive problem (not only a social one).

Interpretation: When a system simultaneously:

• treats spending as suspect,

• praises unpaid work as moral proof,

• and lacks an institutional procurement layer,
  it creates an equilibrium where maintenance survives (because it is urgent) but platform-building stalls (because it is discretionary, contested, and slow to fund).

Key takeaway: Terra Classic’s delivery constraints are not primarily technical—they are incentive- and governance-mediated.

7.1.6.5 “Maintained, not built” has predictable downstream effects on the app layer

Evidence (ecosystem positioning): The Classic Chaos analysis explicitly describes limited broader visibility and the absence of cohesive marketing/distribution structures post-crash, with governance discourse concentrated among a narrow subset of stakeholders.

Interpretation: If L1 is maintained but not built as a platform:

• L2/app builders face a thinner demand base and weaker distribution.

• “Ecosystem lists” can inflate perceived breadth, while measurable adoption remains concentrated in a small subset (addressed in Chapter 7’s inclusion criteria and the ecosystem overview sections).

This is why later parts of Chapter 7 must focus on Tier A measurable apps and treat the remainder as narrative inflation unless hard metrics exist.

Key takeaway: The app layer’s “real adoption” ceiling is downstream of L1 platform-building and distribution capacity—not only of “how many projects exist.”

7.1.6.6 Minimum-viable interpretation for investors and contributors

Evidence: The L1 has demonstrated the ability to keep functioning through upgrades, parity work, and operational continuity across multiple eras/teams.

Interpretation: That achievement should be recognized—but it leads to a sober classification:

• Terra Classic as an operating chain: resilient enough to be maintained.

• Terra Classic as a product platform: not yet operating like a platform that compounds adoption.

Key takeaway: The strongest evidence supports a “maintenance-first chain” characterization. Any thesis that expects a platform re-rating must be supported by a visible transition from maintenance delivery to product and distribution delivery—with governance and funding mechanics that can sustain it.