# USTC Re-Peg: Ziggy (Final) **URL:** \ **Category:** Governance & Proposals\ **Created:** [January 28, 2023, 10:30pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849 "2023-01-28T22:30:16Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![wrapped\_dday](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/wrapped_dday/32/19431_2.png) [@wrapped\_dday](https://classic-agora.terra.money/u/wrapped_dday)\ **Post date:** [January 28, 2023, 10:30pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/1 "2023-01-28T22:30:16Z")
**Proposer** : Duncan Day (@wrapped_dday) **Author** : Duncan Day **0. Disclaimers and Declared Biases** Duncan manages the [Onyx validator](https://station.terra.money/validator/terravaloper1e78ml33v4vfqkpthpkuhdgt4xl6um38vmphk0w) with [PFC](https://station.terra.money/validator/terravaloper12g4nkvsjjnl0t7fvq3hdcw7y8dc9fq69nyeu9q) as a white-label service provider. Duncan does not have any formal affiliation with Terraform Labs, or other major organizations like TerraCVita. Onyx has investments in the LUNC, LUNA, OSMO, ETH, STRD, and various other ecosystems on behalf of its delegates. Duncan does not have any personal investments, but is paid on a performance-basis for investment management through a private fund called _Lotus_. **0a. Previous Discussions** Please read the previous discussions to gather full context on this proposal. #1. [Modify Luna Exchange Rate with Novel Fee Variable](https://classic-agora.terra.money/t/modify-luna-exchange-rate-with-novel-fee-variable-discussion-ustc-re-peg/48881/21): apply a fee to `usdr` or other whitelisted `denom` exchange rates to provide an incentive for arbitrage. #2. [Ziggurat](https://classic-agora.terra.money/t/ustc-re-peg-proposal-ziggurat-discussion-2/49394): apply the incentive for arbitrage on a “penny-by-penny” / “soft-peg” basis, in order to reach the penultimate goal of re-pegging `USTC`. #3. [Exchange Rate Modifier (ERM)](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-erm-discussion-3/49607): apply the arbitrage incentive using a class called `ERM`, or “exchange rate modifier,” and apply the Greeks – quantities that measure price sensitivity of a derivative to a change in an underlying parameter – to guard this method from spiraling out of control. #4. [Pendulum](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-pendulum/49747): apply the arbitrage incentive as a premium or discount, “swinging” the incentives up or down in price to determine guard rails parameters. **1. Summary** This proposal describes an actionable framework for the LUNC Community to re-peg `USTC` from a code level, a consensus level (both technical and social), and guidelines to do so. While this proposal is a signaling proposal, actionable plans outlined here are enforceable through the [Terra Community Trust](https://classic-docs.terra.money/docs/learn/community-trust.html) guidelines. The end goal is to recover the value lost in the May 2022 “de-peg” of `SDT` from the `IMF SDR`, which `USTC` was most affected by, while streamlining `LUNC` burn processes. **Results of Voting** This proposal is a signaling proposal, meaning that there are no immediate, technical consequences for voting either way – a Yes or No will not change anything in the code. Failure to meet quorum or a No with Veto will still burn the deposit. _ **Yes** _ = The community will enact the Ziggy proposal to the extent that they are capable of, including, but not limited to: financing teams, contributing work (paid or unpaid), altering the proposal for communal benefit, or other relevant tasks. _ **No** _ = The community will not enact or produce work for the Ziggy proposal. _ **No with Veto** _ = The community will not enact or produce work for the Ziggy proposal, and the depositors’ LUNC will be burned. **2. Motivation** If Terra stablecoins like `USTC` are not stable, the ability for the `LUNC` blockchain (Terra Classic) to generate meaningful revenue is extremely limited. Profitability is limited to complex AMM strategies and, primarily, arbitrage. Arbitrage is the simultaneous purchase and sale of equivalent assets or of the same asset in multiple markets in order to exploit a temporary discrepancy in prices. This proposal aims to expedite the process slightly using data-driven parameters across any market servicing Terra assets. Terra stablecoins can be thought of like an _option_ instead of a stablecoin when it is off-peg. We retain _optionality_ even when stablecoins are stable, meaning we have a _choice_ of where to allocate that money. When it is de-pegged, we are presented with less choices, as many consumer businesses, for example, will not accept a payment that changes value dynamically. Without stability, we cannot truly benefit from volatility. **2a. _Defining the ERM_** Therefore, the _class_ `ExchangeRateModifier`, or `ERM`, is proposed as a technical, open-source solution for Terra’s community to build on. A _class_ is a blueprint for creating _objects_ (or particular data structures), which provide initial values for _state_ (variables or attributes that are “members” of that blueprint) and implementations of the behavior (functions or methods that are also considered members). More on Classes: [Classes (OOP) | Brilliant Math & Science Wiki](https://brilliant.org/wiki/classes-oop/) The `ERM` class is outlined in the pseudo-code below: ```auto class ERM {} // base class struct Conditionals {} // when should the ERM turn off? var = guard; // guards for the ERM with different "types" of Rails enum Rail { _RAIL, deltaTime, delta, vega, theta, gamma, rho, volga, vanna, charm, lambda, epsilon, vomma, vera, zomma, ultima } // list of Guard Rails available; Rails can be added or removed bool = ModifierActive; // is the ERM "on"? float = taxRate; // what is the tax rate? uint = SoftPeg(high, low); // what is the soft-peg calculated (high and low)? uint = ModifierRange(uint high, uint low); // what is the range applied to the soft-peg (up/down)? uint = ImmediateModifier; // how much should we immediately modify the soft-peg? uint = ModifierBlockDuration(int blocks); // how many blocks is the ERM "on" for? ``` In this class, we define the `ERM` with certain properties. Our `var` `guard` defines a “guard rail” that can define the algorithm’s parameters. **2b. _Using the ERM – The Greeks_** The `ERM` can be upgraded or modified. It is an open-source, high-level model designed to bolster the robustness of the Terra stablecoin mechanism. The `ERM` functions similar to a game’s `Update()` method, where every “tick” (frame) refreshes the game state. Normally, this is `Time.deltaTime`, which we measure through timestamping. Our alternative to measuring timeframes is to use `theta`, or time-to-expiry. We define a certain number of blocks under `ModifierBlockDuration(int blocks)` which can allow us to expire this incentive modifier after a certain block period. Note that this makes a notable difference for block-based MEV when contrasting it with `deltaTime`; the expiry can occur during a block with `deltaTime`. The other Greeks listed are suggestions for Guard Rails (broad definitions): `delta` : amount that one asset changes in price `vega` : price volatility `gamma` : how much a one-asset derivative changes in price (eg an AMM pair LP or LSD) `rho` : how much interest rates (eg staking yield) affect price The other Greeks are defined as second- or third-order derivatives. In actuality, any novel Guard Rail can be designed; a user may propose a Guard Rail with a unique name/ID such as `Attacker` and then define how that Guard Rail is used in the protocol. **2c. _Using the ERM – Creating a Soft Peg_** The `ERM` determines a `SoftPeg` by pulling the last-aggregated exchange rate given in the Vote Procedure. This means that the exchange rates are not altered between the Prevote and the Vote, only after it is completed and before Ballot Rewards are distributed. In essence, this pushes the margin-of-error for exchange rates slightly higher across validators. However, this is still gated by `RewardBand` which will punish validators and their delegates who submit outside of the range with no rewards. For example, if the last-reported aggregate exchange rate for `usdr` is `1000usdr`, then the `ERM` determines this as a “soft-peg.” The `ERM` then determines the `ModifierRange(uint high, uint low)` by filtering the `SoftPeg` rate through an operator function – for example, `SoftPeg + 500usdr` and `SoftPeg - 500usdr`. This defines `SoftPeg(uint high, uint low)`. Then, there is an immediate modifier applied to the soft peg that is within the `ModifierRange`. A simple heuristic to use is `(ModifierRange(high) - ModifierRange(low)) / ModifierBlockDuration`. If the `ModifierBlockDuration` is 50 blocks (roughly 10 Oracle cycles), and the `ModifierRange(total)` is `1000usdr` (500 + 500), the resultant is `1000usdr / 10`, or `100usdr` immediately applied to the exchange rates. This creates some interesting – and dangerous – scenarios where the `ERM` can re-apply Modifiers. This is why the Guard Rails are put on. A `struct` of `ERM` `Conditionals` define how and when this Terra algorithm component stops. For example: ```auto if exchange rate >= SoftPeg(high, low) while ModifierActive == true, THEN ModifierActive == false; ``` In essence, this says if the exchange rate reaches the `SoftPeg` limits while the `ERM` is on, turn it off – we don’t want to keep reapplying incentives. This allows the market to “catch up” to an exchange rate, and we can determine the “cooldown” of such a mechanism in another way algorithmically. **3. Proposal** The proposal outlines an action plan that the community can act on and modify according to preference. **3a. _Obtain Developer Consensus_** There is a small group of individuals who act as “validators for code,” a.k.a. the developers. The only alternative to Developer Consensus is to create a new repository and obtain Validator Consensus to accept that repository. Failure to reach Developer Consensus renders the proposal null and void. _Due Date_ - ideally, before March. (1 month) **3b. _Obtain Cross-Market Consensus_** The core hurdle is ensuring that participating markets are on-board with this idea. This includes _any_ market that services Terra assets on the native level. Tokens that are included: - Wrapped versions, synthetics, and liquid-staking derivatives tracking `LUNC`, including but not limited to: `wLUNA`, `xLUNA`, `stLUNAC`, `ampLUNC`, `wUST`, `weUST`, `whLUNA`, `KRTC`, `wKRT`, etc. - DEX markets that service the above assets and have a governance token, including but not limited to: `UNI`, `AAVE`, `FRAX`, `CRV`, `CVX`, `LDO`, `ASTROC`, `OSMO`, etc. - CEX markets that service the above assets and do not yet run a validator node. CEX markets **must** run a validator node as part of this proposal in order to corroborate their price submissions as an oracle service. They **may not** use external oracle service providers as exchange rates are serviced directly through the oracle. By not obtaining Cross-Market Consensus, all actions taken by the `LUNC` blockchain validators and delegates through parameter change voting (such as `TaxPolicy` or `RewardPolicy`) can affect external markets positively or negatively. The Community, as outlined in the [Terra Community Trust](https://classic-docs.terra.money/docs/learn/community-trust.html), have a fiduciary responsibility to assets in the Community Pool. The Community also has an implicit fiduciary responsibility to the markets they have affected to-date, i.e., all markets that have been affected by a first-, second-, or tertiary-degree exposure to Terra assets. For example, proposals that negatively affect investments in wrapped tokens like `wLUNA`, as they are directly linked in price to `LUNC`, means that they can be held liable under relevant local jurisdictions.\* It is suggested that The Community uses a solution like [Snapshot](https://snapshot.org/#/) to obtain sentiment before asking other markets to enact governance processes, as it costs money to do so. Failure to obtain sufficient Cross-Market Consensus, as determined through majority vote in each market, renders this proposal null and void. _Due Date_ - May 27th, 2024 as an absolute deadline. \*_(To provide further examples: negatively affecting `wLUNA` affects Coinbase investors as well as UniSwap DEX users; the reverse is also true. Committing actions via the Community Pool exposes the committer to laws relevant to how member countries of `LUNC` approach relevant actions separately. There are 22 member countries participating in `TerraSDR`.)_ **3c. _Test and Implement the ERM_** The `ERM` requires a mainnet go-live approach, but it can be partially simulated on testnets. The Community may incentivize testnet simulations for quantative analysts (“quants”) to determine the best course of action. It is suggested that The Community utilize community pool funds to incentivize these facets of development. Ultimately, the `ERM` cannot go live unless Cross-Market Consensus is obtained. If other markets do not want to participate, it is suggested that other markets, including `LUNC`, offer to purchase their distressed assets at face-value to continue participating. They can, again, offer to purchase these using funds in the community pool. When satisfactory data has been collected, the `ERM` should go live on mainnet. This will, in real-time, affect all markets that have `USTC`, `LUNC`, other Terra stables like `KRTC`, wrapped equivalents like `wLUNA`, and synthetics tracking `LUNC` price like `xLUNA`; therefore, The Community should be prepared to shoulder ramifications of such a proposal. Failure to Test and Implement the ERM renders this proposal null and void. _Due Date_: May 27th, 2024 as an absolute deadline. **4. Pros and Cons** In simple terms, the Pros boil down to designing a more efficient system for `LUNC` and `USTC` that can burn more than the tax rate can, create a smoother environment for dApps and its users, and ultimately reach the penultimate goal of re-pegging `USTC`. The Cons for this proposal is that it is costly to make now and over time, and so, if The Community is not interested in expenditures that developers or contributors request for Ziggy, or if they do not have the means (capital or resources) to enact parts of the proposal, then the proposal has failed by way of default. **4a. _Pros_** Re-enabling the algorithmic token methodology _without_ new minting of coins Opening the potential of burning using the `ERM` instead of taxes (“built-in taxation”), increasing the rate of burns (demurrage) significantly Enabling burns (demurrage) of `LUNC` and `USTC` across _all_ markets that participate in Cross-Market Consensus of this proposal Strengthening and streamlining governance across protocols and networks under a common goal Obtaining thorough on-chain data regarding to AFT behaviors in the context of the derivatives market (both simple and complex) **4b. _Cons_** Inability to enact parts of the proposal without additional capital or consensus Initial costly overhead to develop a solution on top of `USTC`, which may or may not work Cost to maintain and refine data and usage of data initially high; requires improvement from community contributors **5. Conclusion and Notes** By reneging Terra Stablecoins like `USTC`, the community reneges one of its most potentially methods of making money: algorithmic foreign exchange trading and remittance. The reason that these opportunities exist for `LUNC` in the first place is due to the algorithmic currency creation. It is a challenging problem from a design perspective, and opting for any amount of collateral on-chain above 0 reduces the potentiality; it is simply more prudent to use a different chain for that purpose. Therefore, it is the Proposer’s opinion that `LUNC` continues to pursue a robust design of the algorithmic system, which Ziggy harkens back to. Obtaining Developer Consensus either requires asking the developers to implement this on the base layer (L1). It can be done on a separate layer (L2) but is not ideal, or even possible, for reasons associated with latency. The other solution is to create another repository that attempts to tackle this problem and asking validators to run that version. Obtaining Cross-Market Consensus requires that `LUNC` obtains consensus from other markets. Every action that the Community takes that affects `LUNC` price affects investors on all chains, some more than others. Using an algorithmic solution as proposed introduces vectors that may not be forecasted in this document. Additionally, `LUNC` must obtain consensus with CEXs like Binance through running a validator on-chain so that they can prove they are not manipulating internal prices against Terra’s. **If this particular step is not taken with CEXs, `LUNC` risks destroying what has been built through the risks associated with direct oracle manipulation.** Finally, like any software, this must be tested and then sent into the field. This cannot stay on testnets forever. The `LUNC` community has the option to incentivize users to go on testnets and interact with production solutions before it goes live. Deadlines have been given as May 27th, 2024, because the rewards in the oracle pool from the May '22 crash will expire by then. (Roughly ~May 9th, 2024) **This proposal will have a deposit created on January 31st, 2023 from the address `terra1ld979rgsh2p5tfxx5rl5cp5r9kd4ke570xc9uf`**. Please use this deposit address as a way to track the proposal from this author. This additionally will be broadcasted on Twitter through [https://twitter.com/wrapped\_dday](https://twitter.com/wrapped_dday). ---
**Author:** ![Ajuranio](https://avatars.discourse-cdn.com/v4/letter/a/a8b319/32.png) [@Ajuranio](https://classic-agora.terra.money/u/Ajuranio)\ **Post date:** [January 28, 2023, 11:05pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/2 "2023-01-28T23:05:12Z")
Can someone explain this in simple terms. ---
**Author:** ![Kevin\_Park](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/kevin_park/32/4837_2.png) [@Kevin\_Park](https://classic-agora.terra.money/u/Kevin_Park)\ **Post date:** [January 28, 2023, 11:52pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/3 "2023-01-28T23:52:45Z")
It’s a proposal asking for money. ---
**Author:** ![Dannavan\_Morrison](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/dannavan_morrison/32/19488_2.png) [@Dannavan\_Morrison](https://classic-agora.terra.money/u/Dannavan_Morrison)\ **Post date:** [January 29, 2023, 1:04am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/4 "2023-01-29T01:04:56Z")
> [@wrapped\_dday](#): > > apply the incentive for arbitrage on a “penny-by-penny” What will happen if there are competition from other traders? Wouldn’t it cause the prices of the assets involved in the arbitrage to converge, making the opportunity less profitable or even eliminating it altogether? "For example, imagine an opportunity to buy a coin for $10 on one exchange and simultaneously sell it for $15 on another exchange. As more traders become aware of this opportunity and start buying the coin on the first exchange and selling it on the second, the demand for the coin in the first exchange will increase and its price will rise. At the same time, the supply of the coin on the second exchange will increase, causing its price to fall. As a result, the price difference between the two exchanges will decrease, making the opportunity less profitable. Additionally, high-frequency traders and algorithmic traders can quickly identify and capitalize on arbitrage opportunities, making it harder for individual traders to execute their strategies. Hence, competition among traders can cause the arbitrage opportunities to be short-lived or with less profits or even losses, as the market adjusts faster." -An extract. Will this have any impact on your proposal. For me I dont want the proposal to be the case of the emperor’s new clothes. I may be naive but I want to know. ---
**Author:** ![JCP.ESQ](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/jcp.esq/32/2136_2.png) [@JCP.ESQ](https://classic-agora.terra.money/u/JCP.ESQ)\ **Post date:** [January 29, 2023, 1:10am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/5 "2023-01-29T01:10:21Z")
“Let’s engage in price-fixing and cross our fingers we don’t get blacklisted.” ---
**Author:** ![SwordDemon](https://avatars.discourse-cdn.com/v4/letter/s/47e85d/32.png) [@SwordDemon](https://classic-agora.terra.money/u/SwordDemon)\ **Post date:** [January 29, 2023, 1:16am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/6 "2023-01-29T01:16:01Z")
L1 team already set the hard cap to 2T.Apparently they make it easier and safer to try any ideas. So what do we afraid of?Nothing! We can’t be worse than now. Go and just do it! ---
**Author:** ![Solstice\_1](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/solstice_1/32/20464_2.png) [@Solstice\_1](https://classic-agora.terra.money/u/Solstice_1)\ **Post date:** [January 29, 2023, 1:47am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/7 "2023-01-29T01:47:40Z")
0101010101010101$01$01$01$0$$$$01​:sunglasses:🕶😆 ---
**Author:** ![JCP.ESQ](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/jcp.esq/32/2136_2.png) [@JCP.ESQ](https://classic-agora.terra.money/u/JCP.ESQ)\ **Post date:** [January 29, 2023, 2:23am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/8 "2023-01-29T02:23:01Z")
Translation: YOLO 🚀 💸 🤑 🚀 ---
**Author:** ![Funkseoulbrotha](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/funkseoulbrotha/32/20100_2.png) [@Funkseoulbrotha](https://classic-agora.terra.money/u/Funkseoulbrotha)\ **Post date:** [January 29, 2023, 3:17am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/9 "2023-01-29T03:17:35Z")
Gotta push hard on the exchanges if this passes… Binance, [Binance.US](http://Binance.US), coinbase, mxc, kraken, all the big boys need to agree to this. Heavy push and influence on Binance to agree…but what do I know. I’m obese and old. ---
**Author:** ![vBlake](https://avatars.discourse-cdn.com/v4/letter/v/a88e57/32.png) [@vBlake](https://classic-agora.terra.money/u/vBlake)\ **Post date:** [January 29, 2023, 4:41am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/10 "2023-01-29T04:41:46Z")
if binance is willing to burn millions of dollars by burning for us I’m sure they would implement the code for us. ---
**Author:** ![Kitthichai\_Punchawat](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/kitthichai_punchawat/32/18885_2.png) [@Kitthichai\_Punchawat](https://classic-agora.terra.money/u/Kitthichai_Punchawat)\ **Post date:** [January 29, 2023, 8:41am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/11 "2023-01-29T08:41:35Z")
To bring the USTC to a value of 1 dollar using a soft peg algorithm, you first need to establish a target exchange rate for the soft peg, which in this case is 1 dollar. Then, you would need to determine a range for the soft peg, which can be done by adding or subtracting a certain percentage or fixed value from the target exchange rate. This range can be used to set boundaries for the USTC to fluctuate within. Next, you need to implement a mechanism for adjusting the USTC to move toward the target exchange rate within the established range. This can be done using various methods, such as changing the supply of the stablecoin, adjusting interest rates, or implementing incentives for market participants to buy or sell the stablecoin. Finally, you would need to put safeguards or “guardrails” to prevent the ERM from deviating too far from the target exchange rate and to prevent any potential adverse effects on the market. It’s worth mentioning that this is a simplified version of the steps. In reality, it’s a complex process requiring much testing, monitoring, and fine-tuning to get the best results. ---
**Author:** ![Kitthichai\_Punchawat](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/kitthichai_punchawat/32/18885_2.png) [@Kitthichai\_Punchawat](https://classic-agora.terra.money/u/Kitthichai_Punchawat)\ **Post date:** [January 29, 2023, 9:12am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/12 "2023-01-29T09:12:28Z")
For USTC from $0.02237 to $1 using a soft peg algorithm, the following steps can be taken: 1. First, could you determine the current exchange rate for the stablecoin? In this case, the exchange rate is $0.02237. 2. Next, could you set the target exchange rate for the stablecoin? In this case, the target is $1. 3. Could you determine the difference between the current and target exchange rate? In this case, the difference is $1 - $0.02237 = $0.97763. 4. Could you set up the parameters for the soft peg algorithm? For example, the algorithm can adjust the exchange rate by 0.1% per block, with a maximum adjustment of 5% per day. 5. I’d like you to begin implementing the soft peg algorithm. The algorithm will continuously adjust the exchange rate towards the target at a rate of 0.1% per block until the target exchange rate of $1 is reached. 6. Could you monitor the exchange rate and adjust the algorithm as necessary? For example, the target exchange rate may change over time, and the algorithm may need to be adjusted to reflect these changes. 7. Could you repeat the above steps until the exchange rate reaches $1? ---
**Author:** ![wrapped\_dday](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/wrapped_dday/32/19431_2.png) [@wrapped\_dday](https://classic-agora.terra.money/u/wrapped_dday)\ **Post date:** [January 29, 2023, 12:02pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/13 "2023-01-29T12:02:55Z")
> Can someone explain this in simple terms. 1: Exchange rate for `USTC` = `$0.02`. This is our “soft peg.” 2: How high or low can we go before turning off our boosters? This is our “modifier range.” 3: How long are we keeping our boosters on? This is our “modifier duration”. 4: How much of a boost should we give? This is our “immediate modifier (range/duration)”. 5: Any other guard rails we should put on? 6: Run the booster until our guard rails kick in. It’s like bowling, a bit. We want to throw the ball a little faster for a strike. Throw it out of control and it lands in the gutter – no pins landed. It’s the difference between these two photos: ![image](https://global.discourse-cdn.com/terra/original/3X/7/e/7ef5e0bc113c784ef07dd8075cb70a3bb458bb3f.jpeg) ![image](https://global.discourse-cdn.com/terra/original/3X/2/b/2b2d044770655e8942d703dd61fab599a34c1a73.jpeg) @Kevin_Park > It’s a proposal asking for money. It’s asking for code and for the community to work for a re-peg. If they don’t want to work, they can vote No. If they don’t want this code implemented, they can vote No. If they don’t want to bother with gathering cross-market consensus, they can vote No. Please read the proposal before making fundamentally inaccurate statements. @Dannavan_Morrison > What will happen if there are competition from other traders? > Wouldn’t it cause the prices of the assets involved in the arbitrage to converge, making the opportunity less profitable or even eliminating it altogether? Yes. That is the natural consequence of this proposal. Arbitrage happens as a result of inefficient market pricing. The pricing of this market is inefficient, but severely limited. We’ve put ourselves in a position where we have a load and are trying to lift it through force, but there is no fulcrum for this to work. This proposal is a modified design of the fulcrum of the original algorithm for fixed-supply instances of `LUNC`. ![image](https://global.discourse-cdn.com/terra/original/3X/4/6/46fb37cf54e324f0bde73b259aa7d7f0d3948858.png) > Additionally, high-frequency traders and algorithmic traders can quickly identify and capitalize on arbitrage opportunities, making it harder for individual traders to execute their strategies. > > Hence, competition among traders can cause the arbitrage opportunities to be short-lived or with less profits or even losses, as the market adjusts faster." -An extract. Will this have any impact on your proposal. For me I dont want the proposal to be the case of the emperor’s new clothes. I may be naive but I want to know. Currently, `LUNC` holders are being extracted through arbitrage carrying costs. The only reason their investment is protected is through the tax and staking yield; i.e., their principal is retained, but the ones who are making money are squeeze multi-hundred percentile profits through high-frequency trading (HFT). Unfortunately for `LUNC` investors, these are really the only people who generate value for the network, except they all trade on Binance for lower spreads and fees and no taxes. It does not make financial sense to run a bot on-chain vs. on Binance. Manual traders like myself have been relegated to DEX options farming which is difficult, slower, less profitable than staking, and expensive. If you want traders to trade without access to quant bots, you need them to have a platform to do so. They do not have a platform to do so. This proposal does not address this, but it asks for all of the money that’s on Binance or other CEXs to come back on-chain. We can reduce the tax to something low – maybe a few basis points – and then stakers will earn on transaction fees in high volume, which has been a complaint since #5234. Also, this is why we test it in controlled zones as outlined in the pseudo-code algorithm. @JCP.ESQ > “Let’s engage in price-fixing and cross our fingers we don’t get blacklisted.” Every one of you are neck-deep in this already with having created the tax, which fundamentally affects the price of all wrapped and synthetic assets on all chains. You should be thankful we haven’t been blacklisted for this reason already, let alone charged on grounds for a myriad of reasons that are out of scope of this document. Also, this is algorithmic price alterations. This differs from things like monetary policy which deliberately alter prices in favor of the governing body. For example, a 1.2% tax rate on all transactions is predictable for those capturing the value on this proposal, but unpredictable for those paying value into it. We can draw similar analogies to rates determined by governing financial bodies. If the FOMC decides that the funding rate is going to increase by 50 basis points, they essentially can frontrun their populace unless their decision-making processes are publicized. If neither the FOMC nor the populace can determine the increase or decrease of the funding rates except by math, then the gate is not whether or not the Fed likes you, but rather your proclivity for learning math. ---
**Author:** ![mdp2909](https://avatars.discourse-cdn.com/v4/letter/m/df788c/32.png) [@mdp2909](https://classic-agora.terra.money/u/mdp2909)\ **Post date:** [January 29, 2023, 1:09pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/14 "2023-01-29T13:09:39Z")
Dear Duncan, The proposal looks good. I suggest you create a simulation with a spreadsheet to show how it works day by day. Otherwise, it is difficult to assess it with numbers. ---
**Author:** ![Kitthichai\_Punchawat](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/kitthichai_punchawat/32/18885_2.png) [@Kitthichai\_Punchawat](https://classic-agora.terra.money/u/Kitthichai_Punchawat)\ **Post date:** [January 29, 2023, 6:49pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/15 "2023-01-29T18:49:02Z")
If there is competition from other traders, it could impact the price of the USTC and make it more challenging to maintain its peg to the USD. One possible solution to mitigate this impact would be to have a mechanism that adjusts the USTC’s exchange rate in response to market conditions. This could be done by implementing a dynamic adjustment algorithm that considers the current market conditions, such as the trading volume and price of competing stablecoins, and adjusts the ERM’s exchange rate accordingly. Additionally, implementing a multi-oracle system, where multiple independent oracles provide exchange rate data, can help reduce the risk of manipulation and ensure that the USTCs exchange rate reflects the actual market conditions. **To improve the ERM algorithm to implement a dynamic adjustment mechanism. This would involve adjusting the ModifierRange and ModifierBlockDuration in response to market conditions rather than having fixed values. For example, during times of high volatility, the ModifierRange could be narrowed, and the ModifierBlockDuration increased to provide more stability. Conversely, during times of low volatility, the ModifierRange could be widened, and the ModifierBlockDuration decreased to allow for more flexibility.** ---
**Author:** ![Sandel](https://avatars.discourse-cdn.com/v4/letter/s/94ad74/32.png) [@Sandel](https://classic-agora.terra.money/u/Sandel)\ **Post date:** [January 29, 2023, 8:37pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/16 "2023-01-29T20:37:34Z")
A easy way to cancel the arbitrary code is to not allow the Ustc withdrawal easy as it sound … ---
**Author:** ![Ricbullo](https://avatars.discourse-cdn.com/v4/letter/r/22d042/32.png) [@Ricbullo](https://classic-agora.terra.money/u/Ricbullo)\ **Post date:** [January 29, 2023, 10:51pm UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/17 "2023-01-29T22:51:05Z")
Hi man You seems know what you talking about so try to create an better proposal and put for vote for the community 🧐🧐🧐 ---
**Author:** ![Jetam](https://avatars.discourse-cdn.com/v4/letter/j/7ea924/32.png) [@Jetam](https://classic-agora.terra.money/u/Jetam)\ **Post date:** [January 30, 2023, 12:00am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/18 "2023-01-30T00:00:18Z")
As stated before this might be part of the solution. I think that ustc staking rewards should be taxed with 50% or more until supply is not down to 5b ustc. That way repeg might be quicker. Since I like gambling and I do believe ustc can be slowly pegged to higher levels I put some $$ into ustc today… will hold for a year. Risk reward ratio is good enough for me here 🙂 Fingers crossed this proposal will be enough! ---
**Author:** ![wrapped\_dday](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/wrapped_dday/32/19431_2.png) [@wrapped\_dday](https://classic-agora.terra.money/u/wrapped_dday)\ **Post date:** [January 30, 2023, 12:55am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/19 "2023-01-30T00:55:47Z")
> Additionally, implementing a multi-oracle system, where multiple independent oracles provide exchange rate data, can help reduce the risk of manipulation and ensure that the USTCs exchange rate reflects the actual market conditions. I have some preliminary research under a project name called [Titan](https://twitter.com/wrapped_dday/status/1604097010650345472) that can scale oracle functionality through sub-groups if necessary. Ideally, it would be to flatly distribute voting power across the system, but it opens it up to Sybils. This research is done under Onyx, and I would look to scale it with Algorand, potentially. (They do not work cross-chain much.) > **To improve the ERM algorithm to implement a dynamic adjustment mechanism. This would involve adjusting the ModifierRange and ModifierBlockDuration in response to market conditions rather than having fixed values. For example, during times of high volatility, the ModifierRange could be narrowed, and the ModifierBlockDuration increased to provide more stability. Conversely, during times of low volatility, the ModifierRange could be widened, and the ModifierBlockDuration decreased to allow for more flexibility.** Thanks for the writings, these look great. Here are some graphs of how I visualize some of the general movements: [Rough Visualizations](https://www.desmos.com/calculator/gyr7fduceq) As `|a|` increases, the more compression occurs on the modifications. As `b` changes, the point of compression changes. Might be an interesting way to determine various aspects of the algorithmic functionality – I find that Terra \<\> Luna is closer to a sinusoidal function. ---
**Author:** ![kobe\_major](https://sea2.discourse-cdn.com/terra/user_avatar/classic-agora.terra.money/kobe_major/32/20463_2.png) [@kobe\_major](https://classic-agora.terra.money/u/kobe_major)\ **Post date:** [January 30, 2023, 2:10am UTC](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849/20 "2023-01-30T02:10:56Z")
Duncan, what would it take to get the ball rolling on this and implement it? Does it have to be on the test net first before it can go to mainnet? do we need to provide capital to get it movign forward? [Next page](https://classic-agora.terra.money/t/ustc-re-peg-ziggy-final/49849.md?page=2)