Skip to main content
Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Dieser Eintrag behandelt ein bevorstehendes LaunchLab-Programm-Update. Er wurde vor der Bereitstellung gegen den lokalen Release-Branch überprüft. Bestätigen Sie das bereitgestellte Programm, bevor Sie sich auf die neue Anweisung oder das geänderte MigrateToAmm-Layout verlassen.
Dies ist das Release, in dem LaunchLab seine Übergangskonstruktion ablegt. Es gab drei separate Mechanismen, um frühere Upgrades sanft zu gestalten: get_upgrade_timestamp, ein hartcodiertes Umstellungsdatum, das mehrere Checks gegen die Uhr verglichen; ein veraltetes Initialize, das drei Tage nach diesem Datum weiterhin funktionierte; und die OpenBook-Infrastruktur von MigrateToAmm, die nach AMM v4 seine eigene OpenBook-Abhängigkeit im Juli entfernte, nichts mehr zu tun hatte. Alle drei sind weg. Auf Mainnet liegt die Umstellung Monate zurück, daher ist die Verhaltensauswirkung null — aber die Fehlermodi haben sich geändert, und eine Kontoliste hat sich drastisch verändert. Das Framework wurde gleichzeitig aktualisiert: Anchor 0.32.1 zu =1.0.2, Agave 2.3.0 zu 3.1.10. Und wie bei AMM v4 und CPMM gibt es eine neue Admin-Anweisung zur Rückgewinnung von Miete. Handel, Gebühren, Vesting, Kurvenregeln und Plattformkonfiguration bleiben unverändert.

​
TL;DR für Integratoren

  • Keine Handelsanweisung hat ihre Konten, Argumente oder Mathematik geändert. BuyExactIn, BuyExactOut, SellExactIn, SellExactOut sind byte-identisch. Kein Kontolayout hat sich geändert.
  • Initialize (das veraltete) schlägt jetzt immer mit NotApproved (6000) fehl, bevor es ein Konto liest. Verwenden Sie InitializeV2. Durch es erstellte Launches handeln und graduieren normal.
  • MigrateToAmm ist ein Hard-Break für die Migrations-Wallet. Es verlor alle drei Argumente (base_lot_size, quote_lot_size, market_vault_signer_nonce) und neun Konten. Siehe unten.
  • Die drei Trade-remaining_accounts sind jetzt bedingungslos erforderlich, und der system_program-Slot wird validiert. Ein Builder, der sie auslässt, schlägt jetzt immer mit NotEnoughRemainingAccounts (6018) fehl, statt nur nach der Umstellung.
  • Eine Anweisung wird hinzugefügt: CollectExcessLamports. Nur für Admin. Siehe products/launchlab/instructions.
  • Ein Fehlercode wird hinzugefügt: 6031 LamportsCalculateError. Codes 6000–6030 bleiben unverändert.
  • Drei MigrateToCpswap-Adressbeschränkungen wurden in den Anweisungstext verschoben, wodurch ihr Fehler von ConstraintAddress (2012) zu RequireKeysEqViolated (2502) wechselt.
  • Eine IDL-Aktualisierung ist erforderlich. Eine neue Anweisung, ein entfernter Argumentsatz, neun entfernte Konten, eine neue Fehler-Variante.

​
MigrateToAmm verlor seine OpenBook-Hälfte

Dies ist die Änderung, die am ehesten etwas kaputt macht. Alte Anweisungsdaten trugen 17 Bytes Argumente nach dem Diskriminator; neue Daten sind der bloße Diskriminator. Alte Kontolisten trugen neun Konten, die nicht mehr in der Struktur existieren, daher ist alles nach der ersten Entfernung falsch ausgerichtet. Entfernte Argumente: base_lot_size: u64, quote_lot_size: u64, market_vault_signer_nonce: u8. Alle drei existierten nur, um den OpenBook-Markt zu konfigurieren, den das Programm per CPI initialisierte. Dieser CPI — initialize_openbook_market — ist weg, zusammen mit der gen_vault_signer_key-Prüfung, die den Nonce validierte. Entfernte Konten: openbook_program, request_queue, event_queue, bids, asks, market_vault_signer, market_base_vault, market_quote_vault und amm_open_orders. Das letzte ging, weil AMM v4’s Initialize2 es nicht mehr nimmt. Das market-Konto bleibt, in seiner ursprünglichen Position. AMM v4 zeichnet den Markt immer noch als Referenzfeld auf AmmInfo auf, daher leitet LaunchLab ihn weiter. Zwei Dinge daran haben sich geändert: Das Programm initialisiert es nicht mehr, und es ist jetzt völlig unvalidiert — seine Deklaration ist ein bloßes #[account(mut)] ohne Owner-, Adress- oder Seeds-Beschränkung, da owner = openbook_program.key() zusammen mit dem openbook_program-Konto entfernt wurde und nichts es ersetzte. Was immer die Migrations-Wallet dort übergibt, wird direkt in AMM v4’s Initialize2 CPI weitergeleitet und auf dem neuen Pool aufgezeichnet. Ein Aufrufer, der einen echten initialisierten Markt hinter diesem Feld haben möchte, muss ihn vorher erstellen, und das Programm wird es nicht anders mitteilen. Die resultierende 23-Kontoliste ist vollständig auf products/launchlab/instructions dokumentiert. MigrateToCpswap ist unberührt — es hatte nie Argumente, und seine Kontoliste ist unverändert.

