Terra Classic Market-Module 2.0

Proposals
1

Terra Classic Market-Module 2.0

A net-deflation engine that can reopen now, throttles itself as supply shrinks, and cannot be trick-printed through stale prices.

Context & Goals

2022 taught two hard lessons:

  • Unlimited capacity kills – raising base_pool and shortening pool_recovery_period (PRP) let traders mint faster than the market absorbed, destroying LUNC.

  • Hard $1 peg is lethal – valuing UST at $1 while it traded at pennies forced hyper-inflation.

Today (28 May 2025) we sit on:

  • 6.50T LUNC

  • 6B USTC

  • Burns are ≈ 1.3B LUNC/month (0.02%)

The community wants the Market Module (MM) back as soon as possible to restore utility and fee flow — but will only accept continuous net supply decline.

How the Market Module Actually Mints

2.1 base_pool — the “virtual SDR reserve”

When you swap USTC → LUNC (or vice versa), the module simulates a virtual SDR pool. It does:

  • Converts USTC to SDR using oracle price

  • Balances the virtual constant-product AMM

  • Updates SDR “debt” from the swap

Formula (simplified):

ΔLUNC_out ≈ ( SDR_spent / SDR_pool_after ) × LUNC_pool_before

A larger base_pool lets a single swap mint more LUNC before the price shifts.

2.2 PRP — the Refill Timer

After a swap, a deficit d is remembered.

Each block:

d_next = d_current × (1 − 1 / PRP)

  • Short PRP → fast refill → can mint again soon

  • Long PRP → slow refill → minting delayed

Daily Mint Capacity:

mint_cap_day ≈ 2 × base_pool / (PRP / 14,400)

(14,400 ≈ blocks per day on Terra Classic)

Net-Deflation Rule (Hard, Epoch-Based)

At the first block H₀ of every 30-day epoch:

taxburn_30d_token = Σ burns of token [H₀−30d , H₀−1]

allowance_token = min(taxburn_30d_token × 0.80 , 100,000 SDR)

Each token (USTC and LUNC) has:

  • Independent mint limit

  • 80% of tax burns re-mintable

  • 100k SDR max cap per token

Once allowance_remaining_token hits 0, minting stops until the next epoch.

Adaptive base_pool & PRP for the Epoch

4.1 Pick a Burst Factor

Default F = 0.07 → Max 7% of allowance printed per day

desired_daily_cap = allowance × F

4.2 Solve for base_pool

base_pool_raw = desired_daily_cap × PRP / (2 × 14,400)

4.3 Supply-Scaled PRP

PRP = max(14,400, 14,400 × (S / 1T))

Example:

6.5T supply → PRP ≈ 93,600 blocks (6.5 days)

4.4 Final Clamps

base_pool = min(base_pool_raw, 0.00010 × mcap_in_SDR, 5,000,000 SDR)

Example for the First Epoch (Today)

| Item | Value |

|-------------------------|-----------------------------|

| burns_30d (B₀) | 1.3B LUNC |

| allowance = 0.8 × B₀ | 1.04B LUNC ≈ 81k SDR |

| PRP (6.5T supply) | 93,600 blocks |

| desired_daily_cap (F=0.1) | 0.104B LUNC |

| base_pool_raw | ≈ 8.3k SDR |

| base_pool after clamps | 8.3k SDR |

| theoretical mint/day | ≈ 32M LUNC (2.6k SDR) |

Since 32M < 104M, the PRP clamp is the active brake, not the burst factor F.

Live Price Input & Anti-Manipulation Guards

| Component | Rule |

|-----------------------|----------------------------------------------------------------------|

| Price vote period | 5 blocks ≈ 30s |

| USTC price | price_uusd(USTC) = voting-power-weighted median this period |

| Quorum auto-kill | If <50% VP for 25 blocks → MM.enabled = false until 5 periods OK |

| TWAP sanity clamp | Swap fails if peg price differs >10% from 45-block CEX TWAP |

| Stable→stable route | Hard-disabled in code (ErrStableSwapDisabled) |

Absolute Brakes & Governance

  • A ⅔ super-majority can close the Market Module (MM) at any time.

  • Caps cannot be raised via governance.

  • MM is inherently capped by:

  • 30-day burn stats

  • Base pool clamps

  • Oracle enforcement

