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.

​
Versionen

​
CLMM: Anchor 1.0, Überschuss-Lamports-Rückgewinnung und feste Fee-Owner
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 in CPMM und CLMM CPI durchführen kann. Ein neuer Admin CollectExcessLamports gibt Miete zurück, die durch SIMD-0437 freigegeben wurde. Es 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 Configs gespeichert sind, und bestehende Configs werden nicht neu geschrieben. 6052 angefügt. Keine benutzergerichtete Anweisung oder Kontolayout hat sich geändert.Vollständigen Eintrag lesen →
​
CPMM: Das Protokoll nimmt einen Anteil der Creator-Fee
CPMM kann jetzt einen Teil der Creator-Fee behalten. Die Aufteilung wird angewendet, wenn die Fee eingezogen wird, nicht wenn sie erhoben wird: Ein Swap sammelt weiterhin die gesamte Creator-Fee 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 kommt von einem neuen AmmConfig.creator_fee_share_rate (aus dem Padding geschnitten; das Konto ist immer noch 236 Bytes, aber das alte padding[0] ist jetzt ein Live-Feld) oder von einer Pro-Creator CreatorFeeShare PDA, die es überschreibt, verwaltet durch den neuen Admin CreateCreatorFeeShare / CloseCreatorFeeShare. Breaking für Creator-Fee-Clients: Beide Einzugsanweisungen nehmen neue Konten am Ende ihrer Listen an — bestehende Konten behalten ihre Positionen, aber die neuen sind obligatorisch, sodass eine Vor-Upgrade-Transaktion wegen fehlender Konten abgelehnt wird. UpdateAmmConfig erhält param = 8. PoolState, Swap-Mathematik und die k Prüfung sind 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 Überganggerüst 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-Entfernung, und das Programm initialisiert den Markt nicht mehr per CPI. Das get_upgrade_timestamp Clock-Gate ist gelöscht, sodass die drei Trade remaining_accounts bedingungslos erforderlich sind (mit dem system_program Slot jetzt validiert), MigrateToCpswap nimmt immer den genehmigten CPMM-Pfad, und InitializeWithToken2022 lässt seine amm_fee_on Einschränkung fallen. Ein neuer Admin CollectExcessLamports gibt Miete zurück, die durch SIMD-0437 freigegeben wurde — beachten Sie, dass Quellkonten nach welcher der drei Vault-Authority PDAs sie besitzt gruppiert werden müssen. Drei MigrateToCpswap Adressbeschränkungen wurden in den Anweisungstext verschoben, was 2012 zu 2502 ändert. 6031 angefügt. Keine Kontolayout-, Trade-Anweisung oder Fee-Verhalten hat sich geändert.Vollständigen Eintrag lesen →
​
CPMM: Anchor 1.0, Überschuss-Lamports-Rückgewinnung und feste Fee-Owner
CPMM wechselt zu Anchor 1.0.2 auf Agave 3.1.10 und fügt einen Admin CollectExcessLamports hinzu, der 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 (bestehende Configs werden nicht migriert — lesen Sie die Felder), die hardcodierte vier-Adressen Token-2022 MINT_WHITELIST wird entfernt, sodass die SupportMintAssociated Registry PDA der einzige verbleibende Bypass ist, und ClosePermissionPda akzeptiert jetzt die dedizierte Grant-Authority. 6015 angefügt. Keine benutzergerichtete Anweisung oder Kontolayout 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 einen Admin-Only WithdrawExcessLamports (Tag 18) hinzu, der 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 Version 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-Parameterbeschränkungen werden von PlatformConfig in Pro-Config PlatformCurveRule Konten verschoben. Eine Regel enthält bis zu 10 Prüfgruppen mit bis zu 25 (field, op, value) Beschränkungen über 19 Start-Parameter, mit Eq / Gte / Lte / Neq — sodass eine Plattform endlich ein Wertband, alternative Stufen, eine Graduierungs-Bewertungsobergrenze, einen Migrations-Boden, Token-Typ-Gating oder eine Gruppe ausdrücken kann, die sich an einem Datum umschaltet, was die Gleichheits-Only-Whitelist nicht konnte. PlatformConfig behält seine 944-Byte-Größe: restrict_curve_param, curve_rule_manager und das Längenpräfix des entfernten Vec kommen alle aus dem Padding. Decoder müssen das nachfolgende Vec<PlatformCurveParam> ablegen, und Start-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 angefügt. IDL-Aktualisierung erforderlich. Das SDK liefert zwei reine Off-Chain-Prüfungen, sodass ein Creator eine Regel nie 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-Authority von der Mint-Erstellung
InitializeWithToken2022 schreibt jetzt PlatformConfig.transfer_fee_extension_auth in die withdraw_withheld_authority des neuen Base-Mints statt der 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 Authority nur neu zu, wenn die PDA sie immer 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, sodass das Rotieren von transfer_fee_extension_auth während des Starts stillschweigend die beiden Authorities auf verschiedenen Schlüsseln lässt. Keine Kontolayout-, Anweisung-, Argument- oder Fehlercode-Änderung.Vollständigen Eintrag lesen →
​
LaunchLab: Plattform-Gebührensatz-Obergrenze auf 500 bps erhöht
Die Plattform fee_rate Obergrenze wechselt zu 50000 (500 bps) auf beiden Pfaden, die sie validieren. CreatePlatformConfig war seit der ersten Version 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 einem zulässigen Satz erstellt wurde, auch mit ihm 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 Kontolayout-, Anweisung- oder Fehlercode-Änderung, und keine bestehende Plattform oder Start 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 einem Token-2022 Mint quotiert werden. CreateConfig, InitializeV2, InitializeWithToken2022, die vier Swap-Anweisungen und jeder Fee-Anspruch akzeptieren entweder Tokenprogramm in ihrem Quote-Programm-Slot; das veraltete Initialize bleibt Legacy-Only. Swap-Slippage-Grenzen werden jetzt gegen das verglichen, was der Zahler tatsächlich zahlt oder erhält, netto der Transfergebühr des Quote-Mints. PoolState.token_program_flag Bit1 wird aussagekräftig, sodass Decoder, die das ganze Byte gegen 0 testen, einen Legacy-Base-Mint als Token-2022 falsch lesen. 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 Plattform-Config-Kontrollen
Neue Start-Initialisierung erfordert jetzt CPMM, während Legacy-AMM-v4-gebundener Status migrierbar bleibt. Vor dieser Version produzierte creator_scale einen Creator-eigenen Fee-Schlüssel; CPMM-Migrationen, die nach dem Upgrade ausgeführt wurden, konsolidieren stattdessen platform_scale + creator_scale in einen Plattform-eigenen Fee-Schlüssel-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 Emittenten-Position NFT-Einfrierung
Neue CLMM-Position NFT-Mints verwenden ihren Pool als Freeze-Authority, aber ihre Token-Konten bleiben standardmäßig nicht eingefroren. Das Einfrieren tritt nur bei OpenPositionV2 oder OpenPositionWithToken22Nft auf, wenn die Freeze-Authority eines der zugrunde liegenden Vault-Mints der Restricted-Issuer-Liste entspricht. Eine übereinstimmende Position kann nicht übertragen oder den Besitzer wechseln, kann aber immer noch Liquidität verwalten. Sein ClosePosition Aufruf muss den Pool anhängen, damit CLMM atomisch auftauen, brennen und schließen kann. Bestehende Positionen bleiben unverändert.Vollständigen Eintrag lesen →
​
CPMM: Genehmigungslose Creator-Fee-Einziehung
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-Authority, 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 Whitelisted-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 geschnitten, keine Größenänderung). Separat nimmt OpenLimitOrder jetzt die Output-Side-Konten 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 + neu nummerierte param); und Initialize, PreInitialize, MonitorStep, MigrateToOpenBook, WithdrawSrm, SimulateInfo, AdminCancelOrders sind nicht mehr aufrufbar. On-Chain-Kontolayouts 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-Fee 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, Single-Sided Fee, Dynamic Fee
Drei Opt-In, rückwärtskompatible CLMM-Fähigkeiten: First-Class Limit Orders (mit einem limit_order_admin Settle Keeper), Single-Sided Fee Collection (CollectFeeOn) und eine Volatilitäts-Tracking Dynamic Fee. 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). Jede Aktualisierung fügt eine neue Eintragseite und eine neue Zeile oben in der Zeitleiste hinzu.
  • Eine Seite pro Version: Jede Versionszusammenfassung lebt auf ihrer eigenen Seite unter reference/changelog/, sodass dieser Index kurz bleibt und jeder Eintrag unabhängig verlinkt werden kann.
  • Verifizierungsdatum: Jeder Eintrag dokumentiert, wann der Inhalt zuletzt gegen On-Chain / API-Status und die Programmquelle abgeglichen wurde. Falls nicht angegeben, gehen Sie vom Hauptdatum des Eintrags aus.
  • Breaking Changes: Werden in einer Warnbox auf betroffenen Seiten hervorgehoben und im Eintrag gekennzeichnet.
  • Abdeckung: Dieses Changelog behandelt die Dokumentation selbst. Die historische Zeitleiste des Protokolls selbst lebt in introduction/history-and-milestones und ist die Quelle der Wahrheit 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