7.3.1. Why incentive alignment is the bottleneck (not “ideas”)

Terra Classic’s post-crash builder economy is shaped less by technical possibility and more by incentive compatibility: what kinds of work are socially rewarded, how funding is approved (or blocked), and which actors capture value when something ships.

Two facts can be true at the same time:

• The chain can be technically maintained and upgraded by committed contributors (see 7.1).

• The ecosystem can still fail to produce new adoption-driving products because the builder incentive environment selects against professional, paid, accountable delivery and selects for low-budget, low-scope, volunteer survival projects.

The evidence in this section shows a recurring pattern: “builders should work for free (or for their bags)” becomes an implicit gatekeeping norm. This raises the cost of building (burnout, churn, and under-investment), and it also distorts which applications survive—often those owned by validators or those that can monetize indirectly—rather than those best positioned to grow the chain.

7.3.2. The incentive stack: who pays, who benefits, who decides

Terra Classic’s builder incentives can be understood as an “incentive stack” with four interacting layers:

1. Funding sources

• Community Pool (governance-approved spends).

• Donations / sponsorships / self-funding (private capital, often informal).

• Validator-derived revenue (commission income, side revenues, brand/community monetization).

2. Approval gate

• Governance vote, where outcomes are materially shaped by validator participation quality (discussed in Chapter 6) and by community attitudes toward spending.

3. Builder compensation norms

• A recurring expectation that “serious” contributors should first prove themselves via unpaid delivery; paid funding requests trigger scrutiny and backlash.

4. Value capture

• When L2/apps exist but activity is small, the main scalable “product” that reliably monetizes is still base-layer security and staking (and for some, validator operations). This creates structural bias: the actors already earning (validators) are frequently the ones gatekeeping spend approvals, while builders without existing revenue are asked to absorb risk “for free.”

7.3.3. Evidence: “work-for-free” pressure is a persistent, documentable norm

The “work-for-free” dynamic is not an abstract complaint; it is visible in primary-source statements and debates from 2022–2026.

A) Explicit statements rejecting unpaid expectations (reveals the norm exists)

Community members repeatedly surface the expectation itself, often in the form of pushback:

• “As soon as the community understands that devs don’t work for free and shouldn’t work for free the better.”

• “People don’t work for free as a rule.”

• “We don’t have a grants programme” (stated as a structural limitation).

• “So you want devs to work for free?” (raised directly as a dispute frame).

These statements matter because they show the social baseline: paid work is treated as controversial enough that people must explicitly restate basic labor economics.

B) Advocacy for volunteerism as a default sourcing model

Primary-source excerpts also show volunteerism being proposed as the solution to capacity constraints:

• “If we want more devs, in our current state then yes, volunteers.”

• “you could place a add on X looking for volunteers”

• “people might be happy to work philanthropically, even if no pay involved.”

This is not automatically “wrong” in a crisis-recovery context. The problem is what happens when the ecosystem tries to transition from survival to growth: volunteerism becomes an entrenched identity test rather than a temporary phase.

C) Builder-side evidence of personal cost and unsustainability

One of the clearest documented cases is infrastructure work (IBC relaying) being privately subsidized and later framed as financially irrational to continue without compensation:

• A contributor describes relaying as a severe personal financial loss and states that private funding is no longer sustainable.

• Community commentary explicitly frames relaying as an L1 operational cost that should not be privately funded long-term.

• Discussion shows reputational friction even around small funding requests (“we asked for $10k … everyone lost their shit”), and contributor withdrawal when funding is cut.

This is an important signal: if the ecosystem struggles to pay for core infrastructure externalities (like relaying), it will predictably struggle even more to fund L2 products whose payoff is uncertain and delayed.

D) The “badge economy”: credibility built through unpaid suffering

Several excerpts show a pattern where past unpaid work becomes a defensive credential during funding scrutiny (“I paid out of pocket,” “volunteer developers using their free time,” etc.).

This produces a toxic selection mechanism: only people willing to incur unrecoverable personal costs can consistently gain legitimacy, which filters out professional teams and favors hobbyist or ideology-driven delivery.

7.3.4. Funding backlash is not just emotional; it is an economic design failure

The excerpts show recurring “funding shock” moments:

• builders describe intense backlash at relatively small funding levels

• contributors explicitly attribute project failure to an unsustainable free-labor model (“the free-model of working is ultimately what killed it”)

