No-Mint version

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

This is based on the original “Terra Classic Market-Module 2.0” draft, but incorporates mechanisms to avoid the mint/burn, which caused concerns among several community members.

If you want a short non-technical summary, please head over to Appendix 1 (Summary) and Appendix 2 (Q/A).

---

1 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 ( 25 June 2025 ) we sit on approx. 6.50 T LUNC and 6 B USTC; burns are just ≈ 1.3 B 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.

---

2 How the market module historically minted

2.1 base_pool — the “virtual SDR reserve”

When you swap USTC → LUNC (or vice versa), the module pretends you are interacting with a virtual SDR pool. The actual calculation involves:

1. Converting the USTC amount to its SDR value using current oracle prices
2. Determining how much LUNC to mint such that the virtual constant-product curve stays balanced
3. Updating the SDR “debt” created by the swap

Simplified speaking, when you swap USTC → LUNC the module poses as an SDR/LUNC AMM whose one side is a virtual pool of size base_pool:

ΔLUNC_out ≈ ( SDR_spent / SDR_pool_after ) × LUNC_pool_before

A larger base_pool lets a single swap give more LUNC before the price moves.

2.2 PRP — the refill timer

After a swap, the module remembers an SDR deficit d (how much the virtual SDR pool is drained). At every block it “refills” a fixed fraction:

d_next = d_current × ( 1 − 1 / PRP )

Each block restores 1/PRP of the deficit. So:

• Short PRP → fast refill → can print again minutes later
• Long PRP → slow refill → must wait hours or days

The total swap capacity per day (if traders drain it fully each time) is approximately:

swap_cap_day ≈ 2 × base_pool / ( PRP / 14 400 )
(14 400 ≈ blocks per day on Terra Classic).

This formula is derived from how much SDR can be depleted and refilled per day while keeping swaps feasible.

---

3 Non-minting approach (epoch-based)

Currently the burn tax on-chain is split 10% to the Community Pool, 10% to the Oracle Pool and 80% to burn.
To avoid any minting of tokens, it is proposed to redirect 60% to a temporary “market module liquidity” pool. While this reduces the immediate burn from the tax to 20%, additional burns will still happen each 30-day epoch (see below).

At the first block H₀ of every 30-day epoch, for each token separately (USTC and LUNC):

• Each token (USTC and LUNC) that reached the market module liquidity pool is moved to a distinct swap pool for the Market Module. This is the amount of that token available for users to swap.
• This is the equivalent of 75% of last month’s tax burns of each token.
• Instead of using minting and burning when swapping through the Market Module, tokens are just taken from and added to this pool.
• At the start of the next 30-day epoch, all remainders in the pools are burnt.

---

4 Adaptive base_pool & PRP for the epoch

We want bursts when volatility spikes, but we must still fit under the monthly allowance.

4.1 Pick a burst factor

Default F = 0.07 → at most 10 % of the current liquidity pool balance can be used in a single day.

desired_daily_cap = pool_balance × F

4.2 Solve for base_pool

Re-arranging the daily-cap formula:

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

4.3 Supply-scaled PRP

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

6.5 T supply → PRP ≈ 93 600 blocks (6.5 days).
When supply falls, the refill gets faster—the faucet shrinks as the tank empties.

4.4 Final clamps

base_pool = min( base_pool_raw, 0.00010 × supply_value_in_SDR, 5 000 000 SDR ) // absolute roof

---

Example for the first epoch (today)

Item	Value
tax_30d (B₀)	1.0 B LUNC
redirected to pool = 0.6 × B₀	600M LUNC ≈ 24,400 SDR
PRP (6.5 T supply)	93 600 blocks
desired_daily_cap (e.g. F = 0.1)	60M LUNC (depending on current balance)
base_pool_raw	≈ 7.9 k SDR
base_pool after clamps	7.9 k SDR
Pool usage per day (max)	2 × 7.9 k / 6.5 ≈ 2.45 k SDR ≈ 60.4 M LUNC

60.4 M > 60 M, so F, not the PRP clamp, is the active brake.

---

5 Live price input & anti-manipulation guards

Component	Rule
Price vote period	5 blocks ≈ 30 s
USTC price	price_uusd(USTC) = voting-power-weighted median this period
Quorum auto-kill	If either asset has price votes from < 50 % VP for 25 blocks → MM.enabled=false until quorum is restored
TWAP sanity clamp	Each swap fails if peg price differs > 10 % from a 45-block Oracle-TWAP (fed by the same oracles)
Stable→stable route	Hard-disabled in code (ErrStableSwapDisabled)

---

6 Absolute brakes & governance

• ⅔ super-majority can close MM any time

---

7 Burns

At the end of the 30-day epoch, all remainders in the pool are burnt. Depending on the swap behavior of users, this can be similar to the burns that would have happened without this approach, or more leaning to one of the two tokens (see summary Appendix 1).