Scenarios

7.1 Bull-but-Boring (Utility Returns)

LUNC in Normal Growth Scenario

LUNC burns double to 2B/month by epoch 3.

PRP still >3 days, base_pool limited by allowance.

| Epoch | Burns | Allowance | Mint (≤) | Net Δ | Supply |

|-------|---------|-----------|----------|-----------|------------|

| 1 | 1.3B | 1.04B | 0.78B | –0.52B | 6.4995T |

| 2 | 1.6B | 1.28B | 1.02B | –0.58B | 6.4989T |

| 3 | 2.0B | 1.60B | 1.24B | –0.76B | 6.4981T |

Total LUNC deflation after 3 epochs: 1.9B (0.03%)

USTC in Normal Growth Scenario

| Epoch | Burns | Allowance | Mint (≤) | Net Δ | Supply |

|-------|-------|-----------|----------|--------|--------|

| 1 | 50M | 40M | 30M | –20M | 5.98B |

| 2 | 75M | 60M | 48M | –27M | 5.95B |

| 3 | 100M | 80M | 64M | –36M | 5.91B |

Total USTC deflation after 3 epochs: 83M (1.38%)

7.2 Flash-Crash & Oracle Outage

Event:

USTC dumps to $0.004; two top validators go offline.

Quorum falls below 50% for 30s → MM shuts automatically.

Burns collapse during the next epochs.

LUNC in Crisis

| Epoch | Burns | Allowance | Mint | Net Δ |

|--------|-------|-----------|------|----------|

| crash | 0.2B | 0.16B | 0 | –0.20B |

| +30d | 0.2B | 0.16B | ≤0.16B | –0.04B |

| +60d | 0.2B | 0.16B | ≤0.16B | –0.04B |

USTC in Crisis

| Epoch | Burns | Allowance | Mint | Net Δ |

|--------|-------|-----------|------|--------|

| crash | 10M | 8M | 0 | –10M |

| +30d | 10M | 8M | ≤8M | –2M |

| +60d | 10M | 8M | ≤8M | –2M |

(*) Oracle kill-switch triggered → inflation = 0

Even in a disaster, deflation continues for both tokens.

Spread-Fee Policy for MM Swaps

| Condition | Fee | Notes |

|------------------------------|--------------------------|--------------------------------------------------------|

| MM disabled | — | No swap, no fee, no burn |

| MM enabled & allowance > 0 | 0.35% of notional | Collected in output asset (LUNC or USTC) |

| Allowance exhausted | — | Swap refused |

  • 0.35% keeps arbitrage profitable

  • No double tax – replaces the 0.5% chain burn tax

  • Fee split: 50% burn, 50% Oracle Pool

Oracle Module Compatibility

To reactivate MM with live pricing:

  • :white_check_mark: Add USTC to the oracle vote set

  • :white_check_mark: Remove $1 peg assumption

  • :white_check_mark: Add more CEX/aggregator price feeds

  • :white_check_mark: Validators must update feeders

  • :warning: Feeder binary rewrite is recommended

  • Support modern APIs

  • Add fallback logic

  • Improve error handling

These changes must be deployed before reopening MM. Otherwise, price input will be invalid → MM disabled.

Roadmap

  • :wrench: Code merge & audit (~500–1,000 LOC)

  • :test_tube: Public testnet with simulated price spikes, quorum drops, burn bursts

  • :rocket: Mainnet upgrade (two-step):

  • Deploy MM in inactive mode

  • Activate at next epoch boundary post-burn stats verification

  • :bar_chart: Dashboards/API:

  • Show taxburn_30d

  • Show allowance_remaining

  • :date: 90-day post-mortem:

  • Adjust 80% coefficient or F only via hard fork

What We Gain

  • :white_check_mark: Immediate reopening — utility & arbitrage from day 1

  • :chart_decreasing: Guaranteed deflation — must shrink supply every epoch

  • :brain: Oracle-safe — 30s lag = okay, 75s lag = MM shutdown

  • :repeat_button: Elastic throttle — refill slows as supply shrinks

  • :fire: Spread fees:

  • 50% burn

  • 50% to Oracle Pool

