Skip to main content
Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Diese Seite dokumentiert das Pro-Launch-Kontennetzwerk: die PoolState (das Root-State-Konto für einen Launch), ihre zwei Vaults, die Authority-PDA und die Post-Graduation-Referenzen, die sie erhält, wenn der Launch abgeschlossen wird. Für die Protocol-Level-Konfiguration, die jeden Launch begrenzt, siehe products/launchlab/global-config. Für die Pro-Platform-Überlagerung siehe products/launchlab/platform-config. Für Vesting-Konten (VestingSchedule auf PoolState, VestingRecord pro Begünstigter), siehe products/launchlab/vesting.

Konteninventar

Das SDK raydium.launchpad.getLaunchById gibt PoolState plus ein Flag zurück, das anzeigt, ob der Launch abgeschlossen wurde; wenn ja, ist die Post-Migration-Pool-ID enthalten.

PoolState

Der Pro-Launch-Root-State. Feldnamen unten entsprechen der On-Chain-Rust-Struktur (states/pool.rs); einige Werte sind zur Lesbarkeit vereinfacht — konsultieren Sie die Quelle für das exakte Memory-Layout.
PoolStatus-Werte (aus dem Anchor IDL):
Integrator-relevante Felder:
  • status — drei Werte, monoton (Funding → Migrate → Migrated). Lesevorgänge immer sicher; Schreibvorgänge gated.
  • real_base, real_quote — aktueller Curve-State. Kombiniert mit virtual_base / virtual_quote sind sie ausreichend, um den Spot-Preis zu berechnen, ohne die Vaults zu berühren. Siehe bonding-curve.
  • total_base_sell vs real_base — „Fortschritt zur Graduation”-Verhältnis für UIs.
  • migrate_type — neue Initialisierung erfordert 1 (CPSWAP). Ein gespeichertes 0 bleibt nur für einen bestehenden Launch sinnvoll, der vor der CPMM-Only-Erzwingung erstellt wurde.
  • amm_creator_fee_on — wählt creator_fee_on = OnlyQuoteToken (0) oder BothToken (1) auf dem Post-Graduation-CPMM-Pool. Es wählt nicht das Migrationsziel. Siehe creator-fees.
  • quote_protocol_fee / platform_fee / migrate_fee — drei unabhängige Gebührenzähler. Jeder hat seine eigene Claim-Anweisung; siehe instructions.
  • vesting_schedule — vorhanden auf jedem PoolState, aber inaktiv, wenn total_locked_amount == 0. Siehe vesting für den vollständigen Lebenszyklus.

Die Authority-PDA

LaunchLab verwendet eine einzelne Authority-PDA über alle Launches hinweg, abgeleitet ohne Pro-Launch-Seed:
Diese einzelne PDA ist:
  • Die Authority auf jedem Launch’s base_vault und quote_vault.
  • Die mint_authority auf jedem Launch’s base_mint (vor Graduation).
  • Der Unterzeichner auf der CPMM-Graduation-CPI und auf Legacy-AMM-v4-Graduation für bestehenden State.
  • Der Unterzeichner auf ClaimVestedToken-Transfers aus dem Base-Vault.
Die mint_authority wird unmittelbar nach MigrateToCpswap oder einem Legacy-MigrateToAmm-Aufruf widerrufen, sodass die Versorgung dauerhaft festgelegt ist. Zwei zusätzliche PDAs gaten die Gebühren-Vaults:
Diese unterzeichnen den Transfer aus den entsprechenden Gebühren-Vaults während ClaimCreatorFee und ClaimPlatformFeeFromVault.

Base Mint

Erstellt inline durch Initialize mit:
  • mint_authority = authority (widerrufen bei Graduation).
  • freeze_authority = None.
  • supply = supply, vollständig in base_vault geprägt.
  • decimals vom Creator bei Initialize gewählt (üblicherweise 6).
Da die vollständige Versorgung vorher geprägt ist, ist base_mint.supply für die Lebensdauer des Launches konstant. Curve-Käufe verschieben Token von base_vault zum Käufer, rufen aber nicht mint_to auf. Initialize / InitializeV2 erstellen SPL-Token-Launches. Die dedizierte InitializeWithToken2022-Anweisung ermöglicht es, dass der Base-Mint ein Token-2022-Mint ist (mit optionalem TransferFeeConfig); der Quote-Mint ist immer noch SPL Token. Alle drei Initialisierungspfade erfordern CPMM-Graduation.

Vaults

Sowohl base_vault als auch quote_vault sind Standard-SPL-Token-Konten, die von der LaunchLab-authority-PDA besessen werden. Adressen werden auf PoolState gespeichert und können auch abgeleitet werden:
(Überprüfen Sie die genauen Seed-Präfixe aus der Initialize-Accounts-Struktur der Quelle, bevor Sie sich in der Produktion auf eine Ableitung verlassen.)

Gebühren-Vaults

Zwei PDAs aggregieren Gebühren über Launches hinweg:
  • Creator-Gebühren-Vault — PDA mit Seeds [creator, quote_mint]. Jeder Launch, der die gleichen Creator-Gebühren auf dem gleichen Quote-Mint verdient, fließt in den gleichen Vault. Der Creator leert ihn über ClaimCreatorFee.
  • Platform-Gebühren-Vault — PDA mit Seeds [platform_config, quote_mint]. Jeder Launch, der durch die gleiche Platform geleitet wird und den gleichen Quote-Mint verwendet, fließt in den gleichen Vault. Die platform_fee_wallet der Platform leert ihn über ClaimPlatformFeeFromVault. Es gibt auch eine Pro-Launch-Leer-Variante (ClaimPlatformFee), die direkt aus dem Launch’s quote_vault zieht, ohne durch den aggregierten Vault zu gehen.
Das aggregierte-Vault-Muster ermöglicht es einem hochvolumigen Creator oder einer Platform, die Mietkosten der Gebührenakkumulation über viele Launches hinweg zu amortisieren.

Quote Vault ↔ real_quote

quote_vault.balance und PoolState.real_quote sollten synchron bleiben. Sie können um höchstens die Summe der drei ausstehenden Gebührenzähler (quote_protocol_fee, platform_fee, migrate_fee) abweichen, die im Vault sitzen, aber zu den Gebührenzählern und nicht zur Curve-Reserve gehören. Die Curve-Mathematik verwendet immer real_quote, nie den rohen Vault-Saldo. Pre-Graduation-Invariante:

Lebenszyklus-Kontentransitionen

Nächste Schritte

Quellen:
  • raydium-launch/programs/launchpad/src/states/pool.rsPoolState, PoolStatus, VestingSchedule, AmmCreatorFeeOn.
  • raydium-launch/programs/launchpad/src/lib.rs — PDA-Seed-Konstanten (AUTH_SEED, CREATOR_FEE_VAULT_AUTH_SEED, PLATFORM_FEE_VAULT_AUTH_SEED).
  • Raydium SDK v2 launchpad Modul.