Changelog

Datierter Überblick über Aktualisierungen dieser Dokumentation. Einträge erfassen, welche Kapitel sich geändert haben, warum die Änderungen vorgenommen wurden und wann die Inhalte zuletzt gegen On-Chain-Status und Programmquellencode überprüft wurden.

Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.

Englische Version ansehen →

Dies ist das Changelog der Dokumentation — der Überblick über Aktualisierungen dieser Seiten seit der Live-Schaltung des Projekts. Für die geschichtliche Zeitleiste des Protokolls selbst siehe introduction/history-and-milestones. Jeder Eintrag hier enthält ein Datum, eine Liste betroffener Kapitel, den Grund für die Änderung und ein Überprüfungsdatum, das anzeigt, wann On-Chain-Status und Programmquellencode zuletzt gegen die schriftliche Dokumentation abgeglichen wurden.

​

2026-05-18 — CLMM: Limit Orders, Single-Sided Fee, Dynamic Fee

Die nächste CLMM-Version fügt drei Funktionen auf Pool-Ebene hinzu. Diese sind bei der Pool-Erstellung optional aktivierbar und rückwärtskompatibel mit bestehenden Pools und Positionen.

​

TL;DR für Integratoren

• Limit Orders sind nun erstklassige CLMM-Primitive. LPs können eine Limit Order auf einem Tick in einem Pool eröffnen, der sie unterstützt. Die Order wird FIFO gefüllt, wenn ein Swap den Tick kreuzt, und ein Off-Chain-Keeper (limit_order_admin) kann die gefüllte Ausgabe abrechnen, ohne dass der Inhaber online sein muss. Sieben neue SDK-Methoden (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) und drei neue Temp-API-Endpoints unter /limit-order/ (aktive Orders, Benutzerhistorie, PDA-Ereignislog) decken den gesamten Ablauf ab.
• Single-Sided Fee (CollectFeeOn) ermöglicht einem Pool, Swap-Gebühren von der Eingabenseite (Legacy, Modus 0) oder immer von token_0 (Modus 1) oder immer von token_1 (Modus 2) zu erheben. Nützlich, wenn eine Seite des Paares das kanonische Abrechnungs-Token ist.
• Dynamic Fee ermöglicht einem Pool, eine volatilitätsabhängige Gebührenaufschlag zu aktivieren, die sich mit schnellen Tick-Bewegungen erhöht und mit der Zeit abnimmt, kalibriert durch eine Pro-Tier-DynamicFeeConfig und eine Pool-spezifische DynamicFeeInfo. Der neue /main/clmm-dynamic-config Endpoint zeigt die Tier-Liste.
• Eine neue Instruktion, CreateCustomizablePool, macht alle drei Optionen bei der Pool-Erstellung verfügbar. Das klassische CreatePool funktioniert weiterhin für Standard-Fee- und No-Limit-Order-Pools.
• Indexer Breaking Change: Die pro-Richtungs-Volumenzähler (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) und Lebenszeit-Gebührenzähler (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) auf PoolState wurden in Padding ausgelagert, um Platz für fee_on und dynamic_fee_info zu schaffen. Indexer, die diese Felder direkt lesen, müssen auf den On-Chain-Observation-Ring oder die API migrieren.

​

Warum dies wichtig ist (für Trader, LPs und Integratoren)

• Trader erhalten engere Quotes auf Long-Tail- und ereignisgesteuerten Paaren: Dynamic Fee ermöglicht dem Pool, Volatilitätszuschläge vom Taker zu absorbieren, ohne dass LPs aktiv Ranges erweitern müssen, und Limit-Order-Leitern vertiefen die On-Chain-Liquidität an spezifischen Preisen ohne breite Kapitalverpflichtung.
• LPs erhalten eine dritte Strategie neben konzentrierten Ranges und Full-Range-Positionen: genaue Preisorders parken, gefüllt werden, wenn der Preis diese besucht, in das Quote-Token abrechnen. Kein aktives Rebalancing erforderlich für den gefüllten Anteil.
• Integratoren können Dynamic-Fee-Pools deterministisch modellieren — Algorithmus und Parameter sind vollständig On-Chain, die Kalibrierungs-Tiers sind abfragbar, und der Swap-Pfad bleibt unverändert in der Form (nur die Gebühr pro Schritt variiert).

​

Was sich im Programm geändert hat

​

Neue Konten