The printer is leashed to yesterday’s bonfire — and the leash gets shorter as the fire dies out.

Voluntary Burns

At present, voluntary burns (e.g., Binance, user burns to burn module terra1...anxu) are a large portion of total burns.

Proposal:

Exclude voluntary burns from taxburn_30d calculation to:

  • Keep voluntary burners engaged

  • Avoid reducing minting capacity unnecessarily

Any allowance increase should be discussed after testing and deployment.

Important Notes

  • Burn data cannot be predicted

  • MM behavior depends on assumptions and must be tested

  • Adjustments to parameters like F and the 80% ratio should be done on testnet first

StrahCole ✰

Vegas

2

I am not a strong AI fella or prompt engineer. Here is my Chat GPT prompt:

“This is an awful proposal which is very hard for the reader to understand. It lacks key points to take away and drowns in tech babble. Can you please give me a better proposal that more clearly distinguishes between how the MM currently works and how it is intended to work in the 2.0 iteration. Also - we need to be less technical and more readable. Please also make clear, how the refill timer distinguishes from the original terra delta mechanism - because currently I don’t see a difference.”

Output:

:rocket: Terra Classic Market Module 2.0

A safer, smarter way to bring back utility — with built-in deflation, real-time pricing, and strong safeguards.

:magnifying_glass_tilted_left: Why We Need a New Market Module

In 2022, the original Market Module enabled on-chain swaps between LUNA and Terra stablecoins (like UST) — but two critical flaws led to collapse:

  • Unlimited Minting: Without hard limits, traders could print stablecoins far faster than the market could absorb, causing supply to explode.
  • Fixed $1 Peg: Assuming UST was always worth $1, even when it traded far below, triggered runaway inflation.

:brain: What We’ve Learned

The community wants the Market Module (MM) back to restore utility and fee flow. But to earn trust, it must be strictly deflationary, oracle-safe, and immune to manipulation.

As of 28 May 2025:

  • :fire: 6.5 trillion LUNC in circulation
  • :ice: 6 billion USTC
  • :axe: Monthly LUNC burns: ~1.3B (≈0.02%)

:scroll: How the Original Market Module Worked

The original MM used a virtual constant-product AMM:

  • Swaps (UST ↔ LUNA) used oracle prices, adjusted by a virtual SDR pool.
  • There was no real liquidity — the pool was virtual, and swap costs increased as more was minted.
  • A “terra delta” tracked the imbalance between minted and burned amounts.
    • This delta decayed over time, restoring swap capacity gradually.

But: there were no hard minting limits, and the $1 peg was hardcoded, even when the market price collapsed.

:construction: What’s New in Market Module 2.0

MM 2.0 preserves the virtual AMM model, but wraps it in hard constraints to ensure that only a limited, deflationary amount of minting is ever allowed — and only with live price input.

:puzzle_piece: Key Changes at a Glance

Feature MM (Old) MM 2.0
Virtual AMM :white_check_mark: Yes :white_check_mark: Yes
Terra Delta :white_check_mark: Yes (implicit) :white_check_mark: Yes (now called PRP)
Burn-based Mint Cap :cross_mark: None :white_check_mark: Based on 30-day burns
Max SDR Allowance :cross_mark: None :white_check_mark: 100k SDR cap per token per epoch
Adaptive Refill :cross_mark: Fixed decay :white_check_mark: Slower refill as supply grows
Peg Assumption :cross_mark: Always $1 :white_check_mark: Uses live oracle + CEX sanity check
Oracle Safeguards :cross_mark: None :white_check_mark: Quorum enforcement, kill-switch
Swap Fee :cross_mark: Slippage only :white_check_mark: 0.35% spread (50% burn, 50% oracle)

:counterclockwise_arrows_button: How MM 2.0 Works

1. SDR-Based Swap Calculation

  • The MM still uses a virtual SDR pool to simulate swaps.
  • Swapping USTC ↔ LUNC:
    • Converts input token to SDR via oracle
    • Applies a constant-product pricing curve
    • Yields output token (in SDR terms), minus spread

