Oracle Revamp Proposal for Columbus-3

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.


  • 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%.


  • 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%.
1 Like

@nplatias @EuiJoon_Lee letโ€™s discuss

์ €๋Š” ๋ฃจ๋‚˜์˜ supply๋งŒ ์Šคํ”„๋ ˆ๋“œ factor์— ๋„ฃ์œผ๋ฉด ๊ฒฐ๊ตญ์—๋Š”
์Šคํ”„๋ ˆ๋“œ๋ฅผ ์ฆ๊ฐ€์‹œํ‚ค์ง€ ์•Š์œผ๋ฉด์„œ ์ฐจ์ต๊ฑฐ๋ž˜๋ฅผ ํ•  ์ˆ˜ ์žˆ๋‹ค๊ณ  ์ƒ๊ฐํ•ฉ๋‹ˆ๋‹ค.

๊ธฐ๋ณธ์ ์œผ๋กœ ํ…Œ๋ผ์˜ supply๊ฐ€ ๋ฃจ๋‚˜์˜ supply์™€ ์—ฐ๊ด€์ด ๋˜์–ด์•ผํ•˜์ง€๋งŒ, ์Šค์™‘ ์•„๋น„ํŠธ๋ผ์ง€๋Š” ๊ทธ๋ ‡์ง€ ์•Š์Šต๋‹ˆ๋‹ค.
ํ…Œ๋ผ์˜ supply๋งŒ ์ฆ๊ฐ€์‹œํ‚ค๊ฑฐ๋‚˜, ๋ฃจ๋‚˜์˜ supply๋งŒ ์ฆ๊ฐ€์‹œํ‚ฌ ์ˆ˜ ์žˆ์Šต๋‹ˆ๋‹ค.

๊ธฐ๋ณธ ์ „์ œ : ๋ฃจ๋‚˜์˜ supply change์— ๋”ฐ๋ผ, ๋‹จ์ผ ๋ฐฉํ–ฅ์œผ๋กœ ๋ฃจ๋‚˜์˜ ์–‘์ด ๋ณ€ํ•˜๋ฉด ์Šคํ”„๋ ˆ๋“œ๊ฐ€ ์ง€์†์ ์œผ๋กœ ์ƒ์Šนํ•˜๋Š” ๊ตฌ์กฐ์ž…๋‹ˆ๋‹ค.
๋ชจ๋‘ ๋ฃจ๋‚˜ <> ํ…Œ๋ผ ์–‘๋ฐฉํ–ฅ ์Šค์™‘์„ ํ†ตํ•œ ์ฐจ์ต๊ฑฐ๋ž˜๋ฅผ ํ•œ๋‹ค๋Š” ๊ฐ€์ •ํ•˜์— ์ž‘์„ฑ๋˜์—ˆ์Šต๋‹ˆ๋‹ค. ์–‘๋ฐฉํ–ฅ ์Šค์™‘์„ ์ง„ํ–‰ํ•  ๋•Œ ํ…Œ๋ผ๋ฅผ ๋ฃจ๋‚˜๋กœ ์Šค์™‘, ๋ฃจ๋‚˜๋ฅผ ํ…Œ๋ผ๋กœ ์Šค์™‘ํ•˜๋Š” ๊ฒฝ์šฐ ์ตœ์ข…์ ์œผ๋กœ ํ…Œ๋ผ๋กœ ์ˆ˜์ต์„ ๋ด„. ๋ฃจ๋‚˜๋ฅผ ํ…Œ๋ผ๋กœ ์Šค์™‘, ํ…Œ๋ผ๋ฅผ ๋ฃจ๋‚˜๋กœ ๋‹ค์‹œ ์Šค์™‘ํ•˜๋Š” ๊ฒฝ์šฐ ์ตœ์ข…์ ์œผ๋กœ ๋ฃจ๋‚˜๋กœ ์ˆ˜์ต์„ ๋ด„.

๋‘๊ฐ€์ง€ ๊ฒฝ์šฐ๋กœ ๋‚˜๋ˆ ๋ณด๊ฒ ์Šต๋‹ˆ๋‹ค.

  1. ํ˜„์žฌ ์ƒํ™ฉ

