I. Disclaimer
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 Terra Rebels or TerraCVita at this time.
This proposal is quite long and dense and is intended to spur discussion on a USTC Re-Peg proposal. Please refer to Layman’s Explanations after each section to digest a summary. In addition, I do not claim all of this information to be fully correct; most citations are from Investopedia (for financial terms) and the Classic Documentation for Terra Classic.
Any feedback from validators : to check the code;
and from quants : to check the math;
Would be greatly appreciated.
II. Summary
This is a discussion for a USTC Re-Peg Plan, which proposes modifying exchange rate reporting via price reporting. This proposal provides a starting point for encouraging arbitrage of USTC at any discounted price, even at our current zero-coupon discount levels. In order to do this, we must change the way we utilize the Oracle module, which requires full collaboration between the active validator set – and assurance that it will be done honestly.
This proposal is meant only as a discussion. Modifying oracle feeds is a dangerous game; it would be prudent to provide third-party, real-time audits of the price feeds to external oracle provides as a historical database for those in the validator set.
III. Motivation
The lack of stable remittance on the blockchain creates a volatile environment that does not cater well to many kinds of businesses, including financial ones. Though even some stable instruments experience volatility through external factors, like inflation or taxation, these are more predictable, and expected by the constituents of that environment.
Terra’s algorithmic market module enabled Terra to issue new money undercollateralized: traditionally, $1 of LUNA would be interchangeable with $1 of UST, and similarly with other foreign exchange currencies supported. While inflation introduced new tokens in the economy through the Mint module, the primary function that caused LUNC hyperinflation and the subsequent persistent de-peg was seigniorage, or the capturing of value via minting and burning, fills the oracle pool, which is depleting more quickly than we can fill it, unless we change core parameters related to seigniorage weight itself.
Without stable remittance on our blockchain, our ability to provide an environment for consumer businesses is an uphill battle. However, the goal of UST / Terra is to create an environment where uncollateralized, algorithmic tokens can flourish – otherwise, we are relegated to fully- or over-collateralized solutions, which centralizes the backing or uses excess security, respectively. It is, therefore, in our best interest to create mechanisms and controls that build upon this ideal.
IV. Proposal
Apply a flexible fee that modifies the Luna exchange rate to allow whitelisted Oracle denoms to trade at a premium or discount above or below existing cross-market exchange rates.
-
Layman’s Explanation
We sell USTC at a higher price than other markets, like CEXs. If we trend above peg, we sell USTC at a discount price than other markets. This function can also be inverted. We do this by creating a fee that can be changed later on. In this case, we’ll call it theReflex Rate.* -
Say that USTC is trading at $0.02 on most exchanges. We charge a tax rate of 0.2%, with 50% of this going to the oracle pool. We can apply a modifier to prices reported to price it at any premium or discount, like ±0.4%: in this case, USTC would trade at $0.02008 instead of $0.02. This means if you send 10,000 USTC ($200.00) from Binance, if you don’t factor in any other fees, the gross profit would be $200.80.
V. Understanding the Risks of this Proposal
This proposal carries inherent risks related to validator honesty and therefore, security. The broader community is now acutely aware of the Free-Rider Problem that exists with respect to the Oracle Pool Rewards, which facilitates the extremely high yield rate at this time at virtually risk-free yield to the delegator as determined by RewardDistributionWindow. This is two years of limited runway with few alternative plans, which carry their own risks. This particular proposal carries the inherent risk of dishonesty via Sybil attacks when casting the Prevote.
The Oracle module works by casting what essentially is a “blind-reveal” vote procedure on price feeds. All validators submit a price for the whitelisted denoms – in this case, ukrt, uusd, and usdr by default. After this vote is cast by each validator, they are revealed, and the blockchain computes the cross-exchange rate. Then, those prices are used in Market Swap Computes.
The simplest analogy is to consider how poker works: players place their bets on a hand. Once those bets are finalized, the betters reveal their hand, and the “best” hand wins that round. In this case, validators cast a Prevote for the whitelisted denoms (KRTC, USTC, and SDT) using MsgExchangeRatePrevote which encrypts the exchange rate of Luna (i.e., “LUNC”) with respect to the Terra peg (i.e. “USTC” et al) using random data encryption mechanism that we refer to as a salt.
The salt is computed from the function VoteHash() which is used in the Prevote and then the Vote itself through MsgExchangeRateVote. If the Salt parameter from the Prevote doesn’t match, the voter can’t be rewarded (i.e. receives no disbursement of money from the oracle pool). This entire process is about 5 blocks, which is about 30 seconds, and is known as the VotePeriod.
To abate this, we can feed Prevote history into an external oracle provider, such as Band Protocol, which used to service Mirror Protocol. If there is any evidence of attempts on oracle manipulation, the validator is slashed, up to 100%.
-
Layman’s Explanation
The validators are playing a game of Texas Hold 'em. There is an implicit understanding that each player (validator) is not cheating. If enough people cheat by playing cards that exist outside of the dealt deck, this proposal creates more financial consequences, which would serve as the nail in the coffin for this industry.
VI. Understanding the Financial Aspect
We need to ensure that if validators report a price that is deliberately higher or lower than everywhere else, we are forcibly creating a market arbitrage opportunity that can inadvertently damage or benefit different participating parties. Therefore, we also create a negative price risk to all assets in Terra by using this mechanism if we do not properly set the fee premium or discount in the operator.
The Incentives Ordeal
This sounds great and all, but if we take our current tax rate – 0.2%, with a 50% reward policy – we’d have to apply a steep premium to sell this offer. Remember, our protocol currently taxes on MsgSend, and for CEXs, it happens twice due to consolidation.
Let us take an example order-flow:
Alice sends 10,000 USTC from Binance to Terra Classic at a price of $0.02 / USTC, or $200.00. We assume a premium of +1%. She’ll pay 0.2% on this send, or 20 USTC.
When it arrives, she can immediately sell USTC to LUNC or another asset.
For example, she can sell this USTC into LUNC. If the swap rate of USTC <> LUNC is 1 : 100, she gets 101 LUNC instead, then pays 0.2% in taxes, with 0.1% going to burns, and the other 0.1% going to the reward pool.
She then can send it back to Binance, where she’ll pay two instances of the tax (once from our chain and another when it lands). This is 0.6% in taxes, with 0.3% going to burns, and 0.3% going to reward pool.
Sounds ideal, yeah? Here’s the problem: if you don’t set the premium high enough, it doesn’t make any sense to do this route.
Alice takes $200.00, then spends 0.075% in fees to buy USTC. She pays $0.15 to Binance, then receives $199.85 of USTC at $0.02 to trade: 9,992.50 USTC.
She then pays 0.2% in taxes to send it to the blockchain. She pays 19.985 USTC for this transaction, leaving her with 9,972.515 USTC.
She then immediately swaps this to LUNC. If the price of LUNC is $0.00017, this rate is 1 USTC to 117.647059 LUNC. She pays 0.2% taxes on the full swap, including a 0.5% spread fee, and the standard compute fee of ~0.10 USTC. 1,173,237.058823 LUNC requires 8,212.659411 LUNC in taxes, which is deducted to garner 1,165,024.399412 LUNC.
She’ll send this amount directly back to Binance and be taxed twice – once for the send, once for the consolidation fee. This deducts 4,660.097598 LUNC, leaving Alice with 1,160,364.301814 LUNC.
Assuming she closes this arbitrage directly to USD, at the same price of $0.00017, she’ll land with $197.26 – oops!
The only benefit this particular route has is that Binance and Terra Classic get a bunch of taxes. Great for everyone except the people we’re trying to incentivize.
Therefore, we need to create a high enough rate to ensure that those arbitrageurs profit while we still collect fees.
VII. Designing a Flexible Rate
We can’t just set the premium or discount higher using a flat rate, because if we’re only 2% off peg in the long run, and we applied a +6% premium across the board, we’ll actually be paying the arbitrageurs free money. Not ideal.
We can instead create some kind of log return on this, as we’d get businesses on-board, and arbitraging profits while “close-to-peg” would be sustained. But we also don’t know how much could be sold off in one go. Say we get 100 businesses on-board, and they’re all selling to customers using USTC. Say one party owns 1b+ USTC. Can we withstand that price shock?
Another option is to delve into my preliminary research on a flexible fee-maker for mint-and-burns called the Reflex Rate. This is a complex series of formulas that captures value on properties of currency reflexivity as seen in Terra <> Luna through two primary notions: seigniorage (mint) and demurrage (burn). I can explore this option more if the basic idea is appealing.
VIII. Personal Views
I wanted to research this idea because it seems interesting and links well with my work on the Reflex Rate. However, I’m not keen to taking shortcuts, and modifying the Oracle voting procedure seems like one at this time.
However, I do want to reflect on the process of how the functionality works. This particular solution takes an immense amount of time, energy, and research, and without the data, it wouldn’t make sense to implement. Furthermore, altering the base code of the oracle is a subject I want to tread extremely lightly on.
you have our support, let’s do this