​
Das veraltete Initialize schlägt immer fehl

initialize führte zuvor eine sanfte Veraltung durch: Es funktionierte bis get_upgrade_timestamp() + 3 days, dann gab es NotApproved zurück. Mit dem gelöschten Timestamp-Helper ist der Fehler bedingungslos — der Handler ist jetzt ein msg! und err!(NotApproved) und nichts anderes. Ein Detail, wenn Sie Logs lesen: Die Accounts-Struktur ist unverändert und trägt immer noch vier init-Beschränkungen, daher läuft Anchors generierter Kontovalidierungs-Prolog — und erstellt diese Konten — bevor der Handler zurückkehrt. Die Transaktion wird sowieso rückgängig gemacht, daher wird tatsächlich nichts erstellt, aber der Fehler tritt nach der Kontovalidierung auf, nicht davor. Die Anweisung wird beibehalten, anstatt entfernt zu werden, damit ihr Diskriminator besetzt bleibt und die IDL eine stabile Form behält. Seine Argument- und Kontodefinitionen sind immer noch dokumentationswert zum Dekodieren historischer Transaktionen, und die Seite behält sie hinter einer Warnung.

​
Das get_upgrade_timestamp-Gate ist weg

Der Helper gab 0 unter den Features local und devnet zurück und den hartcodierten Mainnet-Timestamp 1755522000 (2025-08-18 13:00 UTC) andernfalls. Vier Anweisungen verglichen die Uhr dagegen, über fünf Referenzen im Quellcode. Jede wird bedingungslos zum Post-Umstellungs-Branch: Der Mainnet-Timestamp liegt über ein Jahr zurück, daher sieht ein korrekter, aktueller Builder keine Verhaltensänderung. Was sich geändert hat, ist, dass ein veralteter Builder jetzt deterministisch fehlschlägt, anstatt gegen einen Devnet-Build zu funktionieren. Die neue system_program-Validierung ist wirklich neu: Dieser Slot akzeptierte zuvor jedes Konto.

​
CollectExcessLamports

Schritt 1 von SIMD-0437 landete am 3. September 2026 auf Mainnet und senkte das Miete-Minimum um 9% mit vier weiteren Schritten. Jeder LaunchLab-Pool-Vault, Fee-Vault und Programm-eigene PDA, die vor einem Schritt erstellt wurden, sind jetzt überfinanziert. Die Anweisung nimmt vier feste Konten — die Signer/Ziel-Wallet, eine Vault-Authority-PDA und beide Token-Programme — dann beliebig viele Quellkonten in remaining_accounts. Der authority-Slot ist der Teil, der sorgfältig gelesen werden sollte. LaunchLab hat drei Vault-Authority-PDAs (vault_auth_seed, platform_fee_vault_auth_seed, creator_fee_vault_auth_seed), und die Anweisung löst diejenige auf, die Sie übergeben haben, indem alle drei neu abgeleitet und abgeglichen werden; ein Schlüssel, der keinem entspricht, schlägt mit InvalidOwner (6001) fehl. Da ein Aufruf eine Authority trägt und das Token-Programm erfordert, dass jedes Konto seinen tatsächlichen Owner signiert, müssen Quellkonten nach Authority gruppiert werden — Pool-Vaults, Plattform-Fee-Vaults und Creator-Fee-Vaults werden in separaten Transaktionen geleert. Programm-eigene PDAs werden direkt belastet und können mit jeder Authority mitfahren. Wrapped SOL folgt der gleichen SyncNative → delta-großen UnwrapLamports → assert-unchanged-Sequenz, die CPMM und AMM v4 verwenden, mit LamportsCalculateError (6031), wenn die Hin- und Rückfahrt nicht zu Null führt. Ein SOL-notierter Launch behält seine volle Quote-Reserve. Basis-Mints können nicht geleert werden. InitializeV2 und InitializeWithToken2022 widerrufen MintTokens in der gleichen Anweisung, die die Versorgung prägt, daher kann kein Schlüssel einen WithdrawExcessLamports für einen Basis-Mint signieren. Seine Miete ist absichtlich gestrandet. Der Signer kann entweder der gemeinsame Programm-Admin oder eine dedizierte Collect-Lamports-Wallet sein; Adressen sind in reference/program-addresses.

