Oracle Revamp Proposal for Columbus-3

@dokwon yes we are thinking the same approach. There are several modifications that need to be made to the constant-product model to work for us though. After some thought I think that the adaptation is not that simple. To name a few issues:

  • When defining the constant product we can’t use the size of the Luna pool per se, since its fiat value will fluctuate and so will the fiat price of Terra being offered. We need to define the product using the fiat value of the Luna pool, and therefore adjust the size of the Luna pool on oracle updates.
  • The constant product model offers the same marginal price to buyers and sellers, which doesn’t work for us since we want to enforce a minimum spread on both sides. So we need to offer different bid and ask prices even for marginal trades.
  • We need a way to “replenish” liquidity to prevent spreads from growing too large, which of course uniswap doesn’t do. I think there are problems with both approaches we have discussed (reset cap or trailing cap) – a simpler approach that I think is more robust is to add Terra or Luna liquidity back to the pool at a constant rate until a target size is reached (equivalent to a 24h cap).

I wrote up a detailed proposal addressing the above, including some graphs showing how I think this may work. Let me know what you think and let’s iterate.
constant-product-proposal.pdf (220.9 KB)

Interesting. In layman’s terms, a summary of this thread:

The system will launch swaps at the peg. The system offers an exponentially worse swap rate as swap volume increases to favor one direction of swaps, but swap rates always regress to the peg over time. Swap spreads are determined by the net daily Luna supply change relative to the daily change cap; thus, if net swap volume is favoring Terra to Luna swaps (net daily luna supply increasing), the spread will not move above 2% for Luna to Terra swaps until net swap volume favors this direction (net daily luna supply decreasing). @dokwon suggests in the OP spreads be relative to a 2% Luna total daily supply change cap, while @nplatias suggests in the “Terra Constant-Product Swaps Proposal” paper spreads be relative to a 1% Terra pool daily change cap.

Does this sound right?

A couple things I’m curious about:

  1. Implications for the Terra economy: These spreads effectively limit the volume of swaps that can happen in one direction close to the peg over a certain period of time without counteracting swap pressure. @nplatias in your paper you suggest initializing target Terra swap liquidity at 1% of the Terra supply, with the models indicating rapidly increasing spreads as the terra pool size fluctuates (a .07% change in terra pool size implies a spread of over 10%). Assuming no one will pay 10% premium on a stablecoin, what are the implications on how this might restrict the growth of the economy over time? Moreover, tagging onto this, seigniorage:
  2. Optics of seigniorage: Theoretically speaking, these spreads have an impact on seigniorage. For the system to ever mint terra ie expand the terra economy, there is a minimum 2% cost (and as clear from the paper, potentially much higher). How do we manage optics here?

@nplatias I really enjoyed your paper, and I have two questions.

  1. In your paper, you took LUNA/SDR market as an example. Do you think we need independent Market for the Terra currencies each? (LUNA/KRW, LUNA/USD, LUNA/SDR) Or just using LUNA/SDR market as a main market and use the exchange rate for other Terra currency swaps?
  2. Assuming that Terra pool(virtual) is at the equilibrium. If someone makes Huge swap in one direction(1million SDR to Luna for this example), the spread for the other direction gets extra liquidity for 1million SDT. What it means is that for the next Luna to SDR swaps, the spread pegs to 2% until the Terra pool reaches the equilibrium. If you intended this, can you tell me the rationale for this design?

Yeah. Also curious on:

  1. How often the invariant is reset (“The size of the Luna pool is initialized to offer a Terra price at the peg”) --> given Terra price shifts when is the constant product updated?

  2. As @RA.Terra mentions how this dynamic plays out with multiple Terra currencies?

Great questions gentlemen. @Jkim I think your description is apt, minus the precise numbers – neither I nor I think @dokwon are set on any specific numbers. I am simulating various options and will share results so we can discuss what makes most sense.

A general argument before diving into specifics: I think about a flexible spread as a necessary evil. It is an evil becomes it directly impedes on the peg – the higher the spread on either direction, the wider the band the system is defending. Looked at differently, the larger the spread, the higher the cost of either expanding or contracting the economy. This places an effective cap on the rate at which the economy can robustly grow or shrink – by robustly I mean without the band growing too large. It is necessary because it protects the system from violent moves in either direction that it may not be able to safely absorb. This feature is particularly crucial in contractions: the increasing spread protects Luna holders, and therefore “collateral”, at the expense of Terra holders. This can be seen as the choice between two evils – loosening the peg temporarily vs defending on par and risking irreversible collapse. To charge a spread is to choose the former. Something to keep in mind is that real-world systems are highly non-linear – the effects of 24h Luna supply growth from 9% to 10% are impossible to predict, and may be exponentially more severe than growth from 0% to 1%. Circuit-breakers implemented by most traditional markets are a simple example of guarding against this phenomenon – to limit panic selling, prevent mass margin calls and so on. The justification for an asymptotically increasing spread is to minimize the probability of such non-linear effects.

