Proposer : Duncan Day (@wrapped_dday)
Author : Duncan Day
0. Disclaimers and Declared Biases
Duncan manages the Onyx validator with PFC 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: apply a fee to usdr or other whitelisted denom exchange rates to provide an incentive for arbitrage.
#2. Ziggurat: 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): 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: 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 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
The ERM class is outlined in the pseudo-code below:
class ERM {} // base class
struct Conditionals {} // when should the ERM turn off?
var = guard<type Rail>; // 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<type 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:
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, 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 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.