​
MigrateToCpswap-Beschränkungs-Verschiebung

Drei Kontobeschränkungen wurden aus der Accounts-Struktur in den Anweisungstext verschoben:
Die Anforderung ist identisch — alle drei müssen immer noch den auf PoolState gespeicherten Werten entsprechen. Nur die Fehleroberfläche unterscheidet sich: Anchors generisches RequireKeysEqViolated (2502), ohne Kontonamen gemeldet, anstelle von ConstraintAddress (2012), das das fehlerhafte Konto benennt. Aktualisieren Sie jede Fehlerbehandlung, die auf 2012 für diese drei Konten abgestimmt ist.

​
Toolchain- und Abhängigkeitsänderungen

Anchors zwei Aufrufstellen-Änderungen von 1.0 gelten auch hier: Context kollabiert von vier Lebenszeit-Parametern zu einem, und CpiContext::new nimmt den Pubkey des Programms anstelle seines AccountInfo. Siehe sdk-api/rust-cpi. Zwei Build-System-Details ohne On-Chain-Effekt: Das Feature local wurde durch localnet ersetzt, das die lokale Wallet als admin aus einer LAUNCHPAD_LOCALNET_ADMIN-Umgebungsvariable kompiliert (yarn test:local-admin verdrahtet es), und der doppelte [profile.release]-Block in programs/launchpad/Cargo.toml wurde gelöscht — Cargo ignoriert [profile] außerhalb der Workspace-Root, daher war der Root-Block bereits der gültige, einschließlich der Tatsache, dass der panic = "abort" des Programm-Level-Blocks nie angewendet wurde.

​
Was sich nicht geändert hat

  • Jedes Kontolayout. PoolState, GlobalConfig, PlatformConfig, PlatformCurveRule, PlatformAllowConfig, Vesting-Datensätze — gleiche Größen, gleiche Offsets.
  • Fehlercodes 6000–6030, einschließlich des absichtlich beibehaltenen 6020.
  • Kurvenmathe, Gebührensätze, Gebührenabgrenzung, Vesting-Zeitpläne und die Graduierungs-LP-Aufteilung.
  • Plattform-Kurvenregeln und die GlobalConfig-Allowlist. Gleiche Anweisungen, gleiche Konten, gleiche Semantik; nur das Uhr-Gate um die Kurvenregel-Prüfung ist weg.
  • MigrateToCpswap’s Kontoliste und remaining_accounts-Indizes.
  • Die Token-2022-Transfergebühren-Authority-Übergabe bei Graduation.
  • Programm-ID. Unverändert.

​
Aktualisierte Seiten

  • products/launchlab/instructions — CollectExcessLamports hinzugefügt mit seiner Kontoliste, Authority-Auflösungstabelle und Gruppierungswarnung; MigrateToAmm’s Argument- und Kontoentfernungen dokumentiert mit der vollständigen neuen Liste; Initialize mit einer Always-Fails-Warnung versehen; neuer Abschnitt „Trade remaining accounts” mit den jetzt bedingungslosen drei Konten und der system_program-Prüfung; MigrateToCpswap-Notiz zum Nur-Berechtigung-Pfad und den verschobenen Beschränkungen; Inventar- und State-Change-Matrix-Zeilen.
  • products/launchlab/overview — Release-Banner; die „CPMM-only”- und Basis-Mint-Invarianten korrigiert.
  • products/launchlab/accounts — Mint-Authority-Widerruf-Timing auf Launch-Erstellung korrigiert (es war bei Graduation dokumentiert); CollectExcessLamports-Zeile hinzugefügt.
  • reference/error-codes — 6031 dokumentiert.
  • reference/program-addresses — neuer Abschnitt „Excess-lamports collection wallets”.
  • solana-fundamentals/rent-and-reclaimable-rent — neuer Abschnitt „What the Raydium programs sweep on their own side”.
  • sdk-api/rust-cpi, solana-fundamentals/toolchain — Anchor 1.0 Pins und die CPI-Migrations-Notizen.