Onto specifics – @Jkim can you clarify what you mean by “optics” here? Do you mean come up with a better story to justify the expansion cost?

@RA.Terra 1 is an apt question. Amongst the two options you suggest – the former being maintaining independent markets for each Terra currency, the latter being maintaining a single “global” market – I think the second is simpler and more robust. We could define the Terra liquidity pool using the mothership currency (SDT), and facilitate all other Terra/Luna swaps by first atomically converting to SDT (at zero fee of course). Since the liquidity pool is “virtual” the choice of Terra currency is in fact irrelevant. What the pool is supposed to capture is the total amount of Terra liquidity made available – in whatever sub-currency the market demands. The current mechanism actually works the same way, in the sense that all Terra currencies are subject to the same spread. The difference is that currently we define the spread in terms of Luna supply change, while I am proposing we do so in terms of Terra supply change. “Which Terra” is not well defined – all of them.

I think question 2 is mostly answered by my earlier argument. A spread in either direction is by default an “evil”, but we need it when there is a rapid trade imbalance. Therefore in your example we charge a significant spread on the large single-direction trade. Trades in the opposite direction do not create further liquidity imbalance – in fact they are reversing the imbalance created by the earlier trade. Therefore there is no reason to charge a spread above the minimum, until they create the opposite imbalance.

@dokwon if I understand your question correctly, the constant-product never changes. It is the price of Terra that changes in accordance with changes in the size of the Terra pool – Terra becomes more expensive as the pool shrinks, and cheaper as the pool grows. The pool reverts to equilibrium size – and therefore Terra price reverts to the peg – as liquidity is added/removed. If we want to make available 1% of Terra’s supply into the pool every 24h, then we inject/eject Terra liquidity at a rate of (1% of Terra supply) / (blocks per 24h) every block. In at most 24h of no trading the price of Terra is guaranteed to revert to the peg.

@Jkim i think the periodic caps on swaps are absolutely necessary to prevent catastrophic attacks agains the system in the case the oracle is manipulated or broken. For example, another stablecoin project temporarily lost more than $37 million when the KRW oracle was temporarily manipulated: .

@dokwon I certainly agree.

At the same time, it is important to think beyond just protecting against swap manipulators; my points above were to shed light on a latent side effect of spreads: any future growth in the Terra economy costs a minimum 2%. @nplatias reiterated my points above that, given this is the only way for Terra to be minted (and burned), it is the source of growth (and contraction) in the Terra economy. On the positive side, it should protect the system from violent moves in either direction. On the negative side, on a practical level 2% is quite an expensive “future of money,” and I wonder how this might inhibit our growth story, given the Terra project’s emphasis on discounted growth vs costly growth.

I am reluctant to accept this as simply a necessary evil, but alas, I have no better ideas.

The Terra pool needs to be calculated with precision to sufficiently allow for growth of the economy (important metric to Luna holders ;)) while maintaining the safety mechanics we have discussed here. I think @nplatias already brought this up, and I’m sure you guys will make the right calculation on that.

@nplatias with regards to optics, since seigniorage is such an emphasized part of this project:
I’m wondering how seigniorage, defined as profits from issuance of Terra, is affected when Terra issuance costs at minimum 2%? I’m not sure how this process works, so looking for clarity. On the surface it looks like the Terra Foundation might simply be issuing already-minted Terra to dApps like Chai, something the global crypto community might not be too fond of ;).

@Jkim I think you make a valid point – Terra is committed to frictionless finance, so a minimum 2% fee for buying Terra is a lot. What do you think is a reasonable minimum? The need for capping expansion and contraction via a marginally increasing spread – what I called a “necessary evil” – is separate from this. We want the system to permit low-cost growth at a strong pace, while at the same time restricting violent moves and protecting against manipulation.

Something to keep in mind is that the spread Terra buyers pay (say 2%) is technically part of seigniorage – money earned by the system – therefore it is not “lost”. Part goes to dApps, part rewards validators. Nonetheless, it does act as a disincentive for expansion, which may ultimately lead to less seigniorage overall. We want to avoid this while keeping risk of attacks low.

  1. Increasing spread