2. Pool Recovery Period (PRP)

  • PRP is the new term for the old terra delta refill logic.
  • Each swap creates a virtual debt in the pool (imbalance).
  • That debt decays slowly, just like the old delta — meaning swaps get cheaper over time.
  • But now, refill speed scales with supply:
    • More LUNC in circulation → longer PRP → slower minting

MM 2.0 reuses the proven idea of a decaying imbalance, but makes it supply-aware and strictly bounded.

3. 30-Day Burn-Based Minting Allowance

Every 30 days (1 epoch):

  • The system looks at on-chain burns for LUNC and USTC.
  • Each token gets a mint allowance of:
    • min(80% of burns, 100,000 SDR)
  • Once allowance runs out: minting stops until the next epoch.

4. Daily Mint Rate is Throttled

Even within the 30-day allowance, minting is rate-limited:

  • A burst factor (e.g. 7%) determines how much of the allowance can be minted per day.
  • Combined with the PRP, this prevents sudden large mints.

:chart_decreasing: Designed for Guaranteed Deflation

  • You must burn to mint: new issuance is capped by prior burns.
  • Slower refill as supply grows: large supply means less flexibility.
  • No way around it: caps are enforced at protocol level, not by governance.

:shield: Oracle & Price Safety

Feature Description
Oracle Quorum <50% voting power for 25 blocks → MM auto-disables
Live Price Input Prices come from median validator vote (5-block interval)
Sanity Check (TWAP) If price diverges >10% from CEX average (45 blocks), swap fails
Stable-to-Stable Swaps Fully disabled at code level
Governance Override MM can be shut off by 2/3 vote — but not uncapped

:money_with_wings: Spread Fee Policy

  • All swaps pay a 0.35% fee, deducted from the output.
  • Fee is split:
    • 50% burned
    • 50% goes to Oracle Pool
  • This replaces the 0.5% chain tax for MM swaps.

:bar_chart: Example for the First Epoch

Metric Value
30-day LUNC burns 1.3B
Allowance (80%) 1.04B LUNC ≈ 81k SDR
Supply-scaled PRP 93,600 blocks (~6.5 days)
Theoretical mint per day ~32M LUNC (2.6k SDR)

→ Result: Daily minting is well below the max. The PRP is the limiting factor, not the burst cap.

:test_tube: What’s Left Before Launch

  • Final code audit & cleanup
  • Testnet simulation with price shocks and burn patterns
  • Oracle module updates:
    • Add USTC pricing
    • Remove fixed $1 peg logic
    • Improve error handling
  • Mainnet deployment:
    • Launch MM in inactive mode
    • Activate with verified burn stats

:bullseye: What We Gain

  • :white_check_mark: Real utility: re-enable USTC ↔ LUNC swaps
  • :locked: Guaranteed net deflation: minting never exceeds 80% of burns
  • :brain: Oracle-safe: system halts if price data is stale or quorum is low
  • :counterclockwise_arrows_button: Adaptive throttle: refill slows as supply grows
  • :fire: Fees reduce supply and support oracle operations

:wastebasket: Voluntary Burns

To encourage community-led burns:

Voluntary burns will not count toward the 30-day allowance.

This ensures:

  • Burners (e.g. Binance) stay engaged
  • The system isn’t unfairly “refueled” by voluntary activity

:pushpin: Final Summary

Market Module 2.0 is permissionless utility with enforced discipline.

  • It’s backed by burned supply
  • It adapts to current market conditions
  • It enforces live pricing with safety brakes
  • It cannot be used to overmint — ever

The printer is leashed to yesterday’s bonfire — and the leash gets shorter as the fire dies down.

1 Like
3

I think what GPT overlooked here: One of the key takeaways is also: THERE IS NO 1$ PRICE PEG in this proposal. I don’t see any demand for USTC if it’s not a stable. Why using the MM instead of going to Terraswap to swap my USTC? I don’t get it.

3 Likes
4

Until Vegas will add it to the original text, I’ll put the amendment here:

13 Important notes

The tax burn amount for the coming months cannot be predicted, so the impact on the MM plan is based on assumptions. Parameters and mechanisms can and should be adjusted during the public testnet phase, and it is important to thoroughly test the impact and mechanisms on the testnet before considering a mainnet release.