• participants describe real personal harm from extended unpaid work (burnout, life impact)

From an ecosystem design perspective, this is not a “community drama” issue. It is a capital allocation UX issue:

• No predictable grants lane → every funding request becomes a bespoke political fight.

• No standard procurement pattern (milestones, KPIs, escrow, audit trail) → legitimate work and grift look similar at proposal time → the community defaults to suspicion.

• High social cost of asking for funding → builders under-scope, delay, or avoid proposals entirely → less shipping → weaker demand → more scarcity mindset → repeat.

This creates a self-reinforcing loop that looks “rational” locally (protect the pool) but is destructive systemically (starves growth).

7.3.5. Validator-linked builders: the structural conflict-of-interest vector

In a low-activity ecosystem, the most consistent operational cashflows often sit with validators (commission, ecosystem positioning). That produces a structural advantage:

• validator-linked teams can self-fund longer,

• they can market from an existing distribution channel,

• and they may influence governance outcomes through reputation and voting power (directly or indirectly).

The materials highlight validator-linked ecosystems such as TerraCVita and TerraPort as emblematic of the “volunteer ethos + persistence” model.

A concrete example of how this affects incentives:

• A validator-linked DEX can continue operating even with negligible TVL/volume because persistence can be subsidized by validator economics and community identity, while an independent builder without such revenue faces higher survival pressure.

• The same ecosystem contains explicit advocacy for philanthropic or volunteer labor, which—when coming from actors with ongoing validator revenue—creates an asymmetry: those least exposed to builder poverty are positioned to normalize it.

This does not prove malicious intent. It proves misaligned incentives: rational behavior by individuals can still produce a collectively suboptimal equilibrium.

7.3.6. Why this especially harms “real” L2/app building (not just L1 maintenance)

L1 maintenance can be justified as existential (“chain must run”), making it easier—though still difficult—to fund. L2/apps are different:

• They require risk capital (many experiments fail).

• They require marketing and distribution (users don’t appear because code exists).

• They often require liquidity/incentives before they can produce sustainable fees.

In an environment where:

• funding is sporadic and contested,

• builders are expected to prove themselves unpaid,

• and measurable on-chain demand is already weak (see Chapter 6),

…the ecosystem will systematically under-produce the kind of apps that could reverse stagnation.

Even the “successful” measurable DeFi examples illustrate the ceiling:

• Garuda DeFi shows measurable TVL/volume relative to Terra Classic, but the absolute scale is still very small in global DeFi terms.
  This reinforces the capital allocation problem: without deliberate incentives, small ecosystems stay small.

7.3.7. What incentive alignment would look like in a credible recovery plan

A realistic recovery plan does not require “spending everything.” It requires converting funding from political events into an execution system.

A) Minimum viable builder funding system (MV-BFS)

• A grants lane with clear eligibility + standard templates (scope, milestones, auditability).

• Small tickets by default (reduce risk, increase experimentation throughput).

• Milestone-based releases (de-risk governance fear of “grift”).

• Post-mortems for both success and failure (normalize experimentation).

B) “Infrastructure is a public good” rule

Core externalities (relaying, indexers, SDK maintenance) should not depend on private patronage. The primary sources show the system currently drifts into exactly that.

C) Explicit anti-hypocrisy constraint

If validator-linked entities argue for volunteer labor, they should be required (socially or formally) to disclose whether they are benefiting from validator cashflows and whether they fund builders themselves. This is about reducing information asymmetry, not moralizing.

D) Outcome metrics that force focus on adoption

Tie funding not to “announcements,” but to measurable outcomes aligned with Chapter 7’s inclusion criteria:

• retained active wallets,

• sustained volume/TVL where applicable,

• number of apps with measurable real users,

• on-chain fee growth that improves security budgets.

7.3.8. Key takeaway

The evidence supports a clear conclusion: Terra Classic’s builder incentive environment has been shaped by a prolonged scarcity mindset that normalizes unpaid labor and treats funding requests as reputational risk.

This produces predictable second-order effects:

• fewer credible teams attempt to build,

• those who do are pushed toward minimal-scope, low-cost survivability,

• and validator-linked projects gain structural advantages in persistence and narrative positioning.

In practical terms: Terra Classic can remain “alive” under this equilibrium, but it cannot reliably become a competitive product platform without changing how builders are funded, protected from backlash, and held accountable.