I don’t think this is separate–if you assume no one will ever actually purchase Terra through the system when the spread increases significantly, then this essentially this caps the amount of Terra that will be issued over time. For example, based on your paper a .07% increase in the Terra pool implies a spread of over 10%. Since we can safely assume no one will ever purchase Terra with a 10% spread, we can also assume the Terra economy will never grow even close to .07% of the Terra pool in a day.

  1. Minimum spread

From a purely competitive sense, benchmarking against crypto onramps/stablecoins, it should be moving to zero; personally, .25% is probably the maximum I would define as reasonable. It’s hard because it is a system-endogenous fee. Especially from a protocol perspective, I imagine a high minimum spread seriously hurting the growth of builders on top of the Terra protocol.

  1. Seigniorage

In the OP for this thread, isn’t the proposal to burn spread fees?

Recall that in the proposed implementation there are two components to the spread: (1) the minimum spread, and (2) the implied spread based on the constant-product rule. This is what I mean when I call them separate. (1) is the threshold cost for any expansion/contraction. (2) is a marginal cost, which increases the larger the net expansion/contraction. (2) is more critical for restricting violent moves and preventing manipulation, hence I think there is room to make (1) lower. There is no question that a marginal spread imposes an effective cap on growth rate, and I think that is a necessary evil. Unimpeded expansion/contraction is a serious stability risk as I argued earlier (putting manipulation aside). This is not a black-and-white problem, we need to determine a cap that permits strong growth while protecting stability of the system.

Makes sense, we’ll simulate this. The minimum spread defines the arbitrage threshold between chain and exchanges – this is the most significant tradeoff IMO. If we can stomach the occasional arbitrage, or better yet encourage the informed market participant like yourself to capitalize, this may not be a problem.

Spread fees will be burnt – that is seigniorage. Seigniorage is simply the Luna earned in exchange for Terra issued. The “spread fee” is included in this. Say that 1 Luna is worth 10 Terra and the spread is 1%, then to buy 1 Terra I swap in 0.101 Luna. The 0.001 Luna spread is burnt. The remaining 0.1 Luna will be split between the Treasury and validator rewards. Burning is an alternate form of “dividend”, albeit rewarding all Luna holders (not just validators).

Agreed here, determining the appropriate cap is the key.

Gotcha! Didn’t know.

Moving on to the multi currency peg discussion:

We can’t define the Terra pool using SDT when we have no true price discovery mechanism for the SDR-Luna pair. Luna-KRT works because a free market is determining the Luna-KRW price. Luna will never trade against the SDR on open markets, so the only way you would determine price is by using artificial exchange rates.

Let me try to explain why this would be a faulty system:

Say a currency trader comes in and uses the system to trade SDT and KRT with zero fees. The exchange rate fluctuates up then down 10% 10 times throughout the year. At year end the exchange rate is the same as before these fluctuations, but the trader traded these currencies perfectly and made 10% on 10 trades, resulting in X profits. All the profits here come simply in the form of X Terra being printed. Terra is essentially a derivative of Luna, so via dilution this hurts Luna holders.

In other words, no free market=no price discovery and no way to hedge against system-exogenous exchange rate fluctuations.

Well, the Volatility of Forex market in quite low. But, as you mentioned, traders can make profit by using our zero-fee Forex market. So, We are currently working on Tobin tax for the on-chain forex swaps. Tobin tax can be a good hedge for system-exogenous fluctuations.

This statement^ attempts to defend flawed system mechanics by suggesting your personal definition of a “quite low” amount of unhedged volatility (and the resulting Luna dilution) should be tolerable for Luna investors. I believe zero unhedged volatility is acceptable, and the Terra system has a fiduciary responsibility to guarantee this.

On top of that I would argue forex volatility is not low in the context of the Terra system. The SDR to KRW rate has fluctuated between 1553 and 1685 in the past year; USD to KRW between 1107 and 1223…

Can you explain more about this Tobin tax? This would appear to be in direct contrast to what @nplatias just said about zero fee swaps, but would like to hear more specifics as to how it would work!