This is a signalling proposal that governance and the community want to see this approach implemented. The implementation will be a voluntary effort/contribution of StrathCole, thus there are no fixed deadlines. An alternative option is that a paid team decides to step forward and quote for the work and gets governance approval. This could eventually speed up the implementation timeline.

14 Risks

The risk of hyperinflation is mitigated by the strict limits of minting depending on the tax burns of the previous period. In addition a limiter capped to the total supply of this limit has to be implemented as an additional safeguard.

The main risks of this implementations are:

  • reduced burns of either LUNC or USTC (not both) in case the swapping is only used very rarely and one-sided
  • community disappointment to unmet expectations

15 Non-Tech summary

To summarize the idea in non-technical terms, we can describe it as follows:

Important: This is NOT a repeg proposal and NOT treating USTC as a stable asset.

We will implement safeguards to the market module, so it cannot mint more coins than 80% of what was burnt during the previous 30 days by the tax (manual burns by wallets are ignored because it would be unfair to include them in the allowance).

The price of USTC will be reported by the chain oracle and no longer be fixed at $1 internally. This allows swapping at the real market value, giving the correct amount or LUNC for USTC and vice versa.

When swapping USTC to LUNC, LUNC is minted and USTC is burnt. When swapping LUNC to USTC, USTC is minted and LUNC is burnt. This is how the market module worked initially and should continue to work. The minting is safeguarded by the rules mentioned above.

The fee of each swap (which is not including the tax, but 0.35% spread fee) will be distributed 50%:50% between burns and the Oracle Pool.

Incentives to use the MM to swap could be arbitrage options between CEX prices, DEX prices and the Market Module. This occurs because the on chain price of the oracle is only updated each 30 seconds, which means it lags behind CEX prices often. DEX prices also often deviate among each other and CEXes which offers further potential arbitrage.

Furthermore, using the MM to swap might be an incentive to users that want to cause burns of one side (either LUNC or USTC) during their swaps.

Most of the risks are mitigated by safeguards. But there is still a risk of community disappointment if they expect an effect of these measures beyond what is achieved. Also it is possible that the burns would be lower than expected, in case users solely use the MM to swap USTC to LUNC until the mint limit is reached, but this would in turn have the benefit of increased burns of USTC.

1 Like
5

See bottom part of #15 in the comment below

6

Thank you for the clarifications :folded_hands:

7

Totally supporting the proposal. Open the market module 2.0 immediately on testnet. It would be much better if we have LUNC liquidity on Astroport and on Osmosis. To increase Liquidity and arbitrage on-chain. LUNC liquidity on Astroport means Lunc getting connected back to cosmos. Terra liquidity alliance erisprotocol LUNC whitelisting will be imminent.

https://common.xyz/terra-luna-classic-lunc/discussion/1273501-proposal-signal-to-inject-lunc-liquidity-into-osmosis-and-astroport-terra-to-strengthen-terra-classic-ecosystem

8

I think a Q/A should be included here, too. If you got further questions and/or concerns, just post.

Q: Can this cause further LUNC hyperinflation?
A: No. The minting from swaps is limited to a certain amount, based on the tax burns of the previous period.

Q: Is this re-pegging USTC?
A: No. USTC is a speculative asset and this idea treats it like that. It is valued at market price for the swaps.

Q: What about Binance burns? They stopped burning when we minted previously.
A: We exclude manual burns (sent to the anxu wallet) from the calculation of the mint allowance. Only burns from the tax and MM swap fees will be included.

Q: What is the “mint allowance”?
A: It is the amount of LUNC and USTC that is allowed to be minted during a period. The actual swapped amount can be higher, because the allowance is increased again by swaps to the other side.

Q: ??? Can I have an example?
A: Sure: Imagine 1 USTC is worth 200 LUNC. During the previous period we burnt 500M LUNC by the tax. At a 80% allowance, this would allow the MM to mint 400M LUNC during the next period. So if now 2,000,000 USTC are swapped to LUNC through the MM, this would mint 400M LUNC in turn, effectively disabling further swaps in that direction. But if swaps now happen from LUNC to USTC (e.g. 100M LUNC for 500,000 USTC) then these 100M LUNC would again be allowed for minting.

