Skip to main content
Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Dies ist das Changelog der Dokumentation — die Aufzeichnung von Aktualisierungen dieser Seiten seit dem Projektstart. Jede Version unten verlinkt auf einen eigenen Eintrag; öffnen Sie einen für die vollständige Zusammenfassung, betroffene Kapitel und Verifizierungsdatum. Für die historische Zeitleiste des Protokolls selbst siehe introduction/history-and-milestones.

​
Releases

​
CLMM: CreateCustomizablePoolV2 öffnet die Multi-Pool-Erstellung für alle
CreatePermissionedPool wird in CreateCustomizablePoolV2 umbenannt und verliert sein Permission-PDA-Gate, sodass jeder Zahler zusätzliche Pools für dasselbe Paar und die gleiche Gebührenebene unter einer seed_index-abgeleiteten Adresse erstellen kann. Argumente und die Pool-Adressableitung bleiben unverändert, aber der Diskriminator ändert sich und das permission-Konto verlässt Slot 3, daher müssen Clients, die gegen die alte Anweisung erstellt wurden, neu erstellt werden. pool_creator wird nicht authentifiziert, daher ist der owner eines V2-Pools kein Beweis dafür, wer ihn erstellt hat. Das Permission-Konto, CreatePermissionPda, ClosePermissionPda und der permission_pda_admin-Schlüssel werden entfernt; früher erstellte Permission-PDAs bleiben als inerte Daten in der Chain. Keine Account-Layout oder Fehlercode hat sich geändert. Die IDL sinkt auf 37 Anweisungen.Vollständigen Eintrag lesen →
​
CLMM: Anchor 1.0, Überschuss-Lamports-Rückgewinnung und feste Gebühreninhaber
CLMM wechselt zu Anchor 1.0.2 auf Agave 3.1.10, derselbe Wechsel, den CPMM und LaunchLab am 2026-09-09 durchgeführt haben. Beide öffentlichen CPI-Crates pinnen jetzt =1.0.2, sodass ein einzelnes Programm CPI in CPMM und CLMM durchführen kann. Eine neue Admin-Anweisung CollectExcessLamports gibt Miete zurück, die durch SIMD-0437 freigegeben wurde. Sie verarbeitet einen Pool pro Aufruf: die PoolState-PDA signiert für ihre eigenen Vaults und Reward-Vaults, wSOL-Vaults durchlaufen die SyncNative-/UnwrapLamports-Rundreise, und jedes CLMM-eigene Konto in remaining_accounts wird auf sein Miete-Minimum reduziert. CreateAmmConfig schreibt jetzt hardcodierte protocol_fee_owner- und fund_fee_owner-Schlüssel statt des Signers. Im Mainnet sind dies die Schlüssel, die bereits auf allen 21 Konfigurationen gespeichert sind, und vorhandene Konfigurationen werden nicht neu geschrieben. 6052 angehängt. Keine benutzergerichtete Anweisung oder Account-Layout hat sich geändert.Vollständigen Eintrag lesen →
​
CPMM: Das Protokoll nimmt einen Anteil der Creator-Gebühr
CPMM kann jetzt einen Teil der Creator-Gebühr behalten. Die Aufteilung wird angewendet, wenn die Gebühr eingezogen wird, nicht wenn sie erhoben wird: Ein Swap sammelt weiterhin die gesamte Creator-Gebühr in creator_fees_token*, und CollectCreatorFee/CollectCreatorFeePermissionless verschieben dann einen Anteil in die bestehenden protocol_fees_token*-Zähler des Pools und zahlen dem Creator den Rest — mit Abrundung, sodass Staub beim Creator bleibt. Der Satz stammt aus einem neuen AmmConfig.creator_fee_share_rate (aus dem Padding ausgeschnitten; das Konto ist immer noch 236 Bytes, aber das alte padding[0] ist jetzt ein Live-Feld) oder aus einer Pro-Creator-CreatorFeeShare-PDA, die es überschreibt und von den neuen Admin-Anweisungen CreateCreatorFeeShare/CloseCreatorFeeShare verwaltet wird. Breaking für Creator-Fee-Clients: Beide Einzugsanweisungen nehmen neue Konten an, die am Ende ihrer Listen angehängt werden — vorhandene Konten behalten ihre Positionen, aber die neuen sind obligatorisch, daher wird eine Vor-Upgrade-Transaktion wegen fehlender Konten abgelehnt. UpdateAmmConfig erhält param = 8. PoolState, Swap-Mathematik und die k-Prüfung bleiben unverändert, und es wurde kein Fehlercode hinzugefügt. Mitfahrer: Eine Zwei-Pass-Sortierungskorrektur in CollectExcessLamports.Vollständigen Eintrag lesen →
​
LaunchLab: Anchor 1.0, Überschuss-Lamports-Rückgewinnung und das Ende der Übergangsgates
LaunchLab wechselt zu Anchor 1.0.2 auf Agave 3.1.10 und stellt sein Übergangsgerippe ein. Das veraltete Initialize schlägt jetzt bedingungslos mit NotApproved fehl. MigrateToAmm ist hart-breaking für die Migrations-Wallet: Alle drei Argumente und neun OpenBook-Konten sind weg, nach AMM v4’s eigenem OpenBook-Entfernen, und das Programm initialisiert den Markt nicht mehr per CPI. Das get_upgrade_timestamp-Clock-Gate wird gelöscht, daher sind die drei Trade-remaining_accounts bedingungslos erforderlich (mit dem jetzt validierten system_program-Slot), MigrateToCpswap nimmt immer den genehmigten CPMM-Pfad, und InitializeWithToken2022 verliert seine amm_fee_on-Einschränkung. Eine neue Admin-Anweisung CollectExcessLamports gibt Miete zurück, die durch SIMD-0437 freigegeben wurde — beachten Sie, dass Quellkonten nach dem Vault-Authority-PDA gruppiert werden müssen, der sie besitzt. Drei MigrateToCpswap-Adressenbeschränkungen wurden in den Anweisungstext verschoben, was 2012 zu 2502 ändert. 6031 angehängt. Keine Account-Layout-, Trade-Anweisungs- oder Gebührenverhalten hat sich geändert.Vollständigen Eintrag lesen →
​
CPMM: Anchor 1.0, Überschuss-Lamports-Rückgewinnung und feste Gebühreninhaber
CPMM wechselt zu Anchor 1.0.2 auf Agave 3.1.10 und fügt eine Admin-Anweisung CollectExcessLamports hinzu, die Miete zurückgibt, die durch SIMD-0437 aus Vaults, LP-Mints und PDAs freigegeben wurde — einschließlich Wrapped-SOL-Vaults über eine SyncNative-/UnwrapLamports-Rundreise, die das Wrapped-Guthaben unverändert lässt. Drei Verhaltensänderungen fahren mit: CreateAmmConfig schreibt jetzt hardcodierte protocol_fee_owner- und fund_fee_owner-Schlüssel statt des Signers (vorhandene Konfigurationen werden nicht migriert — lesen Sie die Felder), die hardcodierte vier-Adressen-Token-2022-MINT_WHITELIST wird entfernt, sodass die SupportMintAssociated-Registry-PDA die einzige verbleibende Umgehung ist, und ClosePermissionPda akzeptiert jetzt die dedizierte Grant-Autorität. 6015 angehängt. Keine benutzergerichtete Anweisung oder Account-Layout hat sich geändert.Vollständigen Eintrag lesen →
​
AMM v4: Solana 3.0-Abhängigkeiten und Überschuss-Lamports-Rückgewinnung
AMM v4 wird gegen solana-program 3.0.0, spl-token 9.0.0, spl-associated-token-account 8.0.0 und die neue solana-system-interface-Crate neu erstellt und fügt eine Admin-only-Anweisung WithdrawExcessLamports (Tag 18) hinzu, die Miete zurückgibt, die durch SIMD-0437 freigegeben wurde. Jede Trader- und LP-gerichtete Anweisung behält ihre Konten, Argumente und Mathematik, und nichts in der Veröffentlichung ist Breaking: CreateConfigAccount hat aufgehört, seinen nachfolgenden Rent-Sysvar zu lesen, akzeptiert aber immer noch die alte fünf-Konto-Liste. AmmError erhält Code 60 (es nummeriert von 0, nicht 6000).Vollständigen Eintrag lesen →
​
LaunchLab: Plattform-Kurvenregeln ersetzen die Kurvenparameter-Whitelist
Start-Parametereinschränkungen werden aus PlatformConfig in Pro-Config-PlatformCurveRule-Konten verschoben. Eine Regel enthält bis zu 10 Prüfgruppen mit bis zu 25 (field, op, value)-Einschränkungen über 19 Startparameter, mit Eq/Gte/Lte/Neq — sodass eine Plattform endlich ein Wertband, alternative Ebenen, eine Graduierungs-Bewertungsobergrenze, einen Migrations-Boden, Token-Typ-Gating oder eine Gruppe ausdrücken kann, die sich an einem Datum umschaltet, was die nur-Gleichheit-Whitelist nicht konnte. PlatformConfig behält seine 944-Byte-Größe: restrict_curve_param, curve_rule_manager und das Längenpräfix des entfernten Vektors kommen alle aus dem Padding. Decoder müssen das nachfolgende Vec<PlatformCurveParam> ablegen, und Launch-Builder müssen die Regel-PDA zu remaining_accounts anhängen, während das Flag an ist. Zwei Anweisungen entfernt, vier hinzugefügt, zwei UpdatePlatformConfig-Varianten hinzugefügt, 6024–6030 angehängt. IDL-Aktualisierung erforderlich. Das SDK liefert zwei reine Off-Chain-Prüfungen, sodass ein Creator nie eine Regel aus einer zurückgewiesenen Transaktion lernen muss, und der Eintrag dokumentiert eine Devnet-Probe vor dem Aktivieren des Flags im Mainnet.Vollständigen Eintrag lesen →
​
LaunchLab: Plattform hält die Withdraw-Withheld-Autorität von der Mint-Erstellung
InitializeWithToken2022 schreibt jetzt PlatformConfig.transfer_fee_extension_auth in die withdraw_withheld_authority der neuen Basis-Mint statt in die Launch-authority-PDA, sodass eine Plattform einbehaltene Transfergebühren während der Bonding-Curve-Phase einziehen kann, anstatt auf die Graduierung zu warten — das Programm selbst hat keine Withdraw-Withheld-Anweisung. MigrateToCpswap weist diese Autorität nur neu zu, wenn die PDA sie noch hält, was die Graduierung für Mints beider Generationen funktionsfähig hält. transfer_fee_config_authority wechselt immer noch nur bei der Graduierung, daher lässt das Rotieren von transfer_fee_extension_auth während des Starts die beiden Autoritäten stillschweigend auf verschiedenen Schlüsseln. Keine Account-Layout-, Anweisungs-, Argument- oder Fehlercode-Änderung.Vollständigen Eintrag lesen →
​
LaunchLab: Plattform-Gebührensatz-Obergrenze auf 500 bps erhöht
Die Plattform-fee_rate-Obergrenze wird auf 50000 (500 bps) auf beiden Pfaden verschoben, die sie validieren. CreatePlatformConfig war seit der ersten Veröffentlichung des Programms auf 10000 (100 bps) begrenzt; UpdatePlatformConfig war seit 2026-01-27 auf 25000 (250 bps) begrenzt. Die beiden Prüfungen stimmen jetzt überein, sodass eine Plattform, die mit einer zulässigen Rate erstellt wurde, auch mit ihr aktualisiert werden kann — einschließlich durch die AllInfo-Bulk-Variante, die fee_rate neu validiert, während sie jedes andere Feld neu schreibt. Die beiden Pfade erheben immer noch unterschiedliche Fehler (InvalidInput bei Erstellung, InvalidPlatformInfo bei Aktualisierung). Keine Account-Layout-, Anweisungs- oder Fehlercode-Änderung, und keine vorhandene Plattform oder Launch wird neu bepreist. GlobalConfig.max_share_fee_rate bleibt bei 100 bps und begrenzt nur die Pro-Transaktion-Referral-share_fee_rate.Vollständigen Eintrag lesen →
​
LaunchLab: Token-2022-Quote-Mints
Ein Start kann jetzt in einer Token-2022-Mint notiert werden. CreateConfig, InitializeV2, InitializeWithToken2022, die vier Swap-Anweisungen und jeder Gebührenanspruch akzeptieren beide Token-Programme in ihrem Quote-Programm-Slot; das veraltete Initialize bleibt nur Legacy. Swap-Slippage-Grenzen werden jetzt gegen das verglichen, was der Zahler tatsächlich zahlt oder erhält, netto der Transfergebühr der Quote-Mint. PoolState.token_program_flag Bit1 wird aussagekräftig, daher lesen Decoder, die das ganze Byte gegen 0 testen, eine Legacy-Basis-Mint als Token-2022 falsch. MigrateToCpswap benennt seine zwei Token-Programm-Konten in token_program/token_program_2022 um, und 6023 wird für CalculateOverflow wiederverwendet.Vollständigen Eintrag lesen →
​
LaunchLab: CPMM-only-Starts und Plattformkonfigurations-Kontrollen
Die neue Start-Initialisierung erfordert jetzt CPMM, während Legacy-AMM-v4-gebundener Status migrierbar bleibt. Vor dieser Veröffentlichung produzierte creator_scale einen Creator-eigenen Fee-Key; CPMM-Migrationen, die nach dem Upgrade ausgeführt werden, konsolidieren stattdessen platform_scale + creator_scale in einen Plattform-eigenen Fee-Key-Anteil. Plattformen können Starts auch mit ihren eigenen PlatformAllowConfig-PDAs einschränken, und Migrations-Builder müssen beide CPMM-Support-Mint-PDAs anhängen.Vollständigen Eintrag lesen →
​
CLMM: Eingeschränkte-Emittent-Position-NFT-Einfrierung
Neue CLMM-Position-NFT-Mints verwenden ihren Pool als Freeze-Autorität, aber ihre Token-Konten bleiben standardmäßig nicht eingefroren. Das Einfrieren erfolgt nur bei OpenPositionV2 oder OpenPositionWithToken22Nft, wenn die Freeze-Autorität einer der zugrunde liegenden Vault-Mints mit der Restricted-Issuer-Liste übereinstimmt. Eine übereinstimmende Position kann nicht übertragen oder den Besitzer ändern, kann aber weiterhin Liquidität verwalten. Sein ClosePosition-Aufruf muss den Pool anhängen, damit CLMM atomar auftauen, brennen und schließen kann. Vorhandene Positionen bleiben unverändert.Vollständigen Eintrag lesen →
​
CPMM: Genehmigungslose Creator-Gebühreneinziehung
Eine additive CollectCreatorFeePermissionless-Anweisung lässt jeden Zahler alle aufgelaufenen Creator-Gebühren einziehen, während der Begünstigte und beide Token-Ziele auf PoolState.pool_creator und die kanonischen ATAs des Creators beschränkt werden. Der ursprüngliche Creator-signierte Pfad bleibt unverändert. CreatePermissionPda akzeptiert auch eine dedizierte Grant-Autorität, während ClosePermissionPda Admin-only bleibt.Vollständigen Eintrag lesen →
​
CLMM: Genehmigte Multi-Pools und Limit-Order-Frozen-Account-Guard
Zwei additive, rückwärtskompatible CLMM-Programm-Updates. CreatePermissionedPool faltet einen Client-gelieferten Nicht-Null-seed_index in die Pool-PDA-Seeds, was einem Whitelist-Operator (einem, der eine Permission-PDA hält) ermöglicht, mehrere Pools pro (config, mint0, mint1) zu erstellen — sodass eine Pool-ID nicht mehr kanonisch für ein Paar ist. Neue Admin-Anweisungen CreatePermissionPda/ClosePermissionPda verwalten diese Zuschüsse, und PoolState erhält ein seed_index-Feld (aus dem Padding ausgeschnitten, keine Größenänderung). Separat lehnt OpenLimitOrder jetzt die Ausgabeseiten-Konten ab und lehnt Aufträge ab, deren Input- oder Output-Token-Konto eingefroren ist (NotApproved).Vollständigen Eintrag lesen →
​
AMM v4: OpenBook-/Serum-Abhängigkeit entfernen
AMM v4 entfernt seine lange ruhende OpenBook-/Serum-Abhängigkeit, alle Order-Book-CPIs und die toten Market-Making-Anweisungen. SwapBaseIn/SwapBaseOut, Deposit und Withdraw behalten ihre Layouts (entfernte Market-Konten werden jetzt ignoriert, nicht validiert); ein hart-breaking WithdrawPnl (17 → 10, keine Kompatibilität) und SetParams (reduzierte Konten + umbenummerierter param); und Initialize, PreInitialize, MonitorStep, MigrateToOpenBook, WithdrawSrm, SimulateInfo, AdminCancelOrders sind nicht mehr aufrufbar. On-Chain-Account-Layouts und Fehlercodes bleiben stabil; migrieren Sie Swaps zu den V2-Einstiegspunkten.Vollständigen Eintrag lesen →
​
Stable AMM: Toten OpenBook-(Market-)Code entfernen
Stable AMM entfernt seine lange ruhenden OpenBook-Market-Making-Konten und Code. Kleinere SwapBaseIn/SwapBaseOut (18 → 9), Deposit (14 → 12) und Withdraw (21/22 → 12) Layouts (alte Layouts immer noch kompatibel); ein hart-breaking WithdrawPnl-Änderung (16 → 10, keine Kompatibilität); die Referral-Gebühr eingestellt; und eine vereinfachte Vault-only-Pool-Asset-Formel. Die meisten anderen Stable-Anweisungen sind nicht mehr aufrufbar.Vollständigen Eintrag lesen →
​
CLMM: Limit-Orders, einseitige Gebühr, dynamische Gebühr
Drei Opt-in-, rückwärtskompatible CLMM-Fähigkeiten: First-Class-Limit-Orders (mit einem limit_order_admin-Settle-Keeper), einseitige Gebühreneinziehung (CollectFeeOn) und eine volatilitätsverfolgbare dynamische Gebühr. Fügt CreateCustomizablePool, eine PoolState-Umgestaltung (Indexer-Breaking-Change), neue TickState-Felder, elf neue Fehlercodes (mit einer numerischen Verschiebung) und entsprechende SDK-/API-Ergänzungen hinzu.Vollständigen Eintrag lesen →
​
Erste Veröffentlichung
Erste öffentliche Veröffentlichung des Raydium-Dokumentationssatzes, verifiziert gegen Live-Mainnet-Beta-Bereitstellungen und @raydium-io/raydium-sdk-v2@0.2.42-alpha.Vollständigen Eintrag lesen →

​
Dokumentationskonventionen

  • Versionierung: Diese Dokumentation verwendet kalenderbasierte Versionierung (YYYY-MM-DD). Jedes Update fügt eine neue Eintragsseite und eine neue Zeile in der obigen Zeitleiste hinzu.
  • Eine Seite pro Release: Jede Release-Zusammenfassung befindet sich auf einer eigenen Seite unter reference/changelog/, sodass dieser Index kurz bleibt und jeder Eintrag unabhängig verlinkt werden kann.
  • Verifiziertes Datum: Jeder Eintrag dokumentiert, wann der Inhalt zuletzt gegen den On-Chain-/API-Status und den Programmquellcode überprüft wurde. Falls nicht angegeben, gehen Sie vom Hauptdatum des Eintrags aus.
  • Breaking Changes: Werden in einem eingerahmten Warnhinweis auf betroffenen Seiten hervorgehoben und im Eintrag gekennzeichnet.
  • Abdeckung: Dieses Changelog behandelt die Dokumentation selbst. Die eigene historische Zeitleiste des Protokolls befindet sich in introduction/history-and-milestones und ist die maßgebliche Quelle für „wann ist X auf Raydium passiert”.

​
Korrektionen

Wenn Sie einen Fehler in dieser Dokumentation finden, öffnen Sie bitte ein Issue oder einen Pull Request im Dokumentations-Repository. Korrektionen werden als Changelog-Einträge protokolliert.

​
Verweise