I agree that we ideally want (and should eventually pursue) Luna trading vs SDT. A couple of things to note though:
(1) Assuming we permit trading of all Terras vs Luna, how we “define” the Terra pool is in fact arbitrary. The size of the Terra pool merely determines the aggregate cap on minting/burning of all Terras in any 24h, whichever Terra people want to swap. So the denomination here is arbitrary – KRT works just as well. Rationale for SDT is that it is supposed to be the “default Terra”.
(2) The problem you raise – Luna/SDT swaps being based on the exogenous KRW/SDR pair – is just as much a problem in the current system, or any system that supports Luna/SDT swaps based on a Luna/KRW market for that matter.

This indeed feels problematic – though to be clear this is not risk-free profit, the trader could have well lost 10% on all trades, meaning that Terra would have been burnt, benefiting everyone. That said, you are exposing an emergent consequence of permitting cross-Terra swaps whereby forex fluctuations can alter Terra or Luna supply independent of Terra’s stability. I wonder if this is an inevitable consequence of cross-Terra swaps. The system by its very design allows people to trade forex via swaps.

How does an independent Luna/SDR or Luna/USD market fix the problem that traders can profit (with risk) from forex fluctuations? What do you mean by “hedge” in this context?

We plan on introducing a Tobin tax on cross-Terra swaps to prevent funny behavior and more realistically mimic traditional forex trading. This is separate from the Terra/Luna swaps – in that case you are not gaining exposure to the underlying forex rates, so there is no reason to charge a fee. Does this make sense?

I don’t think Luna-Terra trading pairs really hold much meaning for the system.

I guess it doesn’t hedge against fluctuations, it just gives you true market pricing for Luna in each currency, which will give you the true exchange rates (as opposed to the direct fiat to fiat exchange rates, which don’t apply to crypto markets).

Risk-free to the trader or not, the system should be agnostic to the quality of the trader and remain fully hedged in the face of any system-exogenous rate fluctuations. This is why I pointed out back in May that the current system is flawed because it is always either winning or losing, when it should always be neutral.

Yeah, I would say even more generally, a consequence of a multi-currency Terra. Let me try to flesh out my thoughts and opinions on this:

First, I don’t think we need to support swaps at a system/protocol level. Foreign currency exposure can easily be built on top of crypto at the application layer.

Second, to me this idea of using the SDR as the mothership currency is, frankly, quite academic. No one uses the SDR, the average consumer has no clue even what the SDR is, no one trades with the SDR. MakerDAO realized this (probably along with the fact that there is no liquid SDR<>ETH market to supply oracle price feeds), which is why they switched to use the much more easily understood and widely used global currency: the US dollar.

The more I think about it, the more difficult it appears to support multiple Terra currencies, given the fluctuating nature of exchange rates and how the system is built to mint and burn to compensate price fluctuations. Minting and burning are supposed to compensate for expansions and contractions of the economy, not forex fluctuations.

Furthermore, I fear oracle incentives might be perverse: stakers are incentivized to vote rates that devalue the relative price of the most heavily issued Terra currency at any moment in time to prevent swaps from inflating their Luna holdings. This surely holds ramifications for Terra’s expansion beyond Korea…
(Edit: I suppose this^ would only happen in the case where there is no independent Luna<>fiat trading pair for an issued Terra currency.)

What do you guys think?

Good points @Jkim.

I agree that an ideal design satisfies this. Question is – how do we achieve this in a multi-Terra system?

Yes – assuming that each Terra can be swapped against Luna which is by design.

Can you elaborate? The need for local Terras in terms of adoption is obvious – if I’m a TMON user I do not want exposure to forex risk (unless I opt in). How do we achieve this with a single protocol-level Terra?

Pegging to the SDR is certainly more ambitious than pegging to USD. The days of the dollar as reigning currency are limited, much like for all reserve currencies that came before it. The idea of a “currency basket” is not new, and I think the pitch “more stable than your favorite currency” can work for the average consumer. Libra’s choice to peg to something along those lines vs the USD confirms the thesis. Fundamentally, the bet is that currency baskets as a concept can get adoption (to be confirmed). The fact that BTC does not trade against SDR is not the point here – it never will, though it may trade against SDT, Libra and so on.

Proposed implementation of the constant-product swaps algorithm in python here.

Yeah, good question. Not sure, really. I suppose imposing uniswap mechanics to cross-Terra swaps could smooth out volatility here, or only defending individual Terra pegs with the Luna-Terra uniswap mechanism and allowing Terras to simply trade against each other on the free market.

Would have to think about this one some more.