• DynamicFeeConfig — Pro-Tier-Kalibrierungsdatensatz (Filterperiode, Zerfallperiode, Reduktionsfaktor, Dynamic-Fee-Kontrolle, maximaler Volatilitäts-Akkumulator). Erstellt von CreateDynamicFeeConfig (Admin), referenziert von CreateCustomizablePool, wenn Dynamic Fee aktiviert ist.
• LimitOrderState — Pro-Order-Konto (PDA-Seeds: [owner, limit_order_nonce, order_nonce]) mit Pool, Tick, Seite, Eingabemenge, ungefülltem Verhältnis, FIFO-Kohorten-Phase und Verwaltungs-Snapshots. Der Lebenszyklus ist implizit (filled_amount vs total_amount, plus Kontoexistenz): Open → Filled → Settled → Closed.
• LimitOrderNonce — Pro-(owner, nonce_index) monoton inkrementierender Zähler, der die Limit-Order-PDA-Seeds erhält. Der nonce_index: u8 ermöglicht dem gleichen Owner, Orders in bis zu 256 unabhängige Nonce-Ströme zu unterteilen.

Siehe Accounts → DynamicFeeConfig and DynamicFeeInfo und Accounts → LimitOrderState.

​

PoolState Umstrukturierung

Feldgruppe	Altes Layout	Neues Layout
Pro-Richtungs-Volumenzähler	swap_in_amount_token_0, swap_out_amount_token_0, swap_in_amount_token_1, swap_out_amount_token_1	In padding5: [u128; 4] integriert
Lebenszeit-Gebührenzähler	total_fees_token_0, total_fees_claimed_token_0, total_fees_token_1, total_fees_claimed_token_1	In padding6: [u64; 4] integriert
Single-Sided Fee	—	fee_on: u8 (0 = FromInput, 1 = Token0Only, 2 = Token1Only)
Dynamic Fee	—	dynamic_fee_info: DynamicFeeInfo (eingebettet)

Die Gesamtkontogröße bleibt unverändert. Indexer: Schalten Sie die Volumenverfolgung von PoolState auf den Observation-Ring oder die API um. Die eingestellten Zähler werden auf bestehenden Pools nicht auf Null gesetzt (sie enthalten, was sie zuletzt trugen), sodass das erneute Lesen nach dem Upgrade veraltete Daten zurückgibt.

​

TickState Ergänzungen (keine Breaking Change)

Am Ende von TickState werden vier neue Felder hinzugefügt und ersetzen etwas seines hinteren Paddings:

• order_phase: u64 — Zähler, der Limit-Order-Kohorten an diesem Tick disambiguiert.
• orders_amount: u64 — Gesamteingabe, die von allen offenen Orders an diesem Tick verpflichtet ist (nicht alle sind vollständig ungefüllt).
• part_filled_orders_remaining: u64 — Eingabe, die in der Kohorte noch ungefüllt ist und derzeit von Swaps verbraucht wird.
• unfilled_ratio_x64: u128 — Q64.64 Verhältnis zur Berechnung des Füllungsanteils jeder Order.

Tick-Array-Layout, Größe und PDA-Seeds bleiben unverändert.

​

Neue Instruktionen

• CreateDynamicFeeConfig (Admin) — erstelle eine kalibrierte DynamicFeeConfig Tier. Autorität: gleiches Treasury-Multisig wie CreateAmmConfig.
• UpdateDynamicFeeConfig (Admin) — aktualisiere Parameter einer bestehenden Tier.
• CreateCustomizablePool — Pool-Erstellungs-Entry-Point, der collect_fee_on, enable_dynamic_fee und dynamic_fee_config verfügbar macht. Existiert neben CreatePool; wir empfehlen CreateCustomizablePool für jeden neuen Pool, der die neuen Optionen benötigt.
• OpenLimitOrder — eröffne eine Single-Tick-Limit-Order. Erhöht LimitOrderNonce, belegt LimitOrderState, ordnet die Order in die FIFO-Kohorte am Tick ein.
• IncreaseLimitOrder / DecreaseLimitOrder — passe den ungefüllten Anteil einer Order an. Setzt mit InvalidOrderPhase zurück, wenn die Order vollständig gefüllt ist.
• SettleLimitOrder — räume gefüllte Ausgabe auf das ATA des Inhabers ein. Aufrufer kann der Owner oder der limit_order_admin-Keeper des Pools sein.
• CloseLimitOrder — schließe eine vollständig abgerechnete Order, um Miete zurückzufordern.