---

8 Scenarios

8.1 Bull-but-boring (utility returns)

Example showing separate calculations for both tokens:

LUNC in Normal Growth Scenario

• LUNC tax proceeds reach 2 B / month by epoch 3, USTC proceeds reach 560 K / month.
• PRP still > 3 days, base_pool limited by allowance.

Scenario a.) Users swap equally back and forth between LUNC and USTC

Epoch	LUNC Tax	USTC Tax	Pool LUNC before	Pool USTC before	Pool LUNC after	Pool USTC after
1	1.3 B	360 K	720 M	216 K	720 M	216 K
2	1.6 B	450 K	840 M	270 K	840 M	270 K
3	2.0 B	560 K	1.20 B	336 K	1.20 B	336 K
Burned					2.76B	822 K

In this scenario, the same amounts of LUNC and USTC are burnt as without the MM open.

Scenario b.) Users swap mainly (80%) from USTC to LUNC, assumed price for simplicity: 200 LUNC/USTC (in reality, this price would fluctuate).

Epoch	LUNC Tax	USTC Tax	Pool LUNC before	Pool USTC before	Pool LUNC after	Pool USTC after
1	1.3 B	360 K	720 M	216 K	144 M	3.1 M
2	1.6 B	450 K	840 M	270 K	168 M	3.63 M
3	2.0 B	560 K	1.20 B	336 K	240 M	5.14 M
Burned					552 M	11.87 M

In this scenario, 2.2 B LUNC less would be burnt than without the MM open. In turn, 11 M USTC more would be burnt.

Scenario c.) Users swap mainly (80%) from LUNC to USTC, assumed price for simplicity: 200 LUNC/USTC (in reality, this price would fluctuate).

Epoch	LUNC Tax	USTC Tax	Pool LUNC before	Pool USTC before	Pool LUNC after	Pool USTC after
1	1.3 B	360 K	720 M	216 K	754.5 M	43.2 K
2	1.6 B	450 K	840 M	270 K	882 M	54 K
3	2.0 B	560 K	1.20 B	336 K	1.254 B	67.2 K
Burned					2.89 B	164.4 K

In this scenario, 130 M LUNC more would be burnt than without the MM open. In turn, 660 K USTC less would be burnt.

8.2 Flash-crash & oracle outage

• USTC dumps to $0.004 (80 LUNC/USTC); two top validators offline.
• After 30 s quorum < 50 % → MM shuts.
• Tax proceeds collapse for both tokens in the next epoch.

LUNC in Crisis Scenario

• LUNC tax proceeds collapse to 0.2 B/month.
• USTC tax proceeds collapse to 56 K/month

Scenario a.) Users swap equally back and forth between LUNC and USTC

Epoch	LUNC Tax	USTC Tax	Pool LUNC before	Pool USTC before	Pool LUNC after	Pool USTC after
1	0.2 B	56 K	120 M	33.6 K	120 M	33.6 K
2	0.2 B*	56 K	120 M	33.6 K	120 M	33.6 K
3	0.2 B	56 K	120 M	33.6 K	120 M	33.6 K
Burned					360 M	100.8 K

In this scenario, the same amounts of LUNC and USTC are burnt as without the MM open.

(*) MM is halted mid of this epoch due to an oracle outage and not resumed. No further swaps happen from that point on

Scenario b.) Users swap mainly (80%) from USTC to LUNC, assumed price for simplicity: 80 LUNC/USTC (as defined in crash scenario).

Epoch	LUNC Tax	USTC Tax	Pool LUNC before	Pool USTC before	Pool LUNC after	Pool USTC after
1	0.2 B	56 K	120 M	33.6 K	24 M	1.2 M
2	0.2 B*	56 K	120 M	33.6 K	48 M	900 M
3	0.2 B	56 K	120 M	33.6 K	120 M	33.6 K
Burned					192 M	2.13 M

In this scenario, 150 M LUNC less would be burnt than without the MM open. In turn, 2 M USTC more would be burnt.

(*) MM is halted mid of this epoch due to an oracle outage and not resumed. No further swaps happen from that point on.

Scenario c.) Users swap mainly (80%) from USTC to LUNC, assumed price for simplicity: 80 LUNC/USTC (as defined in crash scenario).

We are leaving out this scenario as it would be unlikely that people swap from LUNC to USTC in an assumed price crash of USTC.

Even in disaster the float keeps shrinking for both tokens independently.

---

9 Spread-fee policy for MM swaps

Condition	Fee applied	Notes
MM disabled (no swaps)	—	No fee, no burn; route is inert.
MM enabled & allowance > 0	0.35 % of notional	Collected in the output asset (LUNC on USTC→LUNC swaps, USTC on LUNC→USTC).
Allowance exhausted (epoch cap hit)	—	Swap is refused; no fee, no burn.

Rationale

• Feasible level – 0.35 % is low enough to keep arbitrage profitable against typical CEX spreads (≈ 0.10 – 0.25 %) yet still recovers oracle and keeper costs.
• No double taxation – The chain-wide 0.50 % burn tax does not apply to these in-module swaps; the spread fee replaces it.
• Accounting – Fees are routed 50% to burn and 50% to the Oracle Pool
• Stable-to-stable path – Disabled entirely (§ 4.4), so the fee only ever applies to LUNC ↔ USTC trades.

---

10 Oracle module compatibility

Reactivating the MM with dynamic pricing requires updates to the current oracle infrastructure:

1. USTC price feed – USTC must be added to the oracle vote set. The MM currently assumes a fixed $1 price; this logic must be removed and replaced with real-time price input from validators.
2. Feeder provider expansion – The existing feeder supports limited sources. To ensure accurate and manipulation-resistant pricing, additional data providers (e.g., multiple CEXs, aggregators) must be integrated.
3. Validator onboarding – All validators must be guided through updating their oracle feeder binaries and configs to support USTC. Documentation and rollout coordination will be required to avoid quorum drops.
4. (Optional) Feeder overhaul – A full rewrite of the feeder binary is not strictly required, but strongly recommended. The current feeder is outdated and lacks support for modern APIs, fallback logic, and proper error handling.

These changes must be deployed before the MM reopens. Without them, price input will be invalid or absent, triggering the automatic shutdown mechanisms.

---

11 Roadmap

1. Code merge for testnet & review – ≈ 500-1000 Lines of Code (pool logic, adaptive knobs, kill-switch).
2. Public testnet – inject price spikes, quorum drops, 10× burn bursts.
3. Mainnet upgrade (two-step)

• Deploy module inactive
• Activate at next epoch boundary after pool filled during the epoch

4. 90-day post-mortem – change 60 % redirection or F only by hard fork (chain upgrade).

---

12 What we gain

• Immediate reopening – traders can arbitrage on day 1.
• Guaranteed deflation – supply must still fall every epoch of 30 days.
• Elastic throttle – as supply contracts, refill slows and pool shrinks.
• Oracle-safe – 30 s lag can’t inflate; 75 s lag kills the module.
• Oracle-Pool refill – spread fees from the market module are redirected to the Oracle Pool for future rewards (50%)
• Burns – 50% of the spread fee are burnt

---

13 Voluntary burns

At this point in time, a big part of burnt supply originates from voluntary burns (coins sent to the on-chain burn module – terra1…anxu).

These funds should be excluded from the calculation of the 30 day epoch burns to avoid losing burn support of entities like Binance and community members. This will tighten the possible available tokens. It should be considered to extend the pools if necessary, but this would need to be discussed with affected entities once the general concept has been implemented and tested.

---

14 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.

---

15 Risks

The risk of hyperinflation is mitigated by using only funds redirected to a distinct pool from the tax proceeds of the previous period. This leaves the MM minting disabled.

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

---

Appendix 1: 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 does not mint for swaps. We acknowledge that this deviates from the original concept of the MM. 60% of the burn tax proceeds (NOT manual burns by wallets) are redirected to the MM swap pool for the next period.

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 provided from the MM pool and the user gives USTC to the pool in turn. When swapping LUNC to USTC, USTC is given out from the pool and LUNC is provided back by the user. This is not exactly how the market module worked initially (mint and burn), but keeps the logic for calculations. The minting is replaced by utilizing a prefilled pool.

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) through their swaps (see mechanisms about the monthly pool burns).

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 pool is exhausted, but this would in turn have the benefit of increased burns of USTC.

---

Appendix 2: Questions and answers

Q: Can this cause further LUNC hyperinflation?
A: No. Minting is avoided in swaps, the available LUNC is limited to the amount in the pool, based on the tax proceeds 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 avoid minting with this approach completely. While we initially have lower burns when we redirect parts of the tax to the swap pool, all remaining balances of the pool are burnt at the period’s end.

Q: What is the “MM swap pool”?
A: It is the amount of LUNC and USTC that is allowed to be used in swaps during a period. The actual swapped amount can be higher, because the balance 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 had 667M LUNC tax proceeds. At a 60% rate, this would fill the MM swap pool with 400M LUNC for the next period. So if now 2,000,000 USTC are swapped to LUNC through the MM, this would give the user 400M LUNC from the pool 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 available for swapping.

Q: But wouldn’t that lower burns significantly overall, if that much is redirected to the pool?
A: No. All remaining balances in the pool would be burnt at the start of the next epoch. It depends on the swap behavior if more LUNC is burnt and less USTC or more USTC and less LUNC.

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 swaps 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 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 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.