So my point here was isolated to a forex exposure/swap feature: if people wanted to hold their wealth in different national currencies without forfeiting custody of their funds (crypto-style), this type of functionality can be (and already is being) built in at the application layer by utilizing global crypto liquidity to facilitate transfers. The mechanisms behind such products are somewhat complex and not directly relevant to this discussion, so will save a deeper dive for another time.

Most definitely. I agree with the ethos of using a basket vs a singular currency for a peg, but practically speaking I do not believe everyday people understand it, which just means there are tradeoffs to being (what I would call) an academically sound currency vs. a widely understood and easily used currency. MakerDAO went through this and decided the tradeoff wasn’t worth it, and that a USD peg would be best for garnering more widespread adoption. They do, of course, have the optionality built into their governance structure to change this in the future if they wish.

Agreed that “more stable than your favorite currency” is a great pitch, but if the USD is your reference point then the USD is always more stable (pardon my oozing patriotism).

Those are my two cents on the choice to use an SDR peg :). I think this is mostly a philosophical discussion, and we first need to figure out how to make a multi-Terra system work.

You bring up a very important discussion with your Libra reference.

Libra pegs to a basket of “low volatility” assets that they hold in a reserve. As a result, all Libra volatility is hedged because the association directly holds the underlying assets (hopefully :wink:), creating a direct, fully liquid market for issuance and redemption at a 1:1 rate.

For Terra, we are relying on a high volatility asset in Luna along with oracle voting to provide a similar issuance and redemption market. If we don’t have an independent Luna-SDR market, how do we know what the price of Luna is in terms of SDR? Who decides that rate, and what are the incentives for oracle voters to use that artificial rate? IMO this becomes quite the ambiguous voting scheme, as there is nothing really defining and defending an SDR peg. And, as mentioned above, I am concerned about voter incentives here…

Defending Terra pegs without facilitating cross-Terra swaps is not a good option in my opinion – the ability to swap between Terras is a key value proposition. I think that the tension here can be summarized as follows: we want to facilitate low-friction cross-currency transfers, while at the same time minimizing exposure to system-exogenous volatility. This is a significant open problem that deserves separate discussion – let’s move it here.

Recalling your original point:

Are you referring to decentralized derivatives ala dydx here? It certainly is possible – in theory – to buy or sell whatever risk you want decentralized-ly. That assumes you’ll find the necessary liquidity – biggest problem with DeFi at the moment. More pertinently though, I don’t think this solves our use case, which is for the Vietnamese worker in Korea to cheaply convert TerraKRW to TerraVND and send back to her family. A decentralized KRW/VND futures contract surely ain’t gonna help her much, right?

Yes – primary objective is a sound multi-currency Terra design. “Mothership currency” is nothing more than a narrative actually – the protocol does not favor SDT over the rest in any meaningful way right now. The suggestion to use SDT when defining the liquidity pool is largely arbitrary as I pointed out – it’s just the denomination for “global terra market cap”. A multi-currency design creates currency competition, so at the end of the day the SDT vs UST verdict is up to the market.

Libra volatility is not fully hedged. First off, Libra didn’t give us a benchmark – volatility against what? Sounds like a currency basket but not clear. I think that Libra is pretty much a tokenized MMF without the interest, hoping that it can function as a loose currency peg. Go back to 2008 to recall why MMFs do not work well as currency pegs – the Reserve Fund broke the buck when the “low volatility” Lehman paper it was holding went bust in a day. Were it not for the Fed, investors would have suffered serious losses. The point is that Libra’s “low volatility” assets cannot guarantee 100% redemption against their peg unless the Fed is ready to step in. To be fair, this is no less a risk with Terra insofar as we hold less than 100% cash reserves. The stability mechanism + fiat reserve have been designed to minimize this risk.

As designed, in absence of an actual Luna/SDR market the rate is determined by say Luna/KRW and KRW/SDR. This is not ideal. Can you explain where you think redemptions break though? If there are liquid markets for both Luna/KRW and KRW/SDR, where does the following redemption process break: SDT --> Luna --> KRW --> SDR. I can see more fees and slightly higher volatility as risks.

Robust voter incentives in decentralized oracles is, in all honesty, very much an open problem. Marco from our team is doing some mechanism design research where the goal is a mechanism whose dominant strategy is truthful voting. The VCG mechanism is an excellent result from auction theory with that property.
Addressing your specific concern about devalued voting: I think that a constant-product mechanism similar to the one I proposed applied to cross-Terra swaps can alleviate this. The objective is to make speculation expensive and our system strictly inferior to traditional forex platforms for non-trivial trade sizes.