Safely reactivating the market module entails making the following adjustments: (repeg USTC)
• Implement Oracle Price Feed for USTC:
· Integrate an oracle module that provides real-time price feeds for USTC, similar to the existing oracle system for LUNC ( this one need upgrading as well). This ensures accurate and current pricing for all transactions involving USTC.
•(To be considered) Burn 20% of the Fee, allocate 20% for Oracle Pool, and designate the remaining 60% to a pool for buyback programs to reinforce the peg.This could be a parameter change option.
• (Important) Enforce limits on the size of virtual liquidity pools, introducing multiple pools with conditional activation steps(example later on in this document.).
•(To be considered) Furthermore, impose a hard cap on the max supply of LUNC and USTC (with enhancements proposed by Igor Veras).
•Add a kill switch.
Motivation:
Reviving the market module offers both prospects and risks:
Rewards:
• Potential restoration of USTC stability to $1, revitalizing the chain’s utility.
- Revenue generation through fees from LUNC<>USTC swaps (helps mitigate OP depletion), distributed as Oracle rewards to validators, delegators, and for buyback programs.
- Potentially burning a significant amount of LUNC
- And will attract considerable interest from both small and large investors.
Risks:
• Unwanted LUNC minting (addressed through the adoption of a multi-conditional pool system and reduction of hard caps for both coins).
1) Creating a system that will utilize real-time price feeds for USTC instead of relying on SDR pools will not be an easy task, but once completed, it will enhance the functionality of the oracle price feed. https://github.com/vegasmorph/oracle_feeder_USTC_market/blob/main/feeder/src/vote.ts by Igor Veras. https://github.com/igorv43/core/blob/fix_ustc/x/market/keeper/swap.go https://github.com/igorv43/core/tree/fix_ustc/x With real-time price feeds for USTC, swaps will be more accurate, and by limiting the size of the virtual liquidity pool, the risk of things going wrong is very small.
2) Limiting the virtual liquidity pool size and implementing multi-conditional pools:
To mitigate the risk even further , we can cap the size of the virtual liquidity pool. Presently, the base pool size is set at 100M SDR with an 18-block recovery period (~1 minute). To lessen liquidity risk, I suggest reducing the base pool size to around 1000 USTC and extending the recovery period to 14,400 blocks (~24 hours).
However, to entice larger investors, the proposed base pool size is not suffice. Thus, I recommend implementing a multi-conditional pool system. This system entails setting conditions for the opening of subsequent pools. For example, when the first pool reaches capacity (1000 ustc), instead of closing the market module for 24 hours, a new, larger pool (2000 ustc) will open if the USTC price doesn’t deviate more than 5% and the hard cap is not reached .
This procedure can be iterated several times, gradually increasing pool sizes (e.g., 1000, 2000, 4000, and so forth) until reaching a specified limit. Resetting pool sizes on a daily basis would fortify the system against potential threats.
Please note that the suggested values for base pool size, number of pools, and recovery period are open to adjustment. A testnet for multi-conditional pools will be established to refine and calibrate these values before a final proposal is made.
To further mitigate risks, I suggest imposing hard caps on the maximum supply of LUNC and USTC. These caps can be adjusted through incremental burns and re-pegging in the future.
Dynamic Conditional Peg Mechanism
The peg (P) of USTC will remain at its current price (X), and can only rise if the fees collected in the collateral pool (Cp) are sufficient to defend the peg at a new stage (S)=X+Z , where (Z) is an incremental increase of $0.001. If the collateral pool CP contains enough funds to cover the daily transaction volume (VD) plus a safety margin (M) (e.g., 30%) of S, the peg can be adjusted upward. The surplus in Cp can also be used in OTC transactions to stabilize the peg as it moves higher.
Example:
If the current peg is P=X=$0.015P, and the collateral pool can cover Vd+M of S , the peg can be moved to P=S=$0.016P . This process would repeat as long as the collateral pool can support the new peg with sufficient funds and margins.
Implementation:
labors required include, but not limited to:
• Establishing the testnet to evaluate optimal values for base pool size, number of pools, and recovery rate, upgrade testnet for the effect (enabling swaps , smart contracts, liquidity pools, wallets, etc).
- Developing a mechanism to burn a portion of the fee and a the creation of a module for buyback programs.
- Oracle module that provides real-time price feeds for USTC
• Creating a system for multi-conditional virtual pools within the market module.
• Proposing a signaling initiative proposal to assess community support.
A YES vote signals community backing for these endeavors, while a NO vote indicates otherwise. Queries, ideas, and feedback are welcomed.
https://commonwealth.im/terra-classic/discussion/12924-reopening-of-the-market-swap
https://commonwealth.im/terra-luna-classic-lunc/discussion/17405-staking-mechanism-for-ustc
Some notes :
To further promote the attempt to peg USTC, it is recommended to introduce a staking system for USTC on the Terra Classic chain,This will incentivize validators to operate the USTC price feeder. This would require the development of a new module. The main concept behind this initiative is to remove more coins from circulation.
However, to implement this, USTC would need to be provided as rewards for staking. In this case, we could use a dead contract supply. E.g. https://xplagames.medium.com/details-on-terminating-c2x-ust-lp-staking-program-d72492485b98
https://finder.terra.money/classic/address/terra1q00r9whldewsktqne5sux6gtaxn2vlfvu5geej
I suggest transferring these funds to the community pool ( freeze them first )to remove them from the circulating supply. Later, the community can decide how to utilize these funds, whether for the creation of an Oracle Pool for USTC, burning them, or any other purpose deemed appropriate by the community.
These are all controversial ideas, but we are not a normal blockchain; we have a history, a history that we have to solve.
This idea haves different topics, and it makes sense to separate in more than one governance proposal. Any feedback will be welcome.
This could be our best effort to bring glory to the entire ecosystem of Terra Classic.
P.S. The burn tax should be excluded from the swap mechanism itself, as it doesn’t align with the purpose of this system. However, it should still be maintained as a safeguard against potential abuse, specifically to prevent the manipulation of funds being transferred from off-chain to on-chain for the simple goal of crashing the price.
Dead contracts and wallets should be identified and frozen
Further considerations should focus on off-chain strategies, particularly with market makers, where buyback agreements can be executed at specific prices XXX through OTC transactions. These acquired tokens can then be burned, effectively reducing sell pressure in the market.
Thanks, Vegas.
