0. Disclaimers
I manage the Onyx validator with the assistance of PFC. I mostly work solo and self-study crypto ecosystems; therefore, I do not have any formal affiliation with Terraform Labs, or other major organizations like TerraCVita.
The final proposal will be put up on January 31st, 2023 for vote. This date is subject to change!
1. Previous Discussions
#1 Modify Luna Exchange Rate with Novel Fee Variable: apply a fee to uluna exchange rate after the Voting Procedure is completed called ArbitrageModifier (or similar).
#2 Ziggurat: utilizing the concept of pegging USTC âpenny by pennyâ (step-wise) to reach our goals, a.k.a. âsoft-pegging,â using the ArbitrageModifier.
#3 Ziggurat and the Exchange Rate Modifier (ERM); using dynamic peg control using the Greeks (options).
2. Summary
This is a 4/n discussion to propose a way we can âhold the pegâ using simple incentives to engage in arbitrage at any price level between Terra <> Luna. We do this by applying a fee to the usdr exchange rate (âLunaâ), or to the stablecoin tokens like uusd (âTerra,â or USTC in this case), and add capital controls like heavy taxation when it moves too far from an arbitrary âpeg.â
This discussion iterates on the previous concepts and clarifies important issues highlighted by community feedback. The discussion points are:
- Is modifying the exchange rate after the
VoteProcedureconsidered âmarket manipulationâ? - Do âfeesâ and âtaxesâ differ when discuss âmonetary policyâ?
- Is âmonetary policyâ considered a form of âmarket manipulationâ?
- If we move forward with a proposal like this, how do we ensure it doesnât spiral out of control?
- Similarly, how do we ensure weâre prepared for what happens when it returns to peg?
3. Background
The proposals asks to add an automated fee â much like many other Layer-1 âgasâ fee systems â that is centered around USTC itself, instead of the L1 token (in this case, LUNC). For this proposal discussion series, this modifier is called the ERM, or ExchangeRateModifier.
The ERM increases or decreases the exchange rate for USTC by a given amount, say, +-0.15%, after itâs submitted. This brings up an interesting discussion point: what triggers the ERM in the first place?
Many Layer-1s, like Ethereum, will refresh rates based on network activity, or how much people are using it. The core issue with using Ethereum (ETH) for gas is that its value changes all the time, and its supply always changes. Imagine at one moment you are paying $15 for a transaction fee, but if you wait 30 seconds, it could be $18!
We struggle with this problem on Terra Classic, except weâre in a much âsaferâ position because we use USTC instead of ETH. If you use it on our network, itâs the difference between $0.01 and $0.015. Not a big deal for small transactions, but start trading a lot and the half-cent adds up.
You can see some stats on Ethereum at ultrasound.money.
4. Motivation
Re-pegging USTC extends to a greater idea â repegging SDT. Donât know what that is? Itâs Terraâs version of the International Monetary Fundâs Special Drawing Rights, or SDR. In our code, we refer to it as SDT, or you might better know it as LUNC.
Wait, re-pegging LUNC? How does that work? Well, we service more than just USTC. KRTC, which is pegged to the Korean Won (KRW) makes up at least several percent of the capital that LUNC can service. We have 20 other countries we also service, or can service, with an ability to add more!
It might be more accurate to think that we re-peg SDT with about $1.5b of value, or the difference of LUNCâs market capitalization and USTC (+KRTC+other Terra stablecoins). $1.5b is a much more manageable value than $9.5b, which weâll have to address down the line, of course.
Now, the motivation behind this proposal is the same as anybodyâs â make money, direct that value back on-chain. In this sense, the ERM proposal just asks people who have USTC on other exchanges like Binance to bring it back on-chain. We also give them the opportunity to stake with us, or cash out â it is a free market, after all.
5. Addressing Market Manipulation Concerns
The Proposal asks for the exchange rate of our native tokens (LUNC, USTC, KRTC, etc) to be modified after the original prices are submitted by validators.
The core question asked by @NovaValidator is: how is this different from market manipulation?
The counter-argument here is: isnât anything that we manually vote in market manipulation â say, the tax, or increase in gas fees? Or does this differ if we instead label these as monetary policies and then lump it in with inflation? Now itâs okay, right?
The only difference between Cosmosâ inflation module, as it were, and monetary policy in governments, is that it automatically distributes based on how much capital stake users have in the network. It is predictable on a per-block basis.
When you elect a leader to decide âhow much we should inflate byâ every year, we end up with an inherently unpredictable facet (humans). The additionally have their own biases â we all have a tendency to be self-preserving and in the interest of maximizing our own gains.
It would simply be easier to âelectâ a program and then alter the program mutually in an open-source environment. We can observe how it works, and train its branches or prune them, as necessary.
It is, therefore, my opinion, that automated systems arenât market manipulation, because it requires collective effort to change. If we elect a board to enact all changes, especially ones that relate tangentially to the idea of âmonetary policy,â we are in danger of mirroring how our governments work already â just without having learned anything.
6. Proposal for Non-Technical People
We make a lever that moves the price of any Terra token (including SDT, or LUNC). We add a trigger that begins this, to avoid purposefully incentivizing one party or other. In code, weâd call this a conditional (if A then B)
We can think of it like a grandfather clock. For all you zoomers in the room, a grandfather clock looks like this:
The Anchor escapement mechanism allows the clock to run with the pendulum â in this case, we determine a âsoft pegâ to begin the swing.
We could pre-determine when weâre going to start this â or we could code it as part of the algorithm. In this case, we want to use time â for options freaks, this might be called theta, and in the context of blockchain, weâd say number of blocks until expiry.
Letâs say we determine the âsoft pegâ by taking the last given exchange rate. For example, this might be USTC = $0.02. This is our âpendulum.â Now, how far can we swing?
We pick two parameters: high and low. When the price swings too high or low, we stop the mechanism. Say âhighâ is USTC = $0.03 and âlowâ is $0.01. We have a âswinging rangeâ of $0.01.
In a way, this is like âvolatility toleranceâ of the algorithm. Terraâs algorithm is already designed with this in mind. Now we are adding a âtime toleranceâ for the algorithm. Options peeps might like analogies to vega / volga / vanna and theta respectively.
If we think about time with respect to how anchor escapement mechanisms work (pendulum in grandfather clocks), they are isochronal â or occurring in regular intervals. So, our âtime toleranceâ for this âsoft peg swingâ has to be a predefined set of blocks, say 10 blocks. (or a little over 1 minute, roughly two oracle cycles).
This allows predictability in our addition (or subtraction) of âtorqueâ to the peg maintenance system.
7. Proposal
Add an exchange rate modifier (ERM) that derives a SoftPeg from the last-reported oracle prices cast. If the modifierâs already active (the state hasnât changed), donât apply the modifier. Then, determine a range of an acceptable volatility ModifierRange for this soft-peg â ±$N from SoftPeg. Finally, determine the acceptable time period for this modifier to be active by quantity of blocks, denoted ModifierBlockDuration.
To simplify this process, we apply a discount of ModifierRange / 2 if weâre âde-peggedâ from SDT and a premium of ModifierRange / 2 if weâre over SDTâs peg.
8. Example
- Capture the last-reported exchange rate for
uusdis0.020000.
This value is now SoftPeg = 20000uusd.
- Conditional: is the modifier already applied? If so, cancel the function. Otherwise, apply it.
ModifierActive ? break() : applyModifier()
- Determine acceptable volatility as
ModifierRange, using an operator of addition or subtraction inuusd, or similar.
ModifierRange = 1500uusd
SoftPeg.high = 21500uusd
SoftPeg.low = 18500uusd
ImmediateModifier = 750uusd
- Determine the amount of blocks for the modifier to be active.
ModifierBlockDuration = 10
- Simulate results
The soft peg is $0.02. If the modifierâs not on yet, we turn it on. We tolerate a price swing of ±$0.0015 before shutting it off automatically. We tolerate 10 blocks of the modifier to be active before shutting it off automatically. When the guards are determined, apply a discount of $0.00075 to USTC until the guardsâ conditions are met.
9. Community Bits
ELI5?
We re-peg this bad boy one soft-peg at a time. That soft-peg is whatever the validators reported last time. Since weâre de-pegged, we discount first.
Why discount first?
We need help, or in this case, someone else to make money to help stimulate our âchain economy.â If weâre over the peg, we benefit from paying people to use our chain instead of the other way around.
Can we use <other personâs> proposal?
Yeah, of course. We just need to decide on something that works for all of us, together. Some ideas I like so far is @RedlineDrifterâs Divergence Tax and proposals like @X-fileperseekâs buyback and save.
How do we benefit from this proposal?
For one, more trading creates more burning. It also creates more transactions which will send money to the oracle and community pool, which pays into the staking yield. If this mechanism is designed properly, we can actually eliminate the tax altogether and go full-force into the re-peg. You can buy LUNC or USTC at a discount depending on how itâs working at the time; discounted LUNC can potentially increase how much of the supply we need to âremoveâ by burning. (so, we might not even need to burn, if you think about it â since all of the LUNC would be bonded!) The most important aspect is that, if this works, we can not only re-peg, but have a methodology that keeps it there. Stable. UST.
Can you explain what you mean by âwe might not need to even burnâ?
When you stake (bond) LUNC to a validator, you remove it from whatâs called the âfloat.â We benefit from having those tokens available to use, not destroying them. Burning contracts the supply; this does the same thing, but allows us to use that money collectively.
How do we know that a whale wonât come in and sell all their USTC at once? Wonât we back at square one?
We donât, and yes, we will. This is also why we canât peg overnight using debt restructuring (deliberate or through burns) or using reverse splits. In any of those cases, youâve just altered supply holdings without accounting for proportionality. Even this method doesnât guarantee that the peg will hold at a dollar. The point is that we develop solutions that can hold peg at any soft-peg level â because those methodologies are extremely transferable to other Terra stablecoins as we go global.
What about collateralizing USTC with BUSD (or another stablecoin)?
We can, but doesnât that defeat the point of what USTC is in the first place â algorithmic and decentralized, not controlled by any institution, including Binance? This kind of proposal benefits not just Binance, but any market thatâs had exposure to Terra assets. (So, all of them.) That is why itâs so important to get the finer details right and explain them so you know what youâre voting on. Fewer changes, higher impact.
Shouldnât we test this before putting it live?
Of course. I would ask that this proposal starts by funding quants to crunch and collect data â it doesnât necessarily have to be me. In fact, I would prefer it to be another team who can provide public testnet data. Users could additionally jump on the testnet, access a faucet (tokens provided for testing) and trying to break it â with incentives, of course. This way, we can refine the proposal for a go-live approach to handle billions in volume.
10. Personal Comments
Hopefully, this proposal should be simplified from the last iterations. I am trying to retain the nuance of the backend designs while making it easily understandable.
The reason I want to enlist quants to help gather data on a testnet is because we are ultimately trying to handle trillions in volume. Billions will be the first step, but trillions is the next step. (Remember that forex markets handle trillions in volume daily; this doesnât even include derivatives markets, which Ethereum is more likely to be able to handle first.) We can also get the community participating in a testnet process, allowing them to understand how testnets work.
I would like people to consider that at least 40% of the USTC supply is held by Binanceâs hot wallet, LFG, Ozone treasury (among many other treasuries) â basically, big holders. Re-pegging would do them right, but it may create an event where we suffer a huge price shock. Plans to address this are separate, as Ziggy is focused on âre-pegging,â not âpreventing another de-pegâ, though it does factor it in. We are looking, ultimately, to diffuse the risk by spreading out âwho has the USTC,â but they need a reason to let go of it first â which, frankly, is going to be a re-peg.
On that note, we probably work with ~10% of the total supply. This proposal is the simplest way to appeal to the main users of the blockchain: arbitrageurs. The more robust our arbitrage mechanisms are, the more stakers benefit from their work. Think of it like earning a commission whenever forex traders used the network: if you earned 0.01% of a trade that was charged 0.02% in fees, and you got a million of those a day? Youâd be sitting well year-to-year. Big picture.