Q: But isn’t that pointless then?
A: No, each swap incurs a fee of 0,35% which is distributed to burn (50%) and Oracle Pool (50%). The more swaps, so the more often the mint/burn happens, the more fees are generated.

Q: Okay, but what amount of swaps can we expect? Wouldn’t everyone only swap their USTC rewards to LUNC?
A: That could happen, but even then it would in turn lower the USTC supply. But when you look at the LUNC/USTC ratio during the past months, you realize that the value fluctuated mostly between 190 and 230 LUNC per USTC. This suggests that people use both directions on trades.

Q: Right, what volume can we expect then?
A: That is very hard to estimate and will depend on the on chain volume and also on arbitrage. The LUNC/USTC pairs on our DEXes had a volume of approximately 120-130k USD a month recently. Assuming this would be split equally between the DEXes and the MM, this would lead to a MM volume of maybe 30-40k USD worth.

Q: But you said USTC is valued at market value. How would arbitrage be possible?
A: The oracle prices on chain are reported every 30 seconds. Especially during high volatility, CEX prices can fluctuate quite quickly. Also DEX prices have shown significant volatility during past months, which might offer arbitrage options with the MM. It is not guaranteed though.

Q: What are the major risks? And how are they mitigated?
A: As said, the risk of hyperinflation is mitigated by very strict boundaries and limits. The risk of technical mistakes in the implementation shall be mitigated by thorough review and, if the community is willing to pay, a code audit (which would be recommended). In the unlikely case of a major flaw, 33.4% of validators could “emergency-halt” the chain for a hotfix. This is not expected to be necessary.
The likeliest risk is too high expectations which can then lead to disappointment.
Another risk is losing a portion of the LUNC burns (through MM minting) in case the MM would only be used one-way (USTC->LUNC). The equivalent of USTC then would be burnt in excess.

Q: Who is developing it? Is it ready? What is the timeline?
A: I (StrathCole) am offering to develop this voluntarily. As I do this in my free time, there is no fixed timeline possible. I expect the pure implementation (without the testing) to take 2-3 weeks. There is always the option that a team can quote for the work and get approval by the community to implement this instead.

Q: If you do it voluntarily, why do you need a proposal?
A: Because I cannot spend the time of development without a signalling proposal that shows this approach as shown is wanted by the community/governance. There have been a lot of reservations against minting of any form and also opening the Market Module. So approval for this is a prerequisite for me personally to start development work on it.

Q: How long will the tests take?
A: That is not foreseeable. As this is a critical part of the blockchain, we need to stress-test this approach in all possible ways. This includes simulated price manipulation, oracle feeder outages, price volatility, swap volume, etc. The more helping hands will take part in the testing and verification the better.

Q: As review/audit was mentioned, this is not free work?
A: No. The team that would quote for a review, or the audit company offering an audit would certainly request funds for that.

2 Likes
9

Just 2.

What tests have been done on our oracle price feeds to protect against missing blocks and price distortion (as seen recently on ATOM) and how many Validators have or will participate? This was the focal point and primary attack vector that allowed pools to be drained, breaking trust and collapsing the original protocol.

We are or should be aware of insiders in LUNC using privy information and manipulating not only pump and dumps, but using this leveraged information position, to ensure any momentum gains through key price points that traders live off are immediately stopped. So, they are circulating and litter our chart with stains of their actions (buying, selling & futures shorts). I recently detailed the most recent example extensively on X from last week and “they” just finished yesterday, successfully stopping the breakout momentum, again. LUNC holders again thinking it was something more. Not cool. You can see the fomo buying up high where shorts start.

What pre-cautions are being taken for this, considering the attack vectors we could open up and have considerations been taken into account of where information on the full plans for the MM have been shared, particularly where weakness and risks in the MM were/have been/are discussed?

We should be sure that they are not waiting to exploit any weakness based off the information they are being fed and that the information is secure, being as we allow them and assist them in their market practices here, which are fully legal even if very foul. They do cost our holders money, wether we acknowledge it or not. For every seller, there is a buyer and visa vis. I would just like us to be extra vigilant on both the above and not allow a repeated attack, through the previous blueprint “on how to” already public, without us at least being as sure as we possible can be, that we have tried to best to address clear risks beforehand.

