Modify Luna Exchange Rate with Novel Fee Variable (Discussion // USTC Re-Peg)

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 the Reflex 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.


Good. But how can we reduce the ustc supply? Can we also burn all another *tc?

1 Like

That’s a genius plan.Would it be a one-way& one-coin swap?From Ustc to Lunc only.


Awesome idea, well explained and opened for ideas and complementation.
As i’ve said before, the applied math techniques sounds and match very well, but other aspects, like techniques to implement, insert the code in/off chain, and Validators contributing or joining, I leave it open for friends to opine…
A tactic of real value for this purpose, easily supported, congratulations for the explanation and idea, again.
Forwarding for sure into Brazilians communities!

1 Like

First of all, thank you for your work. But being not a great specialist in finance, I would like to understand what is the advantage of this approach to the USTC repeg for LUNC holders. If I understand correctly, this proposal implies that billions of Luncs will be minted, the volume of supply will grow by billions and huge pressure will be exerted on the price of Lunc on the exchanges. How will we avoid another death spiral? I would be grateful for clarification for the uninformed like me.

With all due respect to the validators, anything that’s based on the Prisoner’s dilemma (or group variations of it) is doomed to fall prey to exploitation sooner or later. Do Kwon was fond of mentioning optimal game theory outcomes, so if there’s a path here that rewards dishonesty you can be sure someone will take it - it’s inevitable. The only question is how long it’ll take… and considering we’re playing with a $1B asset here (the blockchain), I don’t think it’s a good idea to risk it all on the foibles of human nature. :man_shrugging:

Also as the author states, messing with the Oracle pool is something that shouldn’t be undertaken lightly.

Having said all that, I do like how much thought went into this writeup and I hope we can develop the idea further… maybe if there’s a way to plug the exploitation holes so to speak, this could be further grown into a viable strategy? Since this proposal is still in the germinal stage, I don’t think it’s fair to judge it through the binary lens of YES/NO support (or lack thereof) that we usually apply to props here on Agora. Ergo, I hope the comments section will soon fill with feedback and perhaps even ideas on how to further develop the approach outlined in the OP; I look forward to reading everyone’s replies!

Shalom! :pray:


Thank you for the good advice. Reading this suggestion, I could see how much you’ve been researched about.

This proposal fits well mathematically, but in conclusion, it is a proposal with a set time limit. And the Oracle pool is inevitably depleted.

However, I think It is a great proposal If It has some modifications.

The first part that needs to be modified is where to provide 1% ARB?

Oracle pools are still rapidly decreasing today. If additional free money is provided in this situation, the lifespan of the LUNC chain will decrease rapidly.

I think I can find the answer by referring to the alliance of TFL.

There is a way to get 1% ARB benefits from a third pool where you want to promote your chain using the LUNC chain, not LUNC or USTC.

Let me give you an example. The altar that issued the exam coin is a chain listed on the cosmos ecosystem but not recognized by people.

They want to expose to many users and increase Coin’s TVL while paying for their promotions.

Then they create a separate Reward Pool and link it to the Terra Classic chain.

When the USTC-LUNC pair transaction is traded at $200, the user will receive an additional $2 ARB in EXAM coins.

But most users will want to immediately dispose of the $2 exam coin they received.

Therefore, the compensated EXAM coin must be automatically staked, and a minimum of 21 days of undelegated period must be granted.

Through this procedure, the EXAM coin altar that participated in the promotion can inform users of its coins at a low promotional cost and increase TVL.

Alternatively, you might consider handing over a portion of the LUNC-USTC tax revenue from this relationship to the EXAM Coin Foundation. Because this architecture can clearly improve the face value of LUNC and USTC in the future, and they can be compensated for a significant portion of their promotion expenses.

Algorithmic rotation trading is already a failed model. TFL learned the concept of alliance through the collapse of the Terra Classic, and we will also have to work with other chains to avoid repeating the same mistake.


Good idea Duncan…BRAVO :clap:t3: you have our support, let’s do this


I know we’ve discussed this but I’ll post it up here too so the community can weigh up the pros vs the cons.

It’s difficult to model this as its such a different idea and I’m not sure what dataset you could apply. So to test I try to exploit the system. As an attacker I buy USTC, send USTC to chain, swap into LUNC, sell LUNC for a profit. Rinse, Repeat.

What this is doing is driving up the demand and price for USTC and also drives the liquidity onchain. But as a result it greatly increases sell pressure on LUNC. Driving down the LUNC price and driving all the LUNC off chain.

When USTC is at peg, you then could increase LUNC demand by reversing the rate but until then LUNC would take a hit.

The next thing is the LUNC has to come from somewhere to swap into. If it’s minted - LUNC price gets driven down. If it’s through LP, why would someone swap their LUNC at a loss, when they can send it off chain and get more.

It is a very interesting idea and very different from what’s out there, I just personally think we would need to address those issues I raised.


If LUNC is minted because of your proposal, then I am most opposed to this proposal.


@Thorchain.BULL @ek826 need your expertise sir please review this once

Thank you sir, We need to have discussions with this idea whether is really feasible or not…

1 Like

read this pre crash article and you will understand why. Its not about making ustc holders rich.
We need to come back, but with mechanism that will prevent a death spiral.


I know how Luna worked before the crash. My comment is on the same cons as Redline’s.

This proposal attempts to adjust our chain’s swap ratio dynamically in reaction to the market.

I believe a less complicated approach would be to set our swap ratio where we choose and let the market adjust to the peg we set. There should be plenty of arb opportunities (creating tax revenue) this way.

If the hard peg is incrementally increased there would be an influx of tax revenue as the market corrects to each peg change.

1 Like

I think the biggest reason for the Luna crash is because it consists of two coins. Physically and mathematically, the multiple of 3 is the most stable structure. The two of single structures are easily collapsed by external impacts. It’s not just a field of study, it’s easy to check in your daily life.

If you want to repeg USTC with an algorithmic structure, you need to add another coin other than LUNC/USTC. It could be LUNA or it could be a completely different third-party chain.

1 Like

Smart proposal. What do you think about Market Maker Module? We can start real ustc burns.

This proposal attempts to adjust our chain’s swap ratio dynamically in reaction to the market.

I believe a less complicated approach would be to set our swap ratio where we choose and let the market adjust to the peg we set. There should be plenty of arb opportunities (creating tax revenue) this way.

This is ultimately the crux of the discussion. How do we incentivize engaging with the Terra <> Luna arbitrage mechanism no matter what the price is?

The only issue I see with the peg-setting is that it’s the same thing as what I describe, except we commit the Prevote to be a fixed rate. How do we ensure that all validators are honest, as @RabbiJebediah mentioned? One option is to slash any validators that don’t report the exact price, but this strikes me as totalitarian-by-code.

We could set the price of any Terra denom to “some fixed value” but I think this defeats the purpose. This becomes even more true as you solve Terra <> Terra swaps, as any number of foreign exchange currencies (including things like Bitcoin, Ethereum, etc – things we could eventually support with the integration of THORChain) will effectively be a double-floating rate.

This also means solving the double-floating rate problem can integrate well with Mirror, and effectively opens up brokering to the wider public from a “sovereign” perspective – I will no longer need my brokerage to “approve” that I can handle options contracts, since any double-floating CPMM swaps are like options (something Robinhood is selling to retail, anyways).


With all due respect to the validators, anything that’s based on the Prisoner’s dilemma (or group variations of it) is doomed to fall prey to exploitation sooner or later. Do Kwon was fond of mentioning optimal game theory outcomes, so if there’s a path here that rewards dishonesty you can be sure someone will take it - it’s inevitable. The only question is how long it’ll take… and considering we’re playing with a $1B asset here (the blockchain), I don’t think it’s a good idea to risk it all on the foibles of human nature. :man_shrugging:

This is the exact problem with this particular proposal. However, I wonder if we can extend the functionality proposed to the broader community somehow. Externalizing Prevote / Vote feeds to an oracle runs multiple types of dependency risks. Would it be feasible for community members running a peer node to feed exchange rates programmatically using immutable code (i.e. a contract)? This is something I could potentially integrate with Onyx machines, and is a similar setup to Binance’s Full/Witness schema and perhaps we could take inspiration from the concept of SegWit on the Bitcoin network.

In that sense, any type of attempts at Oracle manipulation from the active set validator level is now a prisoner’s dilemma between the active set and the “community nodes” which are running these oracle feeds in tandem. However, this idea could potentially scale the throughput of foreign exchange trading which requires lightning-fast latency time.


Is it your idea or something that was negotiated with @Thorchain.BULL? Sounds like a “conflict of interest” in the context of his commentaries on community DEX and the way he voted on it.

1 Like

No. Any arguments or proposals like this are made with the assumption that the system is permissionless (which, as far as I know, is permissionless, and open-source).

I use THORSwap to bridge between Cosmos and Ethereum, mostly. I also provide liquidity on the ATOM side. It’s quite cool. Reduces the need for routing through CEXs.

1 Like