12188 | Terra Classic Market Module 2.0 (เวอร์ชันที่ไม่ต้องปรับแต่ง)
แหล่งที่มาจาก :
- https://validator.info/terra-classic/governance/12188
- https://github.com/Market-Module-2-0/proposal/blob/main/proposal-nomint.md
Terra Classic Market-โมดูล 2.0
เวอร์ชัน No-Mint
เครื่องยนต์ ลดเงินฝืดสุทธิ ที่สามารถเปิดได้โดยไม่ต้องสร้างภาระมากเกินไป ลดความเร็วลงเมื่ออุปทานลดลง และไม่สามารถพิมพ์หลอกลวงผ่านราคาที่หยุดนิ่งได้
เนื้อหานี้อิงตามร่างต้นฉบับ “ Terra Classic Market-Module 2.0 ” แต่ได้รวมเอากลไกต่างๆ ไว้เพื่อหลีกเลี่ยงการสร้าง/การเผาไหม้ ซึ่งทำให้สมาชิกในชุมชนหลายคนเกิดความกังวล
หากคุณต้องการสรุปสั้นๆ ที่ไม่ใช่เชิงเทคนิค โปรดไปที่ภาคผนวก 1 (สรุป) และภาคผนวก 2 (คำถาม/คำตอบ)
1. บริบทและเป้าหมาย
ปี 2022 สอนบทเรียนอันยากลำบากสองประการ:
- ความสามารถในการฆ่าที่ไม่จำกัด – การเพิ่ม base_pool และการลดระยะเวลาการกู้คืนของ pool (PRP) ช่วยให้ผู้ซื้อขายสร้างเหรียญได้เร็วกว่าที่ตลาดดูดซับ ส่งผลให้ LUNC ถูกทำลาย
- การตรึงราคาไว้ที่ 1 ดอลลาร์นั้นเป็นอันตราย โดยการกำหนดมูลค่า UST ไว้ที่ 1 ดอลลาร์ในขณะที่ซื้อขายที่ 1 ดอลลาร์นั้นทำให้เกิดภาวะเงินเฟ้อรุนแรง
วันนี้ (25 มิถุนายน 2568) เราอยู่ที่ประมาณ 6.50 T LUNC และ 6 B USTC การเผาไหม้อยู่ที่ ประมาณ 1.3 B LUNC ต่อเดือน (0.02%) ชุมชนต้องการให้โมดูลตลาด (MM) กลับคืนโดยเร็วที่สุดเพื่อฟื้นฟูสาธารณูปโภคและค่าธรรมเนียม แต่จะยอมรับเฉพาะ การลดลงของอุปทานสุทธิอย่างต่อเนื่อง เท่านั้น
2. โมดูลตลาดสร้างขึ้นอย่างไรในอดีต
2.1 base_pool — “สำรอง SDR เสมือน”
เมื่อคุณสลับ USTC → LUNC (หรือกลับกัน) โมดูลจะแสร้งทำเป็นว่าคุณกำลังโต้ตอบกับพูล SDR เสมือน การคำนวณจริงประกอบด้วย:
- การแปลงจำนวน USTC เป็นค่า SDR โดยใช้ราคาออราเคิลปัจจุบัน
- การกำหนดว่าจะต้องสร้าง LUNC เท่าใดเพื่อให้เส้นโค้งผลคูณคงที่เสมือนยังคงสมดุล
- การอัปเดต “หนี้” SDR ที่สร้างขึ้นโดยการสวอป
พูดแบบง่ายๆ ก็คือ เมื่อคุณสลับ USTC → LUNC โมดูลจะทำหน้าที่เป็น SDR/LUNC AMM ซึ่งด้านหนึ่งเป็นกลุ่มเสมือนที่มีขนาด base_pool:
ΔLUNC_out ≈ ( SDR_spent / SDR_pool_after ) × LUNC_pool_before
base_pool ที่ใหญ่กว่าจะช่วยให้การสลับเพียงครั้งเดียวให้ LUNC มากขึ้นก่อนที่ราคาจะเปลี่ยนแปลง
2.2 PRP — ตัวจับเวลาการเติม
หลังจากการสลับ โมดูลจะจดจำค่า SDR deficit d (ปริมาณการใช้พูล SDR เสมือน) ในแต่ละบล็อก โมดูลจะ “เติม” เศษส่วนคงที่:
d_next = d_current × ( 1 − 1 / PRP )
แต่ละบล็อกจะฟื้นฟูส่วนที่ขาด 1/PRP ดังนั้น:
- PRP สั้น → เติมเร็ว → พิมพ์ซ้ำได้ภายในไม่กี่นาที
- PRP ยาว → เติมช้า → ต้องรอเป็นชั่วโมงหรือเป็นวัน
ความสามารถในการสวอปรวมต่อวัน (หากผู้ซื้อขายใช้จนหมดทุกครั้ง) อยู่ที่ประมาณ:
swap_cap_day ≈ 2 × base_pool / ( PRP / 14 400 )
(14,400 ≈ บล็อกต่อวันบน Terra Classic)
สูตรนี้ได้มาจากปริมาณ SDR ที่สามารถหมดลงและเติมใหม่ได้ในแต่ละวัน โดยยังคงสามารถสลับกันได้
3. แนวทางการไม่สร้างเหรียญ (ตามยุคสมัย)
ปัจจุบันภาษีการเผาบนเครือข่ายจะถูกแบ่ง 10% ให้กับ Community Pool, 10% ให้กับ Oracle Pool และ 80% สำหรับการเผา
เพื่อหลีกเลี่ยงการสร้างโทเค็น จึงมีข้อเสนอให้เปลี่ยนเส้นทาง 60% ไปยังกลุ่ม “สภาพคล่องโมดูลตลาด” ชั่วคราว แม้ว่าจะช่วยลดภาระการเผาเหรียญทันทีจากภาษีเหลือ 20% แต่ก็ยังคงเกิดการเผาเหรียญเพิ่มเติมทุกๆ 30 วัน (ดูรายละเอียดด้านล่าง)
ที่บล็อก H₀ แรกของทุก ๆ ยุค 30 วัน สำหรับแต่ละโทเค็นแยกกัน (USTC และ LUNC):
- โทเค็นแต่ละตัว (USTC และ LUNC) ที่เข้าถึงกลุ่มสภาพคล่องของโมดูลตลาด จะถูกย้ายไปยัง กลุ่มสวอปที่แยกต่างหาก สำหรับโมดูลตลาด นี่คือจำนวนโทเค็นที่ผู้ใช้จะสามารถแลกเปลี่ยนได้
- ซึ่งเทียบเท่ากับ 75% ของการเสียภาษีของเดือนที่แล้วของแต่ละโทเค็น
- แทนที่จะใช้การสร้างและการเผาเมื่อสลับผ่านโมดูลตลาด โทเค็นจะถูกนำจากและเพิ่มเข้าในกลุ่มนี้
- ในช่วงเริ่มต้นของยุค 30 วันถัดไป ส่วนที่เหลือทั้งหมดในสระจะถูกเผา
4. Adaptive base_pool & PRP สำหรับยุคนี้
เราต้องการการเติบโตแบบก้าวกระโดดเมื่อความผันผวนพุ่งสูงขึ้น แต่เรายังต้องไม่เกินวงเงินที่อนุญาตรายเดือน
4.1 เลือกปัจจัยการระเบิด
ค่าเริ่มต้น F = 0.07 → สามารถใช้ยอดคงเหลือในสระสภาพคล่องปัจจุบันได้มากที่สุด 10% ในหนึ่งวัน
desired_daily_cap = pool_balance × F
4.2 แก้ปัญหาสำหรับ base_pool
การจัดเรียงสูตรค่าสูงสุดรายวันใหม่:
base_pool_raw = desired_daily_cap × PRP / ( 2 × 14 400 )
4.3 PRP ตามขนาดอุปทาน
PRP = สูงสุด( 14 400 , 14 400 × ( S / 1 T ) )
6.5 T supply → PRP ≈ 93,600 blocks (6.5 วัน)
เมื่อปริมาณน้ำลดลง การเติมน้ำจะเร็วขึ้น—ก๊อกน้ำจะหดตัวลงเมื่อถังน้ำว่าง
4.4 แคลมป์สุดท้าย
base_pool = min(base_pool_raw, 0.00010 × supply_value_in_SDR, 5 000 000 SDR ) // หลังคาสัมบูรณ์
ตัวอย่างยุคแรก (ปัจจุบัน)
| รายการ | ค่า |
|---|---|
| ภาษี_30d (B₀) | 1.0 B ลันช์ |
| เปลี่ยนเส้นทางไปยังพูล = 0.6 × B₀ | 600M LUNC ≈ 24,400 SDR |
| PRP (อุปทาน 6.5 T) | 93 600 บล็อก |
| ที่ต้องการ_รายวัน_สูงสุด (เช่น F = 0.1) | 60M LUNC (ขึ้นอยู่กับยอดคงเหลือในปัจจุบัน) |
| ฐาน_พูล_ดิบ | ≈ 7.9 กิโลไบต์ SDR |
| base_pool หลังจากหนีบ | 7.9 กิโลไบต์ SDR |
| การใช้สระว่ายน้ำต่อวัน (สูงสุด) | 2 × 7.9 k / 6.5 µs 2.45 k SDR µs 60.4 M LUNC |
60.4 M > 60 M ดังนั้น F ไม่ใช่ที่หนีบ PRP จึงเป็นเบรกที่ทำงานอยู่
5. การป้อนราคาสดและการป้องกันการจัดการ
| ส่วนประกอบ | กฎ |
|---|---|
| ระยะเวลาโหวตราคา | 5 บล็อก ≈ 30 วินาที |
| ราคา USTC | price_uusd(USTC) = ค่ามัธยฐานถ่วงน้ำหนักอำนาจการลงคะแนนเสียงในช่วงเวลานี้ |
| การฆ่าโควรัมอัตโนมัติ | หากสินทรัพย์ใด ๆ มีการโหวตราคาตั้งแต่ < 50% VP เป็นเวลา 25 บล็อก → MM.enabled=false จนกว่าจะคืนโควรัม |
| TWAP แคลมป์สติสัมปชัญญะ | การสลับแต่ละครั้งจะล้มเหลวหากราคาที่ตรึงไว้แตกต่างกันมากกว่า 10% จาก Oracle-TWAP 45 บล็อก (ที่ป้อนโดยโอราเคิลเดียวกัน) |
| เส้นทางเสถียร→เสถียร | ปิดใช้งานแบบฮาร์ดในโค้ด (ErrStableSwapDisabled) |
6. เบรกและการควบคุมที่สมบูรณ์แบบ
- ⅔ super-majority สามารถปิด MM ได้ตลอดเวลา
7. แผลไฟไหม้
เมื่อสิ้นสุดระยะเวลา 30 วัน ส่วนที่เหลือทั้งหมดในพูลจะถูกเผา ขึ้นอยู่กับพฤติกรรมการสลับของผู้ใช้ ซึ่งอาจคล้ายกับการเผาที่อาจเกิดขึ้นได้หากไม่มีวิธีการนี้ หรืออาจเอนเอียงไปทางโทเค็นใดโทเค็นหนึ่งจากสองโทเค็นมากกว่า (ดูภาคผนวก 1 สรุป)
8. สถานการณ์
8.1 น่าเบื่อแต่ก็น่าเบื่อ (ผลตอบแทนจากยูทิลิตี้)
ตัวอย่างแสดงการคำนวณแยกกันสำหรับโทเค็นทั้งสอง:
LUNC ในสถานการณ์การเติบโตปกติ
- รายได้จากภาษีของ LUNC สูงถึง 2 พันล้านบาทต่อเดือนภายในยุคที่ 3 ส่วนรายได้จาก USTC สูงถึง 560,000 บาทต่อเดือน
- PRP ยังคงอยู่ > 3 วัน base_pool ถูกจำกัดโดยการอนุญาต
สถานการณ์ ก.) ผู้ใช้สลับไปมาระหว่าง LUNC และ USTC เท่าๆ กัน
| ยุค | ภาษี LUNC | ภาษี USTC | สระว่ายน้ำ LUNC ก่อน | สระว่ายน้ำ USTC ก่อน | สระว่ายน้ำ พักกลางวันหลัง | สระว่ายน้ำ USTC หลังจาก |
|---|---|---|---|---|---|---|
| 1 | 1.3 ข | 360 เค | 720 เมตร | 216 เค | 720 เมตร | 216 เค |
| 2 | 1.6 ข | 450 เค | 840 เมตร | 270 เค | 840 เมตร | 270 เค |
| 3 | 2.0 บี | 560 เค | 1.20 บาท | 336 เค | 1.20 บาท | 336 เค |
| ถูกเผา | 2.76 พันล้าน | 822 เค |
ในสถานการณ์นี้ จะมีการเผา LUNC และ USTC ในปริมาณเท่ากัน กับตอนที่ไม่ได้เปิด MM
สถานการณ์ ข.) ผู้ใช้สลับจาก USTC เป็น LUNC เป็นหลัก (80%) โดยกำหนดราคาเพื่อความเรียบง่ายคือ 200 LUNC/USTC (ในความเป็นจริง ราคาอาจมีการผันผวน)
| ยุค | ภาษี LUNC | ภาษี USTC | สระว่ายน้ำ LUNC ก่อน | สระว่ายน้ำ USTC ก่อน | สระว่ายน้ำ พักกลางวันหลัง | สระว่ายน้ำ USTC หลังจาก |
|---|---|---|---|---|---|---|
| 1 | 1.3 ข | 360 เค | 720 เมตร | 216 เค | 144 ล้าน | 3.1 ล้าน |
| 2 | 1.6 ข | 450 เค | 840 เมตร | 270 เค | 168 ล้าน | 3.63 ล้าน |
| 3 | 2.0 บี | 560 เค | 1.20 บาท | 336 เค | 240 เมตร | 5.14 ล้าน |
| ถูกเผา | 552 เมตร | 11.87 ล้าน |
ในสถานการณ์นี้ LUNC จะถูกเผาไหม้น้อยกว่า 2.2 B เมื่อเทียบกับตอนที่ไม่มี MM เปิดอยู่ ในทางกลับกัน USTC จะถูกเผาไหม้มากกว่า 11 M
สถานการณ์ c) ผู้ใช้สลับจาก LUNC เป็น USTC เป็นหลัก (80%) โดยกำหนดราคาเพื่อความเรียบง่ายคือ 200 LUNC/USTC (ในความเป็นจริง ราคาอาจมีการผันผวน)
| ยุค | ภาษี LUNC | ภาษี USTC | สระว่ายน้ำ LUNC ก่อน | สระว่ายน้ำ USTC ก่อน | สระว่ายน้ำ พักกลางวันหลัง | สระว่ายน้ำ USTC หลังจาก |
|---|---|---|---|---|---|---|
| 1 | 1.3 ข | 360 เค | 720 เมตร | 216 เค | 754.5 ล้าน | 43.2 กิโล |
| 2 | 1.6 ข | 450 เค | 840 เมตร | 270 เค | 882 เมตร | 54 เค |
| 3 | 2.0 บี | 560 เค | 1.20 บาท | 336 เค | 1.254 ข. | 67.2 กิโล |
| ถูกเผา | 2.89 บาท | 164.4 กิโล |
ในสถานการณ์นี้ LUNC จะถูกเผาไหม้มากกว่า 130 M เมื่อเทียบกับตอนที่ MM เปิดอยู่ ในทางกลับกัน USTC จะถูกเผาไหม้น้อยลง 660 K
8.2 Flash-crash และ Oracle หยุดทำงาน
- USTC ทิ้งไปที่ $0.004 (80 LUNC/USTC); ผู้ตรวจสอบชั้นนำ 2 รายออฟไลน์
- หลังจากครบ 30 วินาที โควต้า < 50% → MM จะปิด
- รายได้จากภาษีจะลดลงสำหรับโทเค็นทั้งสองในยุคถัดไป
LUNC ในสถานการณ์วิกฤต
- รายได้จากภาษีของ LUNC ลดลงเหลือ 0.2 พันล้านบาทต่อเดือน
- รายได้จากภาษีของ USTC ลดลงเหลือ 56,000 บาทต่อเดือน
สถานการณ์ ก.) ผู้ใช้สลับไปมาระหว่าง LUNC และ USTC เท่าๆ กัน
| ยุค | ภาษี LUNC | ภาษี USTC | สระว่ายน้ำ LUNC ก่อน | สระว่ายน้ำ USTC ก่อน | สระว่ายน้ำ พักกลางวันหลัง | สระว่ายน้ำ USTC หลังจาก |
|---|---|---|---|---|---|---|
| 1 | 0.2 บี | 56 เค | 120 ล้าน | 33.6 กิโล | 120 ล้าน | 33.6 กิโล |
| 2 | 0.2 บี* | 56 เค | 120 ล้าน | 33.6 กิโล | 120 ล้าน | 33.6 กิโล |
| 3 | 0.2 บี | 56 เค | 120 ล้าน | 33.6 กิโล | 120 ล้าน | 33.6 กิโล |
| ถูกเผา | 360 เมตร | 100.8 กิโล |
ในสถานการณ์นี้ จะมีการเผา LUNC และ USTC ในปริมาณเท่ากัน กับตอนที่ไม่ได้เปิด MM
(*) MM ถูกระงับกลางยุคนี้เนื่องจาก Oracle ขัดข้อง และไม่สามารถกลับมาดำเนินการต่อได้ ไม่มีการสลับระบบใดๆ เกิดขึ้นอีกนับจากจุดนั้นเป็นต้นไป
สถานการณ์ ข) ผู้ใช้สลับจาก USTC เป็น LUNC เป็นหลัก (80%) โดยราคาที่คาดไว้เพื่อความเรียบง่ายคือ 80 LUNC/USTC (ตามที่กำหนดในสถานการณ์การขัดข้อง)
| ยุค | ภาษี LUNC | ภาษี USTC | สระว่ายน้ำ LUNC ก่อน | สระว่ายน้ำ USTC ก่อน | สระว่ายน้ำ พักกลางวันหลัง | สระว่ายน้ำ USTC หลังจาก |
|---|---|---|---|---|---|---|
| 1 | 0.2 บี | 56 เค | 120 ล้าน | 33.6 กิโล | 24 ล้าน | 1.2 ล้าน |
| 2 | 0.2 บี* | 56 เค | 120 ล้าน | 33.6 กิโล | 48 ล้าน | 900 เมตร |
| 3 | 0.2 บี | 56 เค | 120 ล้าน | 33.6 กิโล | 120 ล้าน | 33.6 กิโล |
| ถูกเผา | 192 ล้าน | 2.13 ล้าน |
ในสถานการณ์นี้ LUNC จะถูกเผาไหม้น้อยลง 150 M เมื่อเทียบกับตอนที่ MM เปิดอยู่ ในทางกลับกัน USTC จะถูกเผาไหม้เพิ่มขึ้น 2 M
(*) MM ถูกระงับกลางยุคนี้เนื่องจาก Oracle ขัดข้อง และไม่สามารถกลับมาใช้งานได้อีก ไม่มีการสลับระบบใดๆ เกิดขึ้นอีกนับจากนี้
สถานการณ์ c) ผู้ใช้สลับจาก USTC เป็น LUNC เป็นหลัก (80%) โดยราคาที่คาดไว้เพื่อความเรียบง่ายคือ 80 LUNC/USTC (ตามที่กำหนดในสถานการณ์การขัดข้อง)
เราไม่ได้พูดถึงสถานการณ์นี้ เนื่องจากไม่น่าจะเป็นไปได้ที่ผู้คนจะเปลี่ยนจาก LUNC ไปเป็น USTC หากราคาของ USTC ตก
แม้จะเกิดภัยพิบัติ จำนวนลอยจะยังคงหดตัวลงสำหรับโทเค็นทั้งสองอย่างอิสระ
9. นโยบายค่าธรรมเนียมสเปรดสำหรับ MM Swap
| เงื่อนไข | ค่าธรรมเนียมที่ใช้ | หมายเหตุ |
|---|---|---|
| MM ปิดใช้งาน (ไม่มีการสลับ) | — | ไม่มีค่าธรรมเนียม ไม่ต้องเบิร์น เส้นทางเฉื่อย |
| MM เปิดใช้งานและอนุญาต > 0 | 0.35% ของมูลค่าโดยประมาณ | รวบรวมไว้ในสินทรัพย์เอาต์พุต (LUNC บน USTC→LUNC swaps, USTC บน LUNC→USTC) |
| ค่าเผื่อหมด (ถึงขีดจำกัดของยุค) | — | ปฏิเสธการแลกเปลี่ยน ไม่มีค่าธรรมเนียม ไม่มีการเผา |
เหตุผล
- ระดับที่เป็นไปได้ – 0.35% ถือว่าต่ำเพียงพอที่จะรักษากำไรจากการเก็งกำไรเมื่อเทียบกับสเปรด CEX ทั่วไป (≈ 0.10 – 0.25%) แต่ยังคงคืนต้นทุนของ Oracle และ keeper ได้
- ไม่ต้องเสียภาษีซ้ำซ้อน – ภาษีการเผาไหม้ 0.50% ทั่วทั้งเครือข่ายจะไม่ถูกนำไปใช้กับการสวอปภายในโมดูลเหล่านี้ ค่าธรรมเนียมสเปรดจะเข้ามาแทนที่
- การบัญชี – ค่าธรรมเนียมจะถูกโอน 50% ไปยังระบบเบิร์น และอีก 50% ไปยัง Oracle Pool
- เส้นทางจากเสถียรสู่เสถียร – ปิดใช้งานทั้งหมด (§ 4.4) ดังนั้นค่าธรรมเนียมจะใช้กับการซื้อขาย LUNC ↔ USTC เท่านั้น
10. ความเข้ากันได้ของโมดูล Oracle
การเปิดใช้งาน MM อีกครั้งด้วยการกำหนดราคาแบบไดนามิกต้องมีการอัปเดตโครงสร้างพื้นฐาน Oracle ปัจจุบัน:
- ฟีดราคา USTC – ต้องเพิ่ม USTC ลงในชุดโหวตของ Oracle ปัจจุบัน MM ถือว่าราคาคงที่ 1 ดอลลาร์ ตรรกะนี้ต้องถูกลบออกและแทนที่ด้วยอินพุตราคาแบบเรียลไทม์จากผู้ตรวจสอบ
- การขยายผู้ให้บริการฟีดเดอร์ – ฟีดเดอร์ที่มีอยู่รองรับแหล่งข้อมูลที่จำกัด เพื่อให้มั่นใจว่าราคามีความแม่นยำและป้องกันการบิดเบือน จำเป็นต้องรวมผู้ให้บริการข้อมูลเพิ่มเติม (เช่น CEX หลายรายการ ตัวรวบรวมข้อมูล) เข้าด้วยกัน
- การออนบอร์ดผู้ตรวจสอบ – ผู้ตรวจสอบทุกคนต้องได้รับคำแนะนำในการอัปเดตไบนารีและคอนฟิกของ Oracle Feeder เพื่อรองรับ USTC จำเป็นต้องมีเอกสารประกอบและการประสานงานการเปิดตัวเพื่อหลีกเลี่ยงการสูญเสียโควรัม
- (ทางเลือก) การยกเครื่องฟีดเดอร์ – ไม่จำเป็นต้องเขียนไบนารีฟีดเดอร์ใหม่ทั้งหมด แต่ขอแนะนำอย่างยิ่ง ฟีดเดอร์ปัจจุบันล้าสมัยและขาดการรองรับ API สมัยใหม่ ตรรกะสำรอง และการจัดการข้อผิดพลาดที่เหมาะสม
การเปลี่ยนแปลงเหล่านี้ต้องดำเนินการก่อนที่ MM จะเปิดอีกครั้ง หากไม่มีการเปลี่ยนแปลงเหล่านี้ การป้อนราคาจะไม่ถูกต้องหรือไม่มีข้อมูล ซึ่งจะทำให้ระบบปิดระบบอัตโนมัติ
11. แผนงาน
- การรวมโค้ดสำหรับการทดสอบเครือข่ายและการตรวจสอบ – โค้ดประมาณ 500-1,000 บรรทัด (ตรรกะของพูล, ปุ่มปรับแบบปรับได้, สวิตช์หยุดการทำงาน)
- เทสต์เน็ตสาธารณะ – ราคาพุ่งสูง, โควรัมลดลง, เบิร์นเบิร์สต์ 10 เท่า
- การอัพเกรดเมนเน็ต (สองขั้นตอน)
- โมดูลการใช้งานที่ไม่ได้ใช้งาน
- เปิดใช้งานที่ขอบเขตยุคถัดไปหลังจากเติมสระในช่วงยุคนั้น
- การชันสูตรพลิกศพ 90 วัน – เปลี่ยนเส้นทาง 60% หรือ F โดยการฮาร์ดฟอร์กเท่านั้น (การอัปเกรดเชน)
12. สิ่งที่เราได้รับ
- เปิดใหม่อีกครั้งทันที – ผู้ค้าสามารถเก็งกำไรได้ตั้งแต่วันแรก
- การรับประกันภาวะเงินฝืด – อุปทานจะต้องลดลงทุกๆ 30 วัน
- คันเร่งแบบยืดหยุ่น – เมื่ออุปทานหดตัว เติมช้าลง และแหล่งรวมหดตัวลง
- Oracle-safe – ความล่าช้า 30 วินาทีไม่สามารถขยายตัวได้; ความล่าช้า 75 วินาทีจะทำให้โมดูลหยุดทำงาน
- การเติมเงิน Oracle-Pool – ค่าธรรมเนียมสเปรดจากโมดูลตลาดจะถูกส่งต่อไปยัง Oracle Pool เพื่อรับผลตอบแทนในอนาคต (50%)
- เบิร์น – 50% ของค่าธรรมเนียมสเปรดจะถูกเบิร์น
13. แผลไฟไหม้โดยสมัครใจ
ณ จุดนี้ ส่วนใหญ่ของอุปทานที่ถูกเผาเกิดขึ้นจากการเผาโดยสมัครใจ (เหรียญที่ส่งไปยังโมดูลการเผาบนเชน – terra1…anxu)
ควรยกเว้นเงินทุนเหล่านี้จากการคำนวณการเบิร์น 30 วัน เพื่อหลีกเลี่ยงการสูญเสียการสนับสนุนการเบิร์นจากหน่วยงานต่างๆ เช่น Binance และสมาชิกชุมชน การทำเช่นนี้จะทำให้โทเค็นที่มีอยู่มีความเข้มงวดมากขึ้น ควรพิจารณาขยายพูลหากจำเป็น แต่จำเป็นต้องหารือกับหน่วยงานที่ได้รับผลกระทบเมื่อแนวคิดทั่วไปได้รับการนำไปใช้และทดสอบแล้ว
14. หมายเหตุสำคัญ
เราไม่สามารถคาดการณ์จำนวนเงินที่ต้องจ่ายภาษีในอีกไม่กี่เดือนข้างหน้าได้ ดังนั้นผลกระทบต่อแผน MM จึงขึ้นอยู่กับสมมติฐาน พารามิเตอร์และกลไกต่างๆ สามารถและควรได้รับการปรับเปลี่ยนในระหว่างขั้นตอนการทดสอบเครือข่ายสาธารณะ และสิ่งสำคัญคือต้องทดสอบผลกระทบและกลไกต่างๆ ที่มีต่อเครือข่ายทดสอบอย่างละเอียดถี่ถ้วนก่อนพิจารณาเปิดตัวเครือข่ายหลัก
นี่เป็นข้อเสนอส่งสัญญาณว่าฝ่ายกำกับดูแลและชุมชนต้องการให้แนวทางนี้ถูกนำไปปฏิบัติจริง การดำเนินการนี้จะเป็นความพยายาม/การสนับสนุนจาก StrathCole ดังนั้นจึงไม่มีกำหนดเวลาตายตัว ทางเลือกอื่นคือให้ทีมที่ได้รับค่าจ้างตัดสินใจยื่นข้อเสนองานและขออนุมัติจากฝ่ายกำกับดูแล ซึ่งอาจช่วยเร่งระยะเวลาการดำเนินการให้เร็วขึ้นในที่สุด
15. ความเสี่ยง
ความเสี่ยงของภาวะเงินเฟ้อรุนแรงสามารถบรรเทาได้ด้วยการใช้เฉพาะเงินทุนที่โอนไปยังกลุ่มแยกต่างหากจากรายได้ภาษีจากงวดก่อนหน้า ซึ่งทำให้ไม่สามารถผลิต MM ได้
ความเสี่ยงหลักของการใช้งานดังกล่าวมีดังนี้:
- ลดการไหม้ของ LUNC หรือ USTC (ไม่ใช่ทั้งสองอย่าง) ในกรณีที่ใช้การสลับกันน้อยมากและด้านเดียว
- ความผิดหวังของชุมชนต่อความคาดหวังที่ไม่เป็นจริง
ภาคผนวก 1: สรุปข้อมูลที่ไม่ใช่ด้านเทคนิค
หากจะสรุปแนวคิดในแง่ที่ไม่เชิงเทคนิค เราสามารถอธิบายได้ดังนี้:
สิ่งสำคัญ: นี่ไม่ใช่ข้อเสนอการ repeg และไม่ได้ปฏิบัติต่อ USTC เป็นสินทรัพย์ที่มีเสถียรภาพ
เราจะนำมาตรการป้องกันมาใช้กับโมดูลตลาด เพื่อไม่ให้เกิดการสับเปลี่ยนสกุลเงิน (Swap) เรายอมรับว่าสิ่งนี้แตกต่างจากแนวคิดดั้งเดิมของ MM 60% ของรายได้จากภาษีที่ถูกเผา (ไม่ใช่การเผาด้วยตนเองโดยกระเป๋าสตางค์) จะถูกโอนไปยังกลุ่มสวอปของ MM สำหรับงวดถัดไป
ราคาของ USTC จะถูกรายงานโดย Oracle ของเครือข่าย และจะไม่ถูกกำหนดไว้ที่ 1 ดอลลาร์อีกต่อไป วิธีนี้ช่วยให้สามารถแลกเปลี่ยนเป็นมูลค่าตลาดจริง โดยให้จำนวนเงินหรือ LUNC ที่ถูกต้องสำหรับ USTC และในทางกลับกัน
เมื่อสลับ USTC เป็น LUNC ระบบจะจัดสรร LUNC จากพูล MM และผู้ใช้จะจัดสรร USTC ให้กับพูลนั้นตามลำดับ เมื่อสลับ LUNC เป็น USTC ระบบจะจัดสรร USTC จากพูล และผู้ใช้จะจัดสรร LUNC กลับคืน นี่ไม่ใช่วิธีที่โมดูลตลาดทำงานในตอนแรก (mint และ burn) แต่ยังคงรักษาตรรกะในการคำนวณไว้ การเปลี่ยน minting จะถูกแทนที่ด้วยการใช้พูลที่เติมไว้ล่วงหน้า
ค่าธรรมเนียมการสวอปแต่ละครั้ง (ซึ่งไม่รวมภาษี แต่เป็นค่าธรรมเนียมสเปรด 0.35%) จะถูกกระจาย 50%:50 ระหว่างเบิร์นและ Oracle Pool
แรงจูงใจในการใช้ MM เพื่อแลกเปลี่ยนอาจเป็นตัวเลือกการเก็งกำไรระหว่างราคา CEX, ราคา DEX และ Market Module สาเหตุนี้เกิดขึ้นเนื่องจากราคาบนเครือข่ายของ Oracle มีการอัปเดตเพียงทุกๆ 30 วินาที ซึ่งหมายความว่าราคามักจะต่ำกว่าราคา CEX บ่อยครั้ง นอกจากนี้ ราคา DEX มักจะเบี่ยงเบนจากราคา CEX ซึ่งทำให้มีโอกาสเก็งกำไรเพิ่มขึ้น
ยิ่งไปกว่านั้น การใช้ MM เพื่อสลับอาจเป็นแรงจูงใจให้กับผู้ใช้ที่ต้องการทำให้เกิดการเผาไหม้ของฝ่ายใดฝ่ายหนึ่ง (ไม่ว่าจะเป็น LUNC หรือ USTC) ผ่านการสลับของพวกเขา (ดูกลไกเกี่ยวกับการเผาไหม้ของพูลรายเดือน)
ความเสี่ยงส่วนใหญ่ได้รับการบรรเทาด้วยมาตรการป้องกัน แต่ก็ยังมีความเสี่ยงที่ชุมชนจะผิดหวังหากคาดหวังว่ามาตรการเหล่านี้จะส่งผลเกินกว่าที่คาดการณ์ไว้ นอกจากนี้ อัตราการไหม้อาจต่ำกว่าที่คาดการณ์ไว้ ในกรณีที่ผู้ใช้ใช้ MM เพื่อเปลี่ยน USTC เป็น LUNC จนกว่าปริมาณการใช้จะหมดลง แต่การทำเช่นนี้จะส่งผลให้อัตราการไหม้จาก USTC เพิ่มขึ้น
ภาคผนวก 2: คำถามและคำตอบ
ถาม: สิ่งนี้สามารถทำให้เกิดภาวะเงินเฟ้อ LUNC เพิ่มเติมได้หรือไม่?
ตอบ ไม่ จะมีการหลีกเลี่ยงการผลิตเหรียญในสวอป โดย LUNC ที่มีอยู่จะจำกัดอยู่ที่จำนวนเงินในกลุ่ม โดยอิงตามผลประโยชน์ทางภาษีจากงวดก่อนหน้า
ถาม: นี่คือการกำหนด USTC ใหม่หรือไม่?
ตอบ: ไม่ USTC เป็นสินทรัพย์เก็งกำไร และแนวคิดนี้ก็ถือว่าเป็นเช่นนั้น มูลค่าของ USTC คำนวณตามราคาตลาดของสัญญาสวอป
ถาม: แล้ว Binance ที่ถูกเผาล่ะ? ตอนที่เราสร้างเหรียญใหม่ๆ ก่อนหน้านี้ พวกมันหยุดเผาไปแล้ว
ตอบ: เราหลีกเลี่ยงการสร้างเหรียญด้วยวิธีนี้โดยสิ้นเชิง แม้ว่าในตอนแรกเราจะมีอัตราการใช้เงินที่ลดลงเมื่อเราเปลี่ยนเส้นทางภาษีบางส่วนไปยังสวอปพูล แต่ยอดคงเหลือทั้งหมดที่เหลือจากพูลจะถูกใช้ไปเมื่อสิ้นสุดรอบระยะเวลา
ถาม: “MM swap pool” คืออะไร?
A: คือจำนวน LUNC และ USTC ที่ได้รับอนุญาตให้ใช้ในการแลกเปลี่ยนระหว่างช่วงเวลาหนึ่ง จำนวนเงินที่แลกเปลี่ยนจริงอาจสูงกว่านี้ได้ เนื่องจากยอดคงเหลือจะเพิ่มขึ้นอีกครั้งจากการแลกไปยังอีกฝั่งหนึ่ง
ถาม: ??? ขอตัวอย่างหน่อยได้ไหมครับ?
A: แน่นอน: ลองนึกภาพว่า 1 USTC มีมูลค่า 200 LUNC ในช่วงเวลาก่อนหน้า เรามีรายได้จากภาษี LUNC จำนวน 667 ล้าน ในอัตรา 60% ตัวเลขนี้จะทำให้ MM swap pool เต็มไปด้วย LUNC จำนวน 400 ล้านสำหรับช่วงเวลาถัดไป ดังนั้น หากตอนนี้ 2,000,000 USTC ถูกสลับไปยัง LUNC ผ่าน MM จะทำให้ผู้ใช้ได้รับ 400 ล้าน LUNC จากพูล ซึ่งจะทำให้การสลับในทิศทางนั้นถูกปิดใช้งานไปในทิศทางนั้น แต่หากตอนนี้มีการสลับจาก LUNC ไปยัง USTC (เช่น 100 ล้าน LUNC สำหรับ 500,000 USTC) 100 ล้าน LUNC เหล่านี้ก็จะพร้อมสำหรับการสลับอีกครั้ง
ถาม: แต่โดยรวมแล้ว การเผาไหม้จะลดลงอย่างมากหรือไม่ หากเปลี่ยนปริมาณดังกล่าวไปที่สระว่ายน้ำ?
ตอบ: ไม่ ยอดคงเหลือทั้งหมดในพูลจะถูกใช้หมดเมื่อเริ่มต้นยุคถัดไป ขึ้นอยู่กับพฤติกรรมการสลับว่าใช้ LUNC มากขึ้นและมี USTC น้อยลง หรือ USTC มากขึ้นและมี LUNC น้อยลง
ถาม: แต่นั่นมันไร้ประโยชน์ไม่ใช่เหรอ?
ตอบ: ไม่ครับ ค่าธรรมเนียมการสวอปแต่ละครั้งอยู่ที่ 0.35% ซึ่งจะถูกแบ่งให้กับเบิร์น (50%) และ Oracle Pool (50%) ยิ่งมีการสวอปมากเท่าไหร่ ก็ยิ่งมีการสวอปบ่อยขึ้นเท่านั้น ค่าธรรมเนียมก็จะยิ่งมากขึ้นเท่านั้น
ถาม: โอเค แต่เราจะคาดหวังการแลกได้เท่าไหร่กันล่ะ? ทุกคนจะแลกรางวัล USTC เป็น LUNC กันหมดไม่ใช่เหรอ?
A: นั่นอาจเกิดขึ้นได้ แต่ถึงอย่างนั้นก็อาจทำให้อุปทานของ USTC ลดลงได้ แต่เมื่อพิจารณาอัตราส่วน LUNC/USTC ในช่วงหลายเดือนที่ผ่านมา คุณจะพบว่ามูลค่าส่วนใหญ่ผันผวนอยู่ระหว่าง 190 ถึง 230 LUNC ต่อ USTC ซึ่งชี้ให้เห็นว่าผู้คนมักใช้ทั้งสองทิศทางในการซื้อขาย
ถาม: ใช่แล้ว เราจะคาดหวังปริมาณได้เท่าไร?
A: การประเมินนั้นค่อนข้างยาก และจะขึ้นอยู่กับปริมาณการซื้อขายบนเครือข่าย (on chain) และการเก็งกำไร (arbitrage) คู่สกุลเงิน LUNC/USTC ใน DEX ของเรามีปริมาณการซื้อขายประมาณ 120,000-130,000 ดอลลาร์สหรัฐต่อเดือนเมื่อเร็วๆ นี้ หากสมมติว่าปริมาณการซื้อขายนี้จะถูกแบ่งเท่าๆ กันระหว่าง DEX และ MM ปริมาณการซื้อขาย MM อาจอยู่ที่ประมาณ 30,000-40,000 ดอลลาร์สหรัฐ
ถาม: แต่คุณบอกว่า USTC ประเมินมูลค่าตามราคาตลาด จะสามารถทำกำไรจากการซื้อขายแบบเก็งกำไรได้อย่างไร
A: ราคาออราเคิลบนเชนจะถูกรายงานทุก 30 วินาที โดยเฉพาะอย่างยิ่งในช่วงที่มีความผันผวนสูง ราคา CEX อาจผันผวนอย่างรวดเร็ว นอกจากนี้ ราคา DEX ยังแสดงให้เห็นถึงความผันผวนอย่างมากในช่วงหลายเดือนที่ผ่านมา ซึ่งอาจนำเสนอทางเลือกในการเก็งกำไรกับ MM อย่างไรก็ตาม ยังไม่มีการรับประกัน
ถาม: ความเสี่ยงหลักๆ มีอะไรบ้าง และจะบรรเทาได้อย่างไร
ตอบ: ดังที่ได้กล่าวไปแล้ว ความเสี่ยงของภาวะเงินเฟ้อรุนแรงสามารถบรรเทาได้ด้วยขอบเขตและข้อจำกัดที่เข้มงวดมาก ความเสี่ยงของข้อผิดพลาดทางเทคนิคในการใช้งานควรบรรเทาลงด้วยการตรวจสอบอย่างละเอียด และหากชุมชนยินดีจ่ายเงิน ก็ควรมีการตรวจสอบโค้ด (ซึ่งเป็นสิ่งที่แนะนำ) ในกรณีที่พบข้อบกพร่องร้ายแรงซึ่งไม่น่าจะเกิดขึ้น ผู้ตรวจสอบ 33.4% สามารถ “หยุดการทำงานฉุกเฉิน” ของเชนเพื่อแก้ไขด่วนได้ ซึ่งคาดว่าไม่จำเป็นต้องทำเช่นนี้
ความเสี่ยงที่อาจเกิดขึ้นได้มากที่สุดคือความคาดหวังที่สูงเกินไปซึ่งอาจนำไปสู่ความผิดหวังได้
ความเสี่ยงอีกประการหนึ่งคือการสูญเสียการเผาไหม้ LUNC บางส่วนในกรณีที่ MM จะถูกใช้เพียงทางเดียว (USTC->LUNC) ซึ่งเทียบเท่ากับ USTC จะถูกเผาไหม้เกิน
ถาม: ใครเป็นคนพัฒนา? พร้อมหรือยัง? ไทม์ไลน์เป็นยังไง?
A: ผม (StrathCole) ขอเสนอตัวพัฒนาโปรแกรมนี้โดยสมัครใจ เนื่องจากผมทำในเวลาว่าง จึงไม่มีกำหนดเวลาตายตัว ผมคาดว่าการนำไปปฏิบัติจริง (โดยไม่ทดสอบ) จะใช้เวลา 2-3 สัปดาห์ อย่างไรก็ตาม ทีมงานสามารถเสนอราคาและขออนุมัติจากชุมชนเพื่อนำไปปฏิบัติจริงได้
ถาม: ถ้าทำแบบสมัครใจทำไมต้องมีข้อเสนอ?
ตอบ: เพราะผมไม่สามารถใช้เวลาในการพัฒนาได้หากไม่มีข้อเสนอส่งสัญญาณที่แสดงให้เห็นถึงแนวทางนี้ตามที่ชุมชน/หน่วยงานกำกับดูแลต้องการ มีข้อกังวลมากมายเกี่ยวกับการเปิดโมดูลตลาด ดังนั้น การอนุมัติจึงเป็นข้อกำหนดเบื้องต้นสำหรับผมในการเริ่มพัฒนาโมดูลนี้
ถาม: การทดสอบจะใช้เวลานานเท่าใด?
ตอบ: เรื่องนี้ไม่สามารถคาดการณ์ได้ เนื่องจากนี่เป็นส่วนสำคัญของบล็อกเชน เราจึงจำเป็นต้องทดสอบความเครียดของแนวทางนี้ในทุกวิถีทางที่เป็นไปได้ ซึ่งรวมถึงการจำลองการปั่นราคา การหยุดทำงานของ Oracle Feeder ความผันผวนของราคา ปริมาณสวอป ฯลฯ ยิ่งมีคนเข้ามาช่วยทดสอบและตรวจสอบมากเท่าไหร่ก็ยิ่งดีเท่านั้น
ถาม: ตามที่กล่าวถึงการตรวจสอบ/ตรวจสอบแล้ว นี่ไม่ใช่การทำงานฟรีใช่ไหม?
ตอบ ไม่ ทีมงานที่เสนอราคาให้ตรวจสอบ หรือบริษัทตรวจสอบบัญชีที่เสนอบริการตรวจสอบบัญชี จะต้องขอเงินทุนสำหรับการตรวจสอบนั้นอย่างแน่นอน
ถาม: หากเราต้องการใช้ MM ในรูปแบบเดิมในภายหลังจะทำอย่างไร?
ตอบ: การเปลี่ยนแปลงจะได้รับการออกแบบให้น้อยที่สุดเท่าที่จะเป็นไปได้ในแง่ของการเปลี่ยนจากระบบ mint/burn ไปสู่ระบบ pool คุณสามารถย้อนกลับระบบนี้เพื่อใช้งาน MM ในภายหลัง รวมถึงกลไก mint/burn ได้