​

SwapV2 Verhaltensänderungen

Der Swap-Pfad bleibt unverändert in der Form, aber drei Dinge passieren jetzt entlang des Weges:

1. Dynamic Fee (wenn aktiviert): Das Pool-DynamicFeeInfo wird bei jedem Schritt aktualisiert (Zerfall → Akkumulation → Obergrenze), und der resultierende Zuschlag wird auf die Basis-Gebühr für diesen Schritt addiert.
2. Limit-Order-Matching (wenn der Schritt einen initialisierten Tick kreuzt, der offene Orders hat): Teil der Swap-Eingabe wird FIFO verbraucht, um die Kohorte an diesem Tick zu füllen, mit unfilled_ratio_x64, das atomar aktualisiert wird.
3. Single-Sided-Fee-Routing (wenn fee_on != 0): die Gebühr wird von token_0 oder token_1 unabhängig von der Swap-Richtung entnommen, anstatt immer von der Eingabenseite.

Jedes dieser ist eine No-Op, wenn der Pool mit den Legacy-Standardwerten erstellt wurde. Siehe Instructions → SwapV2 für die aktualisierte Zustandsänderungsmatrix.

​

Neue Fehlercodes

Das ErrorCode-Enum wurde in dieser Version umbenannt: fünf Legacy-Varianten (LOK, ZeroMintAmount, InvalidLiquidity, TransactionTooOld, InvalidRewardDesiredAmount) wurden entfernt, und elf neue Varianten wurden angehängt. Da Anchor Fehler nach Enum-Reihenfolge ab 6000 nummeriert, hat sich jeder Fehlercode an oder nach den entfernten Positionen verschoben — Clients, die numerische Codes hart codiert haben, müssen neu zuordnen.

Die neuen Codes sind:

• 6040 OrderAlreadyFilled
• 6041 InvalidOrderPhase
• 6042 InvalidLimitOrderAmount
• 6043 OrderPhaseSaturated
• 6044 InvalidDynamicFeeConfigParams
• 6045 InvalidFeeOn
• 6046 ZeroSqrtPrice
• 6047 ZeroLiquidity
• 6048 MissingBaseFlag
• 6049 MissingMintAccount
• 6050 MissingTokenProgram2022

Vollständige Strings und die Tabelle nach Verschiebung für alle CLMM-Fehler sind in Error codes.

​

Was sich im SDK (@raydium-io/raydium-sdk-v2) geändert hat

• Neue Methoden auf raydium.clmm: createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
• Neue REST-Helfer auf raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Neue Typen: CollectFeeOn enum, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Interne Reorganisation: utils/ wurde zu libraries/ verschoben. Das Package-Barrel bleibt unverändert; nur tiefe Importe unter @raydium-io/raydium-sdk-v2/utils/... müssen auf …/libraries/... aktualisiert werden.

End-to-End-TypeScript-Walkthroughs sind in products/clmm/code-demos.

​

Was sich in den APIs geändert hat

• api-v3 — zwei neue Endpoints unter /main/:
  • GET /main/clmm-dynamic-config — Liste von DynamicFeeConfig-Tiers.
  • GET /main/clmm-limit-order-config — Pro-Pool-Limit-Order-Konfiguration.
• temp-api-v1 — drei neue Endpoints unter /limit-order/:
  • GET /limit-order/order/list?wallet=… — aktuell geparkte Orders einer Wallet (offen und teilweise gefüllt, aus dem Redis-Cache des Indexers bedient; das gleiche Payload deckt beide Phasen über totalAmount / filledAmount / pendingSettle ab).
  • GET /limit-order/history/order/list-by-user?wallet=… — historische Limit Orders einer Wallet. Optionale Filter: poolId, mint1, mint2, hideCancel. Cursor-paginiert via nextPageId / size (max 100).
  • GET /limit-order/history/event/list-by-pda?pda=… — Pro-PDA-Ereignislog (open / increase / decrease / settle / close) für eine oder mehrere komma-getrennte Limit-Order-PDAs. Cursor-paginiert via nextPageId / size (max 100).

Alle fünf sind im API Reference Tab dokumentiert.

​

Authority-Oberfläche

Der limit_order_admin ist ein Off-Chain-Betriebskeeper, kein Multisig. Er kann nur SettleLimitOrder und CloseLimitOrder auf bestehenden Orders aufrufen, und die Ausgabe eines Settlements landet immer im ATA des Inhabers. Er kann Pool-Felder nicht mutieren, Orders nicht eröffnen oder ändern oder für etwas anderes signieren. Siehe Admin keys and multisig → CLMM.