The aiding we have of insider traders being a particular cause for concern. Which is a shame, this could be an exciting development. I would just like to note we have open 2x new pools LUNC/USDC. We should be extra vigilant and more sure, considering the timing and known insider trading. I am happy to spend time with any community members not aware and I can walk us through charts live to show us the pictures they leave. Not highly sophisticated but you don’t need to be if you’re from the inside, which is why in TradFi, it’s illegal.

10

https://common.xyz/terra-luna-classic-lunc/discussion/1276337-Terra%20Classic%20Market-Module%202.0

11

Introducing the Strategic Recursive Liquidity Model (SRLM)

Introduction: As Terra Classic (LUNC/USTC) prepares for a potential resurgence and technical revitalization, it is imperative to explore innovative mechanisms that go beyond linear burn models. The Strategic Recursive Liquidity Model (SRLM) is a vision-driven, self-reinforcing liquidity system designed to enable organic USTC repeg progression, long-term LUNC value consolidation, and systemic decentralization—all without requiring billions in external capital.

1. The SRLM Concept in Brief: SRLM utilizes a recursive cycle based on:

  • Spot-based incremental acquisitions of LUNC/USTC
  • High-leverage strategic long positions (10x suggested baseline)
  • Realized profit funneling back into the liquidity loop via burn and reentry
  • Supply-side absorption via on-chain swap modules and DEX routing

This creates a dynamic flywheel:

Buy → Leverage → Profit → Burn → Buy Again → Supply Compression → Value Surge → Repeat.

2. Capital Flow and Hedging Strategy: SRLM can begin with a hypothetical $1 billion pool, split as follows:

  • $100M: Initial long position (10x) opened near a key price range (e.g., $0.00007 LUNC)
  • $900M: Segmented into $100M spot tranches, deployed incrementally to minimize market shock

Supply Impact:

  • Assuming spoof ratio of 70%, each $100M tranche may exhaust lower-depth order books and move LUNC price significantly.
  • As price increases, long position gains expand exponentially → profit cycles re-enter model.
  • A hedge layer (short counterpositions) can be optionally employed to minimize loss risk from retracements.

Goal: Achieve multiple deflationary loops that compress LUNC and USTC circulating supply, all while extracting net capital efficiency.

3. On-Chain Integration Proposal:

  • Oracle-Synced Dynamic Entry: Each burn triggers a smart contract that reevaluates price and liquidity levels before reinvestment.
  • Auto-throttle mechanism: If long exposure exceeds risk thresholds, the strategy pauses and consolidates.
  • Validator-assisted confirmation layer: Community validators approve thresholds and transparently verify burn wallet distribution.

4. Why SRLM Is Not Just Theory: Unlike traditional buy-and-burn plans, SRLM is:

  • Self-compounding: profits fund future cycles
  • Less capital-dependent: strategic leverage compensates for capital scarcity
  • Decentralization-friendly: all transactions, swaps, and burns are transparent and on-chain

5. Key Risks & Mitigations:

  • Market Maker Friction: To avoid triggering bot-based frontrunning, spot buys must be randomized in structure.
  • Community misunderstanding: Messaging must clearly state this is not an instant repeg but a recursive, long-term model.
  • Oversight requirement: DAO-level supervision is critical to avoid misuse.

6. How It Complements MM2 (Market Module 2.0): While MM2 focuses on reactivating the internal swap logic within strict mint/burn limits, SRLM can operate in tandem:

  • SRLM generates off-chain and DEX-driven liquidity demand
  • Its burns indirectly increase MM2 mint capacity
  • Together they form a hybrid liquidity model—organic + systemic

Conclusion: The SRLM does not aim to replace the Market Module or DAO strategies—it augments them. In an era where centralized exchanges quietly accumulate influence, it’s time to explore liquidity strategies that empower the chain and reward long-term belief. Let SRLM be that experiment.

Built by the community. Fueled by strategy. Designed for the comeback.

We welcome feedback, improvements, simulations, and developer contributions to expand this model into actionable infrastructure.