์•„๋น„ํŠธ๋ผ์ง€๊ฐ€ ๊ฐ€๋Šฅํ•œ ์กฐ๊ฑด์„ ๋งŒ๋“ค์—ˆ๋‹ค๊ณ  ๊ฐ€์ •ํ•˜๊ณ 
ํ…Œ๋ผ๋กœ ์‹œ์ž‘ํ•˜์—ฌ ํ…Œ๋ผ๋ฅผ ์ฆ๊ฐ€์‹œํ‚ค๋Š”(์ˆ˜์ต์„ ๋ณด๋Š”) ๋ฐฉํ–ฅ์œผ๋กœ ์•„๋น„ํŠธ๋ผ์ง€๋ฅผ ํ•œ๋‹ค๋ฉด, fee ๋ฅผ ๋‚ด๋”๋ผ๋„ ์ด์ต์ด๊ธฐ ๋•Œ๋ฌธ์—
ํ…Œ๋ผ์˜ ๊ฐฏ์ˆ˜๊ฐ€ ์ฆ๊ฐ€ํ•ฉ๋‹ˆ๋‹ค. ํ…Œ๋ผ์˜ ๋ฐœํ–‰๋Ÿ‰์ด ์ฐจ์ต๋ถ„ + fee ๋งŒํผ ์ฆ๊ฐ€ํ•ฉ๋‹ˆ๋‹ค.
fee๋Š” ๊ฐ€๊ฒฉ๋ณดํŒ…ํ•œ ๋ฐธ๋ฆฌํ•œํ…Œ ๊ฐ€๊ณ , ์ฐจ์ต๋ถ„์€ ๋ณธ์ธ์—๊ฒŒ.
ํ…Œ๋ผ ๋ฐœํ–‰๋Ÿ‰์ด ๊ธ‰๊ฒฉํžˆ ์ฆ๊ฐ€ํ•˜์ง€๋งŒ, ์Šคํ”„๋ ˆ๋“œ์— ์˜ํ–ฅ์€ ์—†์Šต๋‹ˆ๋‹ค.
์ด๋ฅผ ์—ฌ๋Ÿฌ๋ฒˆ ๋ฐ˜๋ณตํ•ด๋„ ์Šคํ”„๋ ˆ๋“œ๊ฐ€ ์ง€์†์ ์œผ๋กœ ์ฆ๊ฐ€ํ•˜์ง€ ์•Š์•˜์Šต๋‹ˆ๋‹ค.
ํ…Œ๋ผ์˜ ๋ฐœํ–‰๋Ÿ‰๋งŒ ์ฆ๊ฐ€ํ•˜๋Š” ๊ตฌ์กฐ์ด๊ธฐ ๋•Œ๋ฌธ์ž…๋‹ˆ๋‹ค.

๋ฃจ๋‚˜๋กœ ์‹œ์ž‘ํ•˜์—ฌ ๋ฃจ๋‚˜๋ฅผ ์ฆ๊ฐ€์‹œํ‚ค๋Š”(์ˆ˜์ต์„ ๋ณด๋Š”) ๋ฐฉํ–ฅ์œผ๋กœ ์•„๋น„ํŠธ๋ผ์ง€๋ฅผ ํ•œ๋‹ค๋ฉด, fee๋Š” ์†Œ๊ฐ๋˜์ง€ ์•Š์•˜๊ธฐ ๋•Œ๋ฌธ์—
๋ฃจ๋‚˜์˜ ๋ฐœํ–‰๋Ÿ‰์ด ์ฐจ์ต๋ถ„ + fee ๋งŒํผ ์ฆ๊ฐ€ํ•ฉ๋‹ˆ๋‹ค.
๋ฃจ๋‚˜ supply๊ฐ€ ๊ธ‰๊ฒฉํ•˜๊ฒŒ ์ฆ๊ฐ€ํ•ฉ๋‹ˆ๋‹ค. ์Šคํ”„๋ ˆ๋“œ๋„ ๊ธ‰๊ฒฉํžˆ ์ฆ๊ฐ€ํ•ฉ๋‹ˆ๋‹ค.

  1. 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๋งŒ ๊ณ ๋ ค๋˜๋Š” ๋””์ž์ธ์ด ๋ณ€๊ฒฝ๋˜๋ฉด ์ข‹์„ ๊ฒƒ ๊ฐ™์Šต๋‹ˆ๋‹ค.

์•ˆ๋…•ํ•˜์„ธ์š” @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์˜ ์œ ๋™์„ฑ์„ ์กฐ์ ˆํ•˜์ž๋Š” ์ œ์•ˆ์ด ์žˆ์—ˆ์Šต๋‹ˆ๋‹ค.

๋‹ต๋ณ€์ด ๋˜์…จ๋Š”์ง€ ์ž˜ ๋ชจ๋ฅด๊ฒ ์Šต๋‹ˆ๋‹ค. ํ•ญ์ƒ ๊ด€์‹ฌ ๊ฐ€์ ธ์ฃผ์…”์„œ ๊ฐ์‚ฌํ•ฉ๋‹ˆ๋‹ค.

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

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

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์‹œ๊ฐ„ ๊ธฐ์ค€์œผ๋กœ ์Šค์™‘ ๊ฐ€๋Šฅํ•œ ์–‘ ์ž์ฒด๋Š” ๋˜‘๊ฐ™์ง€๋งŒ ์ˆ˜์ˆ˜๋ฃŒ๋Š” ์ƒ๋Œ€์ ์œผ๋กœ ์ฆ๊ฐ€ํ•˜๋Š” ํšจ๊ณผ๋ฅผ ๋ณผ ์ˆ˜ ์žˆ๋‹ค๊ณ  ์ƒ๊ฐํ•ฉ๋‹ˆ๋‹ค.

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

1 Like

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

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

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