​

Aktualisierte Seiten

• products/clmm/overview — neuer „What’s new”-Bereich und aktualisierte Nächste-Schritte-Zeiger.
• products/clmm/accounts — drei neue Konten, PoolState-Umstrukturierung mit Migrationsbefund, TickState-Ergänzungen, neue PDA-Helfer.
• products/clmm/instructions — sieben neue Instruktionen, SwapV2-Verhaltensergänzung, aktualisierte Zustandsänderungsmatrix.
• products/clmm/fees — Single-Sided-Fee-Bereich, Dynamic-Fee-Bereich mit Parametertabelle.
• products/clmm/math — Limit-Order-Matching-Pseudocode, Dynamic-Fee-Ableitung.
• products/clmm/code-demos — createCustomizablePool-Demo, vollständiger Limit-Order-Walkthrough, neue Fallstricke.
• algorithms/clmm-math — Kreuzverweis auf Limit-Order-Matching und Dynamic Fee in der Multi-Tick-Swap-Schleife.
• sdk-api/typescript-sdk — CLMM-Modul-Ergänzungen-Bereich, utils/ → libraries/-Migrationsbefund.
• api-reference/openapi/api-v3.yaml — zwei neue Endpoints mit Response-Schemas.
• api-reference/openapi/temp-api-v1.yaml — drei neue Limit-Order-Endpoints (/limit-order/order/list, /limit-order/history/order/list-by-user, /limit-order/history/event/list-by-pda) mit ihren Request- und Response-Schemas.
• api-reference/api-v3/overview — Hinweis auf die neuen CLMM-Config-Endpoints.
• api-reference/temp-api-v1/overview — Hinweis auf die neuen Active-Orders-, History-by-User- und Event-by-PDA-Endpoints.
• reference/error-codes — elf neue CLMM-Fehlercodes (6040–6050) plus fünf entfernte Legacy-Codes; numerische Codes nach den Entfernungspunkten haben sich verschoben.
• security/admin-and-multisig — neue DynamicFeeConfig-Admin-Zeile und limit_order_admin-Keeper-Zeile mit Erklärung begrenzte Autorität.

Überprüft gegen:

• raydium-clmm-Quelle.
• @raydium-io/raydium-sdk-v2-Quelle.
• api-v3 und temp-api-v1-Quelle.

​

2026-04-26 — Erste Veröffentlichung

Erste öffentliche Veröffentlichung des Raydium-Dokumentationssatzes.

Überprüft gegen:

• Live-Programm-Deployments auf Solana mainnet-beta.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• Öffentliche Raydium-Dokumentation und On-Chain-Referenzen bis April 2026.

Von nun an landen jedes Protokoll-Upgrade, jede Überprüfung oder Dokumentationsrevision als neuer Eintrag in dieser Datei.

​

Dokumentationskonventionen

• Versionierung: Diese Dokumentation verwendet kalenderbasierte Versionierung (YYYY-MM-DD). Jede Aktualisierung erstellt einen neuen Eintrag oben in der Datei.
• Überprüfungsdatum: Jeder Eintrag erfasst, wann die Inhalte zuletzt gegen On-Chain-/API-Status und die Programmquelle abgeglichen wurden. Falls nicht angegeben, gehen Sie vom Hauptdatum des Eintrags aus.
• Breaking Changes: Hervorgehoben in einem eingerahmten Befund auf betroffenen Seiten und mit Tags in dem Eintrag unten gekennzeichnet.
• Abdeckung: Dieses Changelog deckt die Dokumentationsmenge selbst ab. Die geschichtliche Zeitleiste des Protokolls selbst lebt in introduction/history-and-milestones und ist die Wahrheitsquelle für „wann ist X auf Raydium passiert”.

​

Korrektionen

Falls Sie einen Fehler in dieser Dokumentation entdecken, öffnen Sie bitte ein Issue oder Pull Request im Dokumentations-Repository. Korrektionen werden in diesem Changelog protokolliert.

​

Zeiger

• introduction/history-and-milestones — die Zeitleiste des Protokolls selbst.
• security/audits — Audit-Verlauf.
• ray/protocol-fees — Protokoll-Fee-Splits.
• reference/program-addresses — Program-ID-Quelle-der-Wahrheit.