LaunchLab Bonding Curve

Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →

LaunchLab unterstützt drei Kurvenformen, die bei Initialize ausgewählt werden: constant-product (die häufigste, Virtual-Reserve-Form der Standard-x · y = k Kurve), linear-price und fixed-price. Die Graduierungsschwelle ist für alle drei Formen identisch. Diese Seite erläutert die Mathematik der Constant-Product-Kurve im Detail; die linearen und festen Formen werden am Ende zusammengefasst.

Parameter auf `LaunchState`

Feld	Bedeutung
`curve_type`	`0` = constant-product (Virtual-Reserves), `1` = fixed-price, `2` = linear-price.
`base_supply_max`	Gesamtmenge an Base-Token, die die Kurve jemals prägen kann.
`base_supply_graduation`	Base-Token, die verkauft werden müssen, um die Graduierung zu erreichen. Normalerweise `0.8 × base_supply_max`; die verbleibenden 20% werden zur initialen LP des Post-Graduierungs-Pools.
`quote_reserve_target`	Quote-Menge, die die Graduierung auslöst. Wird bei `Initialize` aus den Kurvenparametern + `base_supply_graduation` hergeleitet.
`virtual_base` / `virtual_quote`	Virtual-Reserve-Seeds für die Constant-Product-Kurve.
`migrate_type`	Muss `CPSWAP` für neue Initialisierungen sein. Ein gespeicherter AMM v4-Wert ist nur Legacy-Status. Siehe `instructions`.
`fees.buy_numerator / buy_denominator`	Gebühr auf der Kaufseite, z. B. `100 / 10_000 = 1.00%`.
`fees.sell_numerator / sell_denominator`	Gebühr auf der Verkaufsseite. Oft gleich wie Kauf.
`fees.protocol_share`, `fees.creator_share`, `fees.lp_share`	Aufteilung der obigen Gebühren, summiert sich zum Nenner.

Feldnamen in der Rust-Struktur entsprechen den PoolState-Feldern, die in accounts beschrieben sind; die Einheiten oben sind konzeptionell.

Constant-Product-Kurve mit Virtual Reserves (`curve_type = 0`)

Die Standard- und am häufigsten verwendete Kurve. Pump-ähnliche Launches verwenden alle diese Form. Die Kurve geht davon aus, dass es von Anfang an eine virtuelle Quote-Reserve V_q und eine virtuelle Base-Reserve V_b gibt (gespeichert als virtual_quote und virtual_base auf PoolState), sodass der effektive Pool wie ein CPMM mit diesen Reserves aussieht. Käufe folgen der x · y = k Mathematik:

(V_q + real_quote_in_after_fee) × (V_b + real_base_remaining − base_out) = V_q × V_b

gelöst nach base_out:

base_out = (V_b + real_base_remaining) × quote_in_after_fee / (V_q + real_quote_in_after_fee)

Effektiver Preis bei Base-verkauft s:

price(s) = (V_q + real_quote_in(s)) / (V_b + real_base_remaining(s))

Die gleiche x · y = k Invariante, die LaunchLab vor der Graduierung anwendet, ist dann die CPMM-Kurve nach der Graduierung, sodass der Übergang mechanisch nahtlos ist: Der Grenzpreis bei base_sold = base_supply_graduation entspricht dem Preis, zu dem der Post-Graduierungs-Pool mit (quote_vault, base_vault_remaining) als seinen Reserves öffnet.

Fixed-Price-Kurve (`curve_type = 1`)

Eine Kurve mit konstantem Preis. Jeder Kauf/Verkauf findet zu einem konstanten Preis statt, der bei Initialize konfigurierbar ist:

price(s) = virtual_quote / virtual_base    (konstant für alle s)

Nützlich für faire Launches, bei denen das Team einheitliche Preise für alle Teilnehmer unabhängig vom Kaufzeitpunkt möchte. Die Graduierung wird ausgelöst, wenn base_supply_graduation verkauft wurde (die lineare Kostenbeziehung macht die Herleitung von quote_reserve_target unkompliziert).

Linear-Price-Kurve (`curve_type = 2`)

Der Preis steigt linear mit base_sold:

price(s) = a · s     (a = Steigung, hergeleitet aus virtual_base / virtual_quote)

Integrierte Kosten:

cost(s_0, s_1) = a · (s_1² − s_0²) / 2

Quadratisch in base_sold — frühe Käufer zahlen nahe null, späte Käufer zahlen erheblich mehr, wobei der Grenzpreis immer mit einer festen Steigung ansteigt. Die On-Chain-Implementierung befindet sich in curve/linear_price.rs.

Vergleich der Kurvenformen

price
  │   linear (steiler Schwanz)               linear (curve_type = 2)
  │       ╱
  │      ╱
  │     ╱            const-product (curve_type = 0)
  │    ╱            ╱
  │   ╱           ╱
  │  ╱         ╱
  │ ╱       ╱
  │╱_____╱_______________________  fixed-price (curve_type = 1)
  └──────────────────────────────── base_sold
  0                  S_grad         S_max

Graduierungsschwelle

quote_reserve_target wird bei Initialize als die Quote berechnet, die erforderlich ist, um base_sold von 0 zu base_supply_graduation zu treiben:

quote_reserve_target = cost(0, base_supply_graduation) × (1 + buy_fee_rate)
                                                         ^^^^^^^^^^^^^^^^^
                                                         Näherung; exakte
                                                         Form entspricht der
                                                         Gebührenrundung bei Buy.

Ein Launch graduiert, sobald quote_vault.balance ≥ quote_reserve_target. Da Käufe in diskreten Größen erfolgen, kann der tatsächliche Saldo bei der Graduierung den Zielwert leicht überschreiten — der Überschuss wird zu zusätzlicher Quote-seitiger Liquidität im resultierenden CPMM-Pool.

Durchgerechnetes Beispiel — ein quadratischer Launch

Parameter:

base_supply_max = 1_000_000_000 (1 Milliarde Base-Token, 6 Dezimalstellen)
base_supply_graduation = 800_000_000 (80% verkauft löst Graduierung aus)
k = 40 (Preisskala)
Gebühren: 1% Kauf, 1% Verkauf, Aufteilung lp:creator:protocol = 60:20:20.

Anfangspreis (s = 0): 0 (rein quadratisch beginnt bei null). Preis bei 50% verkauft (s = 500_000_000):

price = 40 × (500e6 / 1e9)² = 40 × 0.25 = 10  (Quote pro Base, 6 Dezimalstellen)

Preis bei Graduierung (s = 800_000_000):

price = 40 × (800e6 / 1e9)² = 40 × 0.64 = 25.6

Quote erforderlich, um die Graduierung zu erreichen (integrierte Kosten):

cost(0, 800_000_000) = (40 / (3 × 1e18)) × ((800e6)³ − 0)
                     = (40 / 3e18) × 5.12e26
                     ≈ 6.827e9

Also ≈ 6.827 Quote-native Einheiten (in welcher 6-Dezimal-Quote-Mint auch immer konfiguriert ist, z. B. ~6.827 USDC, wenn die Quote USDC ist). Gebühr oben drauf:

quote_reserve_target ≈ 6.827e9 × 1.01 ≈ 6.895e9  (6.895 USDC)

Erster Kauf von 10 USDC:

Virtueller Status: s = 0, quote_vault = 0.
Gebühr abziehen: quote_after_fee = 10 × 0.99 = 9.9.
Löse (40 / (3e18)) × s³ = 9.9 ⇒ s ≈ 6.22e6 Base-Token gekauft.
1% Gebühr (0.1 USDC) Aufteilung: lp 0.06, creator 0.02, protocol 0.02. Der lp-Anteil bleibt in quote_vault; die anderen zwei leiten zu ihren jeweiligen Akkumulatoren weiter.

Kauf bei 75% verkauft (nähert sich der Graduierung): Die gleichen 10 USDC kaufen jetzt viel weniger Base, weil die Kurve steil ist. Ein Newton-Solve bei s₀ = 750e6 mit quote_in_after_fee = 9.9 ergibt ungefähr ∆s ≈ 0.4e6 — eine ~15-fache Reduktion in Base pro USDC im Vergleich zum ersten Kauf.

Gebührenmechanik während der Kurvephase

Bei jedem Buy:

gross_fee      = ceil(quote_in_gross × buy_numerator / buy_denominator)
lp_share       = gross_fee × fees.lp_share / fees.total_share
protocol_share = gross_fee × fees.protocol_share / fees.total_share
creator_share  = gross_fee × fees.creator_share / fees.total_share

lp_share bleibt in quote_vault. Dies ist das, was die effektive Kurve enger macht (mehr Quote-Reserve gegen die gleiche Base-Versorgung).
protocol_share erhöht LaunchState.state_data.protocol_fees_quote.
creator_share erhöht LaunchState.state_data.creator_fees_quote.

Bei Sell gilt die gleiche Aufteilung, aber die Gebühr wird vom ausgehenden quote_out abgezogen. Beide Zähler werden über CollectFees geleert (Admin oder Creator, jeweils zu ihrem eigenen Zähler).

Präzision

Base-seitige Beträge: u64.
Quote-seitige Beträge: u64.
Zwischenergebnisse (Kuben / Produkte): u128.
Newton-Lösungen für „Kauf exakte Quote” und „Verkauf exakte Quote” iterieren in u128 Festkomma mit einer konfigurierbaren maximalen Iterationszahl (Standard 10). Der Fehlermodus ist NotConverged — selten außerhalb von Grenzfällen nahe der Graduierung.

Übergabe an CPMM

Wenn Graduate ausgelöst wird:

cpmm_quote_reserve = quote_vault − swept_protocol_fees − swept_creator_fees
cpmm_base_reserve  = base_vault                       // d. h. base_supply_max − base_sold
cpmm_initial_price = cpmm_quote_reserve / cpmm_base_reserve

Für die quadratische Kurve ist cpmm_initial_price mechanisch price(base_sold) (es ist der Grenzpreis der Kurve zum Zeitpunkt des Übergangs). Der CPMM-Pool öffnet genau zu diesem Preis, sodass ein Beobachter, der von der Kurven-UI zur CPMM-UI wechselt, keinen Sprung sieht.

Nächste Schritte

products/launchlab/accounts — die LaunchState-Felder, die diese Parameter speichern.
products/launchlab/instructions — Buy, Sell, Graduate Kontolisten.
algorithms/constant-product — die CPMM-Mathematik, die der Post-Graduierungs-Pool verwendet.

Quellen:

Raydium SDK v2 LaunchLab Modul
Raydium LaunchLab Programmquelle

LaunchLab

Token-Launch-Ablauf

Tips & Gotchas

LaunchLab Bonding Curve

Parameter auf `LaunchState`

Constant-Product-Kurve mit Virtual Reserves (`curve_type = 0`)

Fixed-Price-Kurve (`curve_type = 1`)

Linear-Price-Kurve (`curve_type = 2`)

Vergleich der Kurvenformen

Graduierungsschwelle

Durchgerechnetes Beispiel — ein quadratischer Launch

Gebührenmechanik während der Kurvephase

Präzision

Übergabe an CPMM

Nächste Schritte

​Parameter auf LaunchState

​Constant-Product-Kurve mit Virtual Reserves (curve_type = 0)

​Fixed-Price-Kurve (curve_type = 1)

​Linear-Price-Kurve (curve_type = 2)

​Vergleich der Kurvenformen

​Graduierungsschwelle

​Durchgerechnetes Beispiel — ein quadratischer Launch

​Gebührenmechanik während der Kurvephase

​Präzision

​Übergabe an CPMM

​Nächste Schritte

Parameter auf `LaunchState`

Constant-Product-Kurve mit Virtual Reserves (`curve_type = 0`)

Fixed-Price-Kurve (`curve_type = 1`)

Linear-Price-Kurve (`curve_type = 2`)

Vergleich der Kurvenformen

Graduierungsschwelle

Durchgerechnetes Beispiel — ein quadratischer Launch

Gebührenmechanik während der Kurvephase

Präzision

Übergabe an CPMM

Nächste Schritte