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 – but this date is subject to change if we cannot reach a mutually agreeable plan together.
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
.
2. Summary
This is a 3/n discussion to propose a scalable method of arbitrage incentives between Terra <> Luna at any price level, especially at our deep-discount (“de-pegged”) levels. 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), with a target “stop” level to prevent “overflow.”
This discussion iterates on the previous concepts and clarifies important issues highlighted by community feedback.
3. Background
Terra was initially designed around the basic incentive mechanism known as arbitrage:
- Arbitrage occurs when a security is purchased in one market and simultaneously sold in another market, for a higher price.
- The temporary price difference of the same asset between the two markets lets traders lock in profits.
- Traders frequently attempt to exploit the arbitrage opportunity by buying a stock on a foreign exchange where the share price hasn’t yet been adjusted for the fluctuating exchange rate.
- An arbitrage trade is considered to be a relatively low-risk exercise.
For example, if a user purchases USTC @ $0.02 on Terra, then sells it on Binance for $0.03, they have earned $0.01 for 1 “unit” of trade.
This arbitrage translates internally. You can use your Terra, like USTC
, to buy Luna (LUNC
), and vice versa. These exchange rates are cast by the validators in a process called the “Voting Procedure,” where each validator posts the exchange_rates
.
Example block: 10,193,375:
salt: "400f"
feeder:
terra1s8x58csttl3wgw0vgds5ptlrq3lgeau6f6wusz
validator:
terravaloper1xl2ujgt7f6xn8v26rjkhy4f20x5plc3nq6nql7
exchange_rates: ""0.000295594206874093uaud,0.00025988545353405ucad,0.000188358954092912uchf,0.001398435318661292ucny,0.001423678820640927udkk,0.000191376691164571ueur,0.000166983721981012ugbp,0.001526318082244413uhkd,3.029580302927471892uidr,0.015704698819674663uinr,0.02771880738142329ujpy,0.261949510563912077ukrw,0.663612297496888114umnt,0.000904542991035891umyr,0.001971752033675646unok,0.011162123826391876uphp,0.000150794404366008usdr,0.002070056692098034usek,0.000269649063995179usgd,0.007037748996891885uthb,0.006118288984096355utwd,0.000194629930452078uusd""
Currently, all of our exchange rates are similar across the market. There are users who are performing arbitrage, but not nearly enough to push the USTC peg high enough.
This discussion series attempts to resolve the lack of trading activity on CEXs (like Binance) and DEXs (like Terraswap) by providing a nominal incentive for those traders.
4. Motivation
In order to re-peg USTC
(and all other Terra stablecoins, by extension), we need one of the following:
- more money (supply)
- more use cases for money (demand, or “utility”)
However, we are bleeding cash rapidly and not using our available runway (money available for use, such as expenditures) to subsidize demand.
We are, relatively speaking, flush with cash (market capitalization trending downwards from $3.5b since the re-implementation of the staking in ~September) – we can see this as “total available capital for use.”
Over time, the amount of capital as measured by market capitalization has dropped by roughly $2.5b in the last several months, and for good reason, too: it’s more profitable to short LUNC
than it is to go long!
Now, one way to go long is to simply “buy more.” That’s increasing your “supply” of cash. However, it seems like there’s not a really convincing reason to buy. (You’re also paying carrying costs!)
Enter “demand.” This is “reason to use your cash.” People don’t want to give up their LUNC
, so we provide an incentive to use something tied to it – in this case, “Terra,” which includes, but isn’t limited to, USTC
.
At the very base level, if swapping Terra <> Luna sucks, then people will not want to use the blockchain. Full stop. If you want to get rid of Terra, you can, but then you’d just have LUNA
or any other Layer-1 blockchain, except with no functional dApps.
4. Proposal for non-techies
We want to provide a really basic system so our blockchain can process monies in the form of Terra or Luna faster, or slower, but we also want to automate this bit because we’re lazy. (and we’d rather spend 8 months, 8-12 hour days to automate a process that might be a few seconds. programming.)
This super basic system is a pedal-like system like one you’d find on a car. Terra is our car, and we can tell the prices to go faster (accelerate) or go slower (brake) by pushing the price up or down by just a wee lil bit.
A premium is an extra price you’d pay for making that swap. A discount is a reduction of price for making that swap.
In this proposal, we tell the ERM to either:
- Increase the price of Luna by +N%, or
- Increase the price of Terra by +N%.
This creates an implied premium or discount on the markets that trade these coins. For example, if we increase the price of the USTC exchange rate by a penny on Terra, the markets over on Binance need to catch up. This also means you could buy Luna (LUNC
, in this case) at a discount and stake it.
We then ask the ERM to turn off automatically when we hit one of our “soft-peg” targets or when the validator exchange rate price-feeds deviate too far from one another.
This part is very important to note. If we modify the exchange rate, the next price feed may spiral out of control, causing a chain-reaction of inaccurate price feeds. (Credit to: @Asobs for pointing this out prior to this discussion.)
In short, we could have a price feed that modifies the price of Luna or Terra by +N%. If the price gap we purposefully made doesn’t settle accurately, we may accidentally reapply this exchange rate modifier.
Think of it like driving a car in traffic. We need to get to our destination by a certain point. (in our case, this is actually 2 years from May 2022, which means we have about 16 months if we don’t otherwise have plans.) In order to get to our destination on time, we need to go faster on the open roads, slower in traffic and turns, and detour when there’s obstacles on our course.
For our options geeks, we can formalize this analogy in the following way:
- Destination:
delta
- Time-to-destination:
theta
- When to detour (“navigation”):
vega
However, we need to automate this process, as votes go through a 7-day process, provided another 7-day signal wasn’t posted prior. It is too slow to handle this kind of change, and so requires careful crafting from the developers to implement.
5. Proposal
Introduce a new, automated lever called ExchangeRateModifier
, or ERM
, and apply it to the Luna exchange rate usdr
or individual exchange rates “Terra” uusd
, ukrt
, ujpy
, et al, after the Voting Procedure. Then, guard against capital hemorrhaging by using options-inspired methodologies.
The ERM
is a one-time, conditional application of fees, to be turned off when specific conditions are met:
- A “soft-peg”
Target
for theERM
is met (delta
), which is defined when theERM
turns on. - The “soft-peg”
Target
for theERM
is not met, which is defined in any number of possible ways: number of blocks passed (theta
) or exchange rates trend too close to theRewardBand
limit, the default of which isDec
at7%
. (vega
)
An example flow of implementing this kind of fee lever is as-follows, using bps
:
-
ERM.delta
(“soft-peg target”) has a predefinedbps
target:+0.15
. -
ERM.theta
(“time-until-expiration”) defines an expiration time for theERM
by specifying how many blocks must pass before theERM
shuts off:25
blocks (or roughly 2.5 minutes) -
ERM.vega
(“implied volatility guard”) defines an emergency mechanism for theERM
by gauging implied volatility from the existing exchange rates when theERM
is first applied:+0.30
. - In the event that:
delta
is not met;theta
reaches expiration; orvega
suggests that validators will trend towards casting rates outside of theRewardBand
, disable theERM
until cross-market exchange rates normalize.
6. Questions
ELI5 the proposal, please.
We tell the blockchain to “do something” and make the prices of coins or up and down. But only a little bit, and only for a little bit. If it doesn’t do what we want (or we just forget, lmao), we turn it off.
Does this burn???
If designed properly, it will burn more than the tax ever will. Such an implementation would mean we could get rid of the tax in favor for this. (We already have taxes and fees baked into the system. Unless you love doing taxes and trading through financial quicksand, this is probably a better long-term option.)
OK BUT HOW MUCH DOES IT BURN???
I don’t know. But that’s why we can test it in small amounts and if it doesn’t work, oh well, Duncan learned something new. Think of it like trying to find a different kind of fuel for burning. Pine burns fast and hot, but you’ll need a lot of it to burn. Oak takes longer to light on fire, but burns for a lot longer than Pine.
Will this nuke LUNC’s price?
Designed properly, it will actually make stakers earn more than they currently do – not just by burning, but also because the USTC rewards stakers get from burning would increase. (Remember, the Oracle pool is filled by swap fees!)
This proposal has been changed after feedback. The inclusion of option-like methods to the ERM
, particularly ERM.theta
, should prove useful – we might explore the integration of MEV protocols such as Skip, which is on LUNA 2.0.
Why are you not including other Greeks like Rho and Gamma?
We don’t include Rho until we adjust this mechanism for inflation, meaning that if we re-enable inflation/minting, we can add a method ERM.rho
to accurately determine a “risk-free” rate.
We could probably include Gamma if we set >1 instances of ERM.delta
. We support over 20 native currencies from different regions. Including ERM.gamma
would be a useful measure after we’ve tested ERM.delta
on several tokens. (Why this bit is cool: if you love tricrypto2
, you’re gonna love eicosidyocrypto2
.)
Ok, but if there’s a discount on LUNC, doesn’t that mean the price will nuke? Also, does this mean a bunch of USTC could come on-chain, buy out all the LUNC, and then stake to validators for a Sybil attack?
In its prior forms, yes. The suggestion to include options-like methodologies would abate this to some degree:
-
ERM.theta
would mean that arbitrageurs must execute within a certain block timeframe. -
ERM.delta
means that when arbitrageurs hit a price change (“soft-peg target”), they now are subject to immediate market adjustments (market responsiveness) -
ERM.vega
forces arbitrageurs who want to try to obliterate the price to do so within theERM.theta
period.
The theta-vega
threat vector caps the arbitrageur threat to a very small timeframe. If the block period is 25
, then the arbitrageur would have 2.5 minutes to execute a MEV attack. If you squash this block period to 1
, then the arbitrageur must flash loan to execute a MEV attack.
There is an incredibly cool design feature we can make around this to internally collateralize the protocol: “vault-breakers.”
Say that we use part of the fees collected while trading to make a vault, kind of like the burn tax. The only way to open this vault is to execute the
theta-vega
MEV attack. If the vault is cracked, the entire network stalls all functionality and distributes fully from the protocol’s internal vault.Attack vectors will always exist in this kind of protocol due to the arbitrageur mechanism. Better to know and understand it than to be caught off-guard by it!
7. Aggregated community suggestions / feedback (open for later edits)
If users take a discount LUNC purchase on Terra using this kind of proposal, automatically stake and/or vest that LUNC to the user over time (e.g. 21 days) to prevent mass arbitrage.
(Duncan’s suggestion: see if you can incorporate Staking LSDs here.)
Since the Market mechanism for Terra <> Luna is turned off, we’ll need to use a liquidity pool like
LUNC-USTC
to route trades through.These liquidity pools, or LPs, mint a token usually denoted
uLP
for the assets you’ve deposited. We can send these LP tokens to the burn wallet, which would make the burn wallet a permanent burn outlet, while providing better slippage rates the more TVL the burn wallet holds.(Duncan’s suggestion: This is insanely interesting. I would find a way to organize this for users.)
7. Personal Comments
I’ve touched up the proposal to not directly interfere with the Voting Procedure, included some safeguards in the form of optionality methods (the Greeks) to ensure we don’t go overboard on key concerns people let me know about.
Much more pleased with this iteration than the last few. I am hesitant to include any controls on ERM.gamma
because this would include controlling the internal swap rate to some degree at a “hard-coded” level. If anyone has any ideas here, let me know. Otherwise, ERM.rho
would be an interesting method to look into.