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

​
CPMM: Das Protokoll behält einen Anteil der Creator-Gebühr
CPMM kann nun einen Teil der Creator-Gebühr behalten. Die Aufteilung wird angewendet, wenn die Gebühr eingezogen wird, nicht wenn sie berechnet 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 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 aktives Feld) oder von einer Pro-Creator-CreatorFeeShare-PDA, die es überschreibt und von den neuen Admin-Instruktionen CreateCreatorFeeShare / CloseCreatorFeeShare verwaltet wird. Breaking für Creator-Fee-Clients: Beide Einzugs-Instruktionen nehmen neue Konten auf, die am Ende ihrer Listen angehängt werden — bestehende Konten behalten ihre Positionen, aber die neuen sind verpflichtend, sodass eine Transaktion von vor dem Upgrade wegen fehlender Konten abgelehnt wird. UpdateAmmConfig erhält param = 8. PoolState, Swap-Mathematik und die k-Prüfung bleiben unverändert, und es wurde kein Fehlercode hinzugefügt. Mitgenommen: eine Zwei-Pass-Sortierungskorrektur in CollectExcessLamports.Vollständigen Eintrag lesen →
​
LaunchLab: Anchor 1.0, Excess-Lamports-Wiederherstellung und Ende der Übergangsgates
LaunchLab wechselt zu Anchor 1.0.2 auf Agave 3.1.10 und beendet sein Übergangssystem. Das veraltete Initialize schlägt nun bedingungslos mit NotApproved fehl. MigrateToAmm ist hart-breaking für die Migrations-Wallet: Alle drei Argumente und neun OpenBook-Konten sind weg, nach AMM v4s eigenem OpenBook-Entfernen, 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 nun validiert), MigrateToCpswap nimmt immer den berechtigten CPMM-Pfad, und InitializeWithToken2022 lässt seine amm_fee_on-Einschränkung fallen. Ein neuer Admin CollectExcessLamports gibt Miete zurück, die von SIMD-0437 freigegeben wurde — beachten Sie, dass Quellkonten nach welcher der drei Vault-Authority-PDAs sie besitzt gruppiert werden müssen. Drei MigrateToCpswap-Adresseinschränkungen wurden in den Instruktionstext verschoben, was 2012 zu 2502 ändert. 6031 angehängt. Keine Kontenlayout-, Trade-Instruktions- oder Gebührenverhalten änderte sich.Vollständigen Eintrag lesen →
​
CPMM: Anchor 1.0, Excess-Lamports-Wiederherstellung und korrigierte Gebühreneigentümer
CPMM wechselt zu Anchor 1.0.2 auf Agave 3.1.10 und fügt einen Admin CollectExcessLamports hinzu, der Miete zurückgibt, die von 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 kommen mit: CreateAmmConfig schreibt nun hartcodierte protocol_fee_owner- und fund_fee_owner-Schlüssel statt des Signers (bestehende Konfigurationen werden nicht migriert — lesen Sie die Felder), die hartcodierte vier-Adressen-Token-2022-MINT_WHITELIST wird entfernt, sodass die SupportMintAssociated-Registry-PDA der einzige verbleibende Bypass ist, und ClosePermissionPda akzeptiert nun die dedizierte Grant-Authority. 6015 angehängt. Keine benutzergerichtete Instruktion oder Kontenlayout änderte sich.Vollständigen Eintrag lesen →
​
AMM v4: Solana-3.0-Abhängigkeiten und Excess-Lamports-Wiederherstellung
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 ein Admin-Only-WithdrawExcessLamports (Tag 18) hinzu, das Miete zurückgibt, die von SIMD-0437 freigegeben wurde. Jede Trader- und LP-gerichtete Instruktion 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)-Einschränkungen über 19 Startparameter, mit Eq / Gte / Lte / Neq — sodass eine Plattform endlich ein Wertband, alternative Stufen, eine Graduierungs-Bewertungsobergrenze, einen Migrations-Untergrenze, 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 Vec kommen alle aus dem Padding. Decoder müssen das nachfolgende Vec<PlatformCurveParam> löschen, und Start-Builder müssen die Regel-PDA zu remaining_accounts anhängen, während das Flag an ist. Zwei Instruktionen 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 eine Regel nie aus einer zurückgewiesenen Transaktion lernen muss, und der Eintrag dokumentiert eine Devnet-Probe vor dem Aktivieren des Flags auf Mainnet.Vollständigen Eintrag lesen →
​
LaunchLab: Plattform hält die Withdraw-Withheld-Authority von der Mint-Erstellung
InitializeWithToken2022 schreibt nun PlatformConfig.transfer_fee_extension_auth in die neue Basis-Mint’s withdraw_withheld_authority 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-Instruktion. MigrateToCpswap weist diese Authority 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, sodass das Rotieren von transfer_fee_extension_auth während des Starts die beiden Authorities stillschweigend auf verschiedenen Schlüsseln lässt. Keine Kontenlayout-, Instruktions-, 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 nun überein, sodass eine Plattform, die mit einer beliebigen 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 umschreibt. Die beiden Pfade erheben immer noch unterschiedliche Fehler (InvalidInput bei Erstellung, InvalidPlatformInfo bei Aktualisierung). Keine Kontenlayout-, Instruktions- 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 nun in einer Token-2022-Mint notiert werden. CreateConfig, InitializeV2, InitializeWithToken2022, die vier Swap-Instruktionen und jeder Gebührenanspruch akzeptieren entweder Tokenprogramm in ihrem Quote-Programm-Slot; das veraltete Initialize bleibt nur Legacy. Swap-Slippage-Grenzen werden nun 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 bedeutsam, sodass Decoder, die das ganze Byte gegen 0 testen, eine Legacy-Basis-Mint als Token-2022 misslesen. 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-Konfigurationssteuerungen
Neue Start-Initialisierung erfordert nun CPMM, während Legacy-AMM-v4-gebundener Status migrierbar bleibt. Vor dieser Version produzierte creator_scale eine Creator-eigene Fee Key; CPMM-Migrationen, die nach dem Upgrade ausgeführt wurden, 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-Authority, aber ihre Token-Konten bleiben standardmäßig nicht eingefroren. Das Einfrieren erfolgt nur bei OpenPositionV2 oder OpenPositionWithToken22Nft, wenn die Freeze-Authority einer der zugrunde liegenden Vault-Mints mit der Restricted-Issuer-Liste übereinstimmt. Eine übereinstimmende Position kann nicht übertragen oder den Besitzer wechseln, kann aber immer noch Liquidität verwalten. Ihr ClosePosition-Aufruf muss den Pool anhängen, damit CLMM atomar auftauen, brennen und schließen kann. Bestehende Positionen bleiben unverändert.Vollständigen Eintrag lesen →
​
CPMM: Berechtigungslose Creator-Gebühreneinziehung
Eine additive CollectCreatorFeePermissionless-Instruktion 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: Berechtigte 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, sodass ein berechtigter Operator (einer, der eine Permission-PDA hält) mehrere Pools pro (config, mint0, mint1) erstellen kann — sodass eine Pool-ID nicht mehr kanonisch für ein Paar ist. Neue Admin-Instruktionen 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 nun 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-Instruktionen. SwapBaseIn / SwapBaseOut, Deposit und Withdraw behalten ihre Layouts (entfernte Market-Konten werden nun 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-Kontenlayouts 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); eine 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-Instruktionen 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-Gebühreneinziehung (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 verzeichnet, 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 den Dokumentationssatz 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