Oracle Revamp Proposal for Columbus-3

[dokwon]

This proposal builds on this robustness analysis, a discussion on oracle reliability and a discussion on swap liquidity. We propose modification to 1) the existing oracle voting participation incentives and 2) the existing cost structure for market swap transactions.

1. Oracle voting incentives

Currently, validators choose to submit oracle votes every 1 minute, and validators voting within 2% of the elected median price get rewarded with spread fees from swaps coming in the next minute.

Problems:

• Incentives are uncertain. Although running an oracle takes similar effort to block validation (requires steady attention and honesty) the rewards are sporadic and unpredictable, which makes it difficult to invest time and resources to create an oracle.
• Market volatility (and infancy) hurts oracle voters, as many may not make it into the winning set even when they are voting honestly due to the volatility of sources
• The mechanism tends towards token inflation, as swaps tend to capturing arb, which inflates the number of tokens

Proposed modification:

• Slash low oracle availability: Validators that fail to submit honest (as defined in item 2) votes at least 5% of the last 1000 oracle votes get slashed.
• Make oracle honesty relative: Validators whose votes are within max(0.02, s) from the elected median, where s is the stddev of the vote prices are eligible to get rewarded .
• Burn spread fees: Instead of rewarding oracle participating validators with swap spread fees, burn it.
• Reward seigniorage to oracle winners instead of burning: Instead of burning epoch’s seigniorage * reward-weight , add it to an amortized reward pool where 1/100th of the pool is paid out as rewards to oracle ballot winners every VotePeriod

2. Swap trading incentives

Currently, the system charges a gradient swap spread fee (2-10%) increasing as the supply change of Luna approximates a DailyChangeCap. For example, if the DailyChangeCap is 0.1%, the spread fee for swapping Luna to Terra increases up to 10% as Luna daily supply change gets closer to -0.1%, and and spread fee for swapping Terra to Luna increases up to 10% as Luna daily supply change gets closer to +0.1%.

Problems:

• The stability mechanism is powerless when the DailyChangeCap is hit. We need a way to facilitate swaps even if the cost of doing so is high.
• If an attacker can manipulate one or more of Luna’s markets more than the effective spread (2-10%), he can capture an arbitrage gain even if Terra is trading at the peg (this).

Proposed modification (borrowing from Uniswap’s book):

Let DailyChangeCap = l,
daily supply change of Luna be c,
TERRA/LUNA exchange rate r

• Swapping x Terra costs: max(0.02, (c + x / r) / l) in spread. Intuitively, the spread goes up from 2% to 100% as Luna inflation approximates the cap.
• Swapping y Luna costs: max(0.02, (c + y * r) / l) in spread. Intuitively, the spread goes up from 2% to 100% as Luna deflation approximates the cap.
• Luna supply change tracking resets every 24 hours.
• The DailyChangeCap should be set to something much higher than what it is currently (0.1%) to 2%.

[dokwon]

@nplatias @EuiJoon_Lee let’s discuss

[Terragogo]

저는 루나의 supply만 스프레드 factor에 넣으면 결국에는
스프레드를 증가시키지 않으면서 차익거래를 할 수 있다고 생각합니다.

기본적으로 테라의 supply가 루나의 supply와 연관이 되어야하지만, 스왑 아비트라지는 그렇지 않습니다.
테라의 supply만 증가시키거나, 루나의 supply만 증가시킬 수 있습니다.

기본 전제 : 루나의 supply change에 따라, 단일 방향으로 루나의 양이 변하면 스프레드가 지속적으로 상승하는 구조입니다.
모두 루나 <> 테라 양방향 스왑을 통한 차익거래를 한다는 가정하에 작성되었습니다. 양방향 스왑을 진행할 때 테라를 루나로 스왑, 루나를 테라로 스왑하는 경우 최종적으로 테라로 수익을 봄. 루나를 테라로 스왑, 테라를 루나로 다시 스왑하는 경우 최종적으로 루나로 수익을 봄.

두가지 경우로 나눠보겠습니다.

1. 현재 상황

아비트라지가 가능한 조건을 만들었다고 가정하고
테라로 시작하여 테라를 증가시키는(수익을 보는) 방향으로 아비트라지를 한다면, fee 를 내더라도 이익이기 때문에
테라의 갯수가 증가합니다. 테라의 발행량이 차익분 + fee 만큼 증가합니다.
fee는 가격보팅한 밸리한테 가고, 차익분은 본인에게.
테라 발행량이 급격히 증가하지만, 스프레드에 영향은 없습니다.
이를 여러번 반복해도 스프레드가 지속적으로 증가하지 않았습니다.
테라의 발행량만 증가하는 구조이기 때문입니다.

루나로 시작하여 루나를 증가시키는(수익을 보는) 방향으로 아비트라지를 한다면, fee는 소각되지 않았기 때문에
루나의 발행량이 차익분 + fee 만큼 증가합니다.
루나 supply가 급격하게 증가합니다. 스프레드도 급격히 증가합니다.

2. Burn spread fees: Instead of rewarding oracle participating validators with swap spread fees, burn it.
   위의 제안이 스왑에 반영된 상황

이 제안은 테라로 시작하여 테라를 증가시키는(수익을 보는) 방향으로 아비트라지를 하더라도,
swap fee 가 2. 제안에 의해 소각되기 때문에,
fee만큼의 루나가 줄어듭니다. 따라서 스프레드가 지속적으로 올라갑니다. 1. 에 비해선 천천히 올라갑니다.

그럼 루나로 시작하여 루나를 증가시키는(수익을 보는) 방향으로 아비트라지를 한다면 어떨까요?
루나를 벌어들이는 방향으로
아비트라지를 반복하면, 루나의 supply는 차익분 만큼 증가합니다. (fee만큼은 소각되기 때문에)
근데 여기서 벌어들인 차익분만큼의 루나를 다시 테라로 스왑하면,
루나의 supply는 증가하지 않습니다. 테라의 발행량이 차익분 *(1-spread) 만큼 증가합니다.
그럼 스프레드를 지속적으로 증가시키지 않고, 차익거래를 계속할 수 있습니다.
차익분에 대해 spread 만큼만 내면 되기 때문에 비용도 저렴합니다.

spread 를 2%~ 100% 까지 증가시켜도 루나 supply를 변화시키지 않으면서 소액으로 여러번 진행한다면,
2%보다 살짝큰 스프레드로 아비트라지를 지속적으로 할 수 있을 것입니다.

DailyChangeCap, daily supply change 에 루나 supply만 고려되는 디자인이 변경되면 좋을 것 같습니다.

[EJ_Lee]

안녕하세요 @Terragogo 님.
말씀하신 부분에 대해서 제 생각 이야기 해보겠습니다.

1. 현재 상황

테라를 증가시키는 방향으로 차익거래 진행시
루나를 테라로 swap하는 경우라고 할 수 있습니다.
이경우 루나의 supply는 감소하고 테라의 supply는 증가합니다.
차익거래자는 ‘루나’를 스프레드 수수료로 지급합니다.
따라서 루나의 supply는 swap된 루나만큼 감소합니다.(fee는 사라지지 않음)
테라의 발행량도 증가하고 루나의 supply도 -방향으로 변화합니다.
저희는 루나 공급량의 변화를 수수료 계산시 사용하고 있기 때문에
테라를 증가시키는 방향으로 차익거래가 진행되더라도
루나 공급량이 감소하여 루나 공급량의 변화가 생기기 때문에
스프레드는 선형적으로 증가합니다.

루나를 증가시키는 방향으로 차익거래 진행시
테라를 루나로 Swap하는 경우라고 할 수 있습니다.
이경우 테라의 supply는 감소하고 루나의 supply는 증가합니다.
차익거래자는 ‘테라’를 스프레드 수수료로 지급합니다.
따라서 루나의 supply는 swap된 루나만큼 증가합니다.(fee는 테라의 형태로 지급되기 때문에 무관)
테라의 발행량은 감소하고 루나의 supply도 +방향으로 변화합니다.
루나의 공급량이 증가하여 루나 공급량의 변화가 생기기 때문에
스프레드는 선형적으로 증가합니다.

요약 : 저희는 루나 공급량의 변화(+,- 둘다)를 스프레드 수수료 계산에 사용하고 있어서 테라를 증가시키는 방향으로 스왑을 계속 진행해도 수수료는 증가합니다.

2. 스프레드 수수료를 소각하는 경우

루나를 테라로 Swap시, 루나의 공급량은 감소하고 테라의 공급량은 증가합니다.
이때 이전에는 소각하지 않던 스프레드 수수료(루나)도 소각되기 때문에 루나의 공급량이 이전보다 더 빠르게 감소합니다.
따라서 1번 케이스보다 루나를 테라로 Swap하는 경우 수수료가 더 빠르게 증가합니다.

테라를 루나로 Swap시, 테라의 공급량은 감소하고 루나의 공급량은 증가합니다.
이때 이전에 소각하지 않던 스프레드 수수료를 소각(테라)하긴 하지만, 이는 루나 공급량 변화와 무관합니다.
따라서 테라를 루나로 Swap하는 경우에는 수수료는 이전과 똑같이 증가합니다.

따라서 단방향 스왑(루나 계속 테라로 바꾸거나, 테라를 계속 루나로 바꾸는 형태의 스왑)은 1,2번 케이스 모두에서 수수료를 계속 증가시킨다는 것을 알 수 있습니다.

현재 디자인은 우려하신 단방향 스왑보다 오히려 양방향 스왑에 더 취약합니다. 저희는 루나 공급량의 변화량을 스프레드 계산에 사용하고 있기 때문에, 비슷한 가치의 루나와 테라를 반복해서(테라를 루나로 스왑한 뒤 루나를 테라로 스왑) 스왑하는 경우 스왑을 반복해도 스프레드 수수료가 일정 범위 밖으로 벗어나지 않습니다. 이 취약점은 7/15 7/22일에 공격자에 의해서 차익거래에 이용된 바 있습니다.

스프레드 수수료 계산에 루나 supply만 고려되는 현재의 디자인이 허점이 있다는 것에는 동의합니다. 팀 내부에서 여러 제안이 있었고, 그중 거래소의 ‘테라’ 가격을 오라클로 불러와서 ‘테라’ 가격이 고정가격에서 얼마나 벗어나 있는지에 따라 on-chain market의 유동성을 조절하자는 제안이 있었습니다.

답변이 되셨는지 잘 모르겠습니다. 항상 관심 가져주셔서 감사합니다.

[nplatias]

@dokwon I agree with the motivation and problems you raise.

In terms of the proposed modifications:

1. I am in line with those modifications. The biggest win here is burning spread fees I think. The seigniorage modification of course means not exerting as tight control as we currently do over Luna’s supply. Freeing ourselves from burning seigniorage gives us the leeway to do more interesting things, such as paying part of it as direct rewards.
2. A uniswap-like model makes a lot of sense here – Marco wrote up a detailed survey of automated market makers including uniswap here. What if we applied the idea of “liquidity pools” more directly, rather than defining a custom equation ourselves? In particular, we could define “virtual” pools of Terra and Luna managed by the protocol and used to facilitate swaps. The size of the Luna pool, for instance, would be the remaining available Luna from the 24h supply cap. By constraining liquidity to the pools the protocol is guaranteeing the caps that we want, while at the same time mimicking the way uniswap adjusts price based on available liquidity. There are a few kinks to how this would apply in our case, I’ll be sharing a longer post with how this might work and we can discuss in more depth.

A few other considerations:

• Are you suggesting Luna supply change be reset every 24h, rather than being a trailing 24h sum?
• Should the spread perhaps grow unidirectionally instead of bidirectionally? By unidirectionally I mean: spread is at least 2% on both sides (say Luna bid and ask), if Luna supply is increasing, decrease Luna bid only (i.e. swapping in Luna costs more), if Luna supply is decreasing increase Luna ask only (i.e. swapping in Terra costs more).

[dokwon]

@nplatias don’t you think the equation above captures the constant product equation of Uniswap well? More concretely:

• Terra Market defines two pools, A and B, wherein A * B are held constant. If applied to our swaps, A = 1 million Luna, and B = 1 million Luna’s worth of Terra defined at the “rebalance point”, where the daily swap cap is set.
• Uniswap defines two pools, A and B, with A holding 1 million Luna and B holding some fixed quantity of Terra.

Seems to be the same for me. Do you have a more formal suggestion?

For the above reason, I think it may be preferable to reset the daily trading volume once a day instead of doing trailing 24 hr caps. If the rebalance is too frequent it prevents us from penalizing a “trailing attacker” looking to lower the spread over several trades as the spreads and the caps would keep getting updated.

Your suggestion regarding impacting spreads unidirectionally depending on which side of the swap is favored is a sound one, and I think we should incorporate.

[EJ_Lee]

1. Oracle voting incentives

루나 인플레이션을 통한 오라클 투표자 보상
시뇨리지 보상의 일부를 오라클 보상으로 지급하는 것 보다는, 인플레이션 보상(루나)을 오라클 보상으로 지급하는 것이 보상의 안정성 측면에서 나은 선택이라고 생각합니다. 또한 인플레이션 보상을 통해서 오라클 보상을 지급하는 것은 현재의 낮은 스테이킹 보상에 대한 해답도 될 수 있습니다.

현재 테라 네트워크의 스테이킹 수익은 너무 낮습니다. 일반적인 PoS 네트워크에서는 인플레이션을 통해서 초창기 스테이킹 수익은 낮더라도 네이티브 토큰으로 보상을 받기 때문에 검증인들은 네트워크에서 스테이킹 하지 않은 홀더들의 지분을 빼앗아 올 수 있습니다. 따라서 향후 네트워크 가치 상승으로 네이티브 토큰의 가치가 상승했을때 초기에 받은 스테이킹 보상의 가치도 상승하여 적자를 메꿀 수 있습니다.

코스모스 네트워크의 경우 스테이킹 비율에 따라서 연간 인플레이션 보상을 7%~20% 사이로 조절합니다. 스테이킹 비율이 증가할수록 연간 인플레이션 보상은 7%로 수렴하고, 스테이킹 비율이 66%를 초과하면 연간 인플레이션 보상은 7%로 고정됩니다. 연간 인플레이션 보상은 스테이킹된 아톰의 수량을 기준으로 하는것이 아닌 네트워크의 아톰 총 수량 기준이기 때문에, 스테이킹 비율에 따라서 연간 인플레이션 보상은 7%~20%이상으로 상승할 수 있습니다. 따라서 아톰의 미래 가치를 높게 평가하는 사람들은 초기에 아톰을 스테이킹할 유인이 충분합니다.

하지만 테라 블록체인의 대부분의 스테이킹 보상은 테라의 형태로 지급됩니다. 심지어 지금 스테이킹 보상의 경우 노드를 운영하기에는 터무니 없는 수준입니다.(3억원 50일간 위임했을때 35000원 정도) 또한 테라는 가치가 명목화폐에 고정되어 있기 때문에 향후 네트워크의 가치 상승이 초기에 받은 스테이킹 보상의 가치를 상승시키지 못합니다.

따라서 초창기 보상이 추후 네트워크 가치의 상승으로 보상받을 수 있는 형태의 보상이 필요합니다. 추가적으로 스테이킹 하지 않은 루나 홀더들에 대한 일종의 페널티가 필요합니다.

이에 대한 해답은 인플레이션 보상(루나)이라고 생각합니다.

1. 인플레이션 보상을 통해서 루나의 미래가치를 고평가하는 사람들에게 초창기 테라 생태계에서 스테이킹할 유인을 제공할 수 있습니다.
2. 스테이킹 하지 않은 사람들에게 지분 희석을 통한 패널티를 부여할 수 있습니다.
3. 인플레이션 보상을 오라클 보상으로 지급하는 것을 통해 검증인들은 현재의 불확실한 보상에 비해 훨씬 예측가능한 보상을 기대할 수 있습니다.

Availability가 낮은 검증인들을 슬래싱 하는 것과, 스프레드 수수료를 소각하는 것은 적극 찬성합니다.

적절한 인플레이션율을 설정하기 위한 고민은 좀 필요할 것 같습니다.
2%미만이 적절할 것 같습니다.

2. Swap trading incentives

max(0.02, ( c + x / r ) / l )
max(0.02, ( c + y * r ) / l ) 보다는

0.02 + ( c + x / r ) / l
0.02 +( c + y * r ) / l 가 나은 것 같습니다.

유니스왑 디자인에 대해서는

luna_liquidity_pool(Virtual) * krt_liquidity_pool(Virtual) = constant_product 를 공식이라고 가정하면

luna_liquidity_pool에 있는 루나 갯수를 고정시켜서 지금의 DailyChangeCap과 같은 기능을 하게 한 후, 매 Vote_period마다 Oracle_price를 불러와서 위 공식을 리벨런싱 시키는 방식으로 바꾸면 좋을 것 같습니다.

luna_liquidity_pool을 너무 크게 잡으면 하루에 스왑할 수 있는 양은 늘어나지만, 적은 양의 스왑에 대해서 Spread fee가 상대적으로 감소하는 단점이 있는데요, 이를 방지하기 위해서 luna_liquidity_pool의 규모를 줄인 후, 하루마다 리셋시켜주는 것이 아닌 12시간이나 8시간 마다 리셋시켜주는 것을 통해서 24시간 기준으로 스왑 가능한 양 자체는 똑같지만 수수료는 상대적으로 증가하는 효과를 볼 수 있다고 생각합니다.

[nplatias]

@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)

[Jkim]

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?

[EJ_Lee]

hould the spread perhaps grow unidirectionally instead of bidirectionally? By unidirectionally I mean: spread is at least 2% on both sides (say Luna bid and ask), if Luna supply is increasing, decrease Luna bid only (i.e. swapping in Luna costs more), if Luna supply is decreasing increase Luna ask only (i.e. swapping in Terra costs more

@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?

[dokwon]

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 @EJ_Lee mentions how this dynamic plays out with multiple Terra currencies?

[nplatias]

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?

@EJ_Lee 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.

[dokwon]

@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: https://www.theblockcrypto.com/tiny/synthetix-suffers-oracle-attack-potentially-looting-37-million-synthetic-ether/ .

[Jkim]

@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 ;).

[nplatias]

@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.

[Jkim]

1. Increasing spread

The need for capping expansion and contraction via a marginally increasing spread – what I called a “necessary evil” – is separate from this.

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.

2. Minimum spread

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?

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.

3. Seigniorage

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”.

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

[nplatias]

1. Increasing spread

nplatias:

The need for capping expansion and contraction via a marginally increasing spread – what I called a “necessary evil” – is separate from this.

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.

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.

2. Minimum spread

nplatias:

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?

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

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.

3. Seigniorage

nplatias:

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”.

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

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).

[Jkim]

This is not a black-and-white problem, we need to determine a cap that permits strong growth while protecting stability of the system.

Agreed here, determining the appropriate cap is the key.

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).

Gotcha! Didn’t know.

[Jkim]

Moving on to the multi currency peg discussion:

@EJ_Lee

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?

@nplatias

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).

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.

[EJ_Lee]

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.