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:
- Converting the USTC amount to its SDR value using current oracle prices
- Determining how much LUNC to mint such that the virtual constant-product curve stays balanced
- 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:
- 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.
- 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.
- 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.
- (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
- Code merge for testnet & review – ≈ 500-1000 Lines of Code (pool logic, adaptive knobs, kill-switch).
- Public testnet – inject price spikes, quorum drops, 10× burn bursts.
- Mainnet upgrade (two-step)
- Deploy module inactive
- Activate at next epoch boundary after pool filled during the epoch
- 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.