Q: What if we want to use the MM in its original form later?
A: The changes will be designed to be as minimal as possible in terms of changing from mint/burn to the pool approach. Reverting this for a later use of the MM including the mint/burn mechanism is possible.

READ MORE HERE

Abstract

To address the ongoing issue of centralized voting power within the Terra Classic network, which currently has a Nakamoto index of 5, this proposal introduces a new rule to the staking module: a 2.5% voting power cap on validators. This cap prevents validators with more than 2.5% voting power from receiving new delegations or redelegations, encouraging a more equitable distribution of voting power, increasing the Nakamoto index to a target of 14, and fostering greater decentralization and validator equal profitability.

Background & Problem Statement

Terra Classic prides itself on being a fully decentralized blockchain, where governance decisions are made through community consensus. However, the current Nakamoto index of 5 indicates that just five validators could potentially veto proposals or exert significant control over the chain. While historical data suggests no malicious intent from the top validators, this low index undermines the chain’s decentralization ethos and introduces risks.

Additionally, the concentration of voting power among the top validators creates profitability challenges for smaller validators. Only the top 10 validators can consistently cover the operational costs of running a node, leading to reduced motivation for others to participate actively. This centralization fosters internal conflicts and discourages validators from championing Terra Classic’s growth.

Key issues include:

• Centralized Control: A Nakamoto index of 5 indicates that five validators can dominate governance, contradicting Terra Classic’s decentralization principles.
• Validator Profitability: Smaller validators struggle to remain profitable, reducing their incentive to maintain nodes or advocate for the network.
• Community Dynamics: Centralization fuels internal disputes, hindering collaborative efforts to build and promote Terra Classic.

Proposal & Example

This proposal introduces a simple yet effective rule to the staking module: Validators with more than 2.5% of the total voting power cannot receive new delegations or redelegations. This cap ensures that voting power is gradually redistributed to smaller validators, increasing the Nakamoto index and enhancing network fairness.

Example Scenario

• Validator A: Currently holds 3% voting power. Under the proposed rule, Validator A cannot receive new delegations or redelegations until their voting power falls below 2.5%.
• Validator B: Holds 2% voting power. This validator can continue to receive delegations, attracting new stakers and increasing their voting power up to the 2.5% cap.
• Outcome: Over time, validators with lower voting power gain more stake, reducing the dominance of top validators and increasing the Nakamoto index.

The goal is to raise the Nakamoto index from 5 to 14 within a reasonable timeframe, making Terra Classic more decentralized and resilient.

Mechanics of the Mechanism

The proposed rule will be implemented as follows:

• Voting Power Cap: Any validator exceeding 2.5% of the total voting power will be ineligible to receive new delegations or redelegations.
• Monitoring and Enforcement: The staking module will check each validator’s voting power at the end of each epoch. If a validator exceeds 2.5% ( prev. cap 20%), new delegations and redelegations will be blocked.
• Grace Period: Upon implementation, validators above 2.5% will retain their current stake but cannot receive additional delegations or redelegations until their voting power falls below the threshold .
• Governance Adjustments: The 2.5% cap can be adjusted via governance proposals to reflect network conditions, validator feedback, or decentralization goals.

This mechanism requires minimal changes to the staking module .

Advantages

• Enhanced Decentralization: By limiting the voting power of dominant validators, the proposal encourages a broader distribution of stake, increasing the Nakamoto index.
• Improved equal Validator Profitability: Smaller validators gain access to more delegations, improving their financial sustainability and motivation to participate.
• Network Security: A higher Nakamoto index reduces the risk of coordinated attacks or governance manipulation.
• Community Unity: Fairer stake distribution mitigates internal conflicts, fostering collaboration among validators and community members.
• Simplicity: The 2.5% cap is straightforward to implement and understand, minimizing technical complexity.

Future Adjustments

The 2.5% voting power cap can be fine-tuned through governance based on:

• The current Nakamoto index and decentralization metrics.
• Feedback from validators and delegators.
• Network growth and staking participation rates.

Regular evaluations will ensure the cap remains effective and aligned with Terra Classic’s goals.

Conclusion

The proposed 2.5% voting power cap addresses Terra Classic’s centralization challenges by redistributing voting power, increasing the Nakamoto index, and improving validator eqaul profitability. This mechanism aligns with the community’s decentralization ethos, enhances network security, and fosters a more collaborative ecosystem. By implementing this rule, Terra Classic can solidify its position as a truly decentralized blockchain.

Cast Your Vote Now

• Yes: Support the 2.5% voting power cap proposal.
• No: Oppose the proposal.

Note on Implementation

Implementing the voting power cap requires modifications to the staking module at the L1 level. While this entails development effort, the changes are relatively straightforward and can leverage existing governance and staking frameworks.

Author: Vegas

READ MORE HERE