Changelog

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

​

Unveröffentlicht — CLMM: Limit Orders, einseitige Gebühr, dynamische Gebühr

​

TL;DR für Integratoren

• Limit Orders sind jetzt erstklassige CLMM-Primitive. LPs können eine Single-Tick-Order in einem Pool eröffnen, der diese unterstützt; die Order wird FIFO befüllt, wenn ein Swap den Tick kreuzt, und ein Off-Chain-Keeper (limit_order_admin) kann den gefüllten Output abrechnen, ohne dass der Eigentümer online sein muss. Sieben neue SDK-Methoden (openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, closeLimitOrder, closeAllLimitOrder, settleAllLimitOrder) und drei neue Temp-API-Endpunkte unter /limit-order/ (aktive Orders, Verlauf pro Nutzer, Ereignisprotokoll pro PDA) decken den gesamten Ablauf ab.
• Einseitige Gebühr (CollectFeeOn) ermöglicht es einem Pool, Swap-Gebühren von der Eingabeseite zu erheben (Legacy, Modus 0), immer von token_0 (Modus 1) oder immer von token_1 (Modus 2). Nützlich, wenn eine Seite des Paares das kanonische Buchungstoken ist.
• Dynamische Gebühr ermöglicht es einem Pool, einen volatilitätsverfolgenden Aufschlag zu aktivieren, der mit schneller Tick-Bewegung steigt und über die Zeit abklingt, kalibriert durch eine DynamicFeeConfig pro Tier und eine DynamicFeeInfo pro Pool. Der neue Endpunkt /main/clmm-dynamic-config liefert die Tier-Liste.
• Eine neue Instruktion, CreateCustomizablePool, macht alle drei Parameter bei der Pool-Erstellung zugänglich. Das klassische CreatePool funktioniert weiterhin für Pools mit Standard-Gebühren ohne Limit Orders.
• Breaking Change für Indexer: Die richtungsbezogenen Volumen-Zähler (swap_in_amount_token_{0,1}, swap_out_amount_token_{0,1}) und die lebenslangen Gebühren-Zähler (total_fees_token_{0,1}, total_fees_claimed_token_{0,1}) in PoolState wurden in Padding überführt, 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 das wichtig ist (für Trader, LPs und Integratoren)

• Trader erhalten engere Quotes bei Long-Tail- und ereignisgetriebenen Paaren: Die dynamische Gebühr ermöglicht es dem Pool, Volatilitätsaufschläge vom Taker zu absorbieren, ohne dass LPs ihre Ranges aktiv ausweiten müssen, und Limit-Order-Leitern vertiefen On-Chain-Liquidität zu bestimmten Preisen, ohne kapitalintensive Range-weite Positionen einzugehen.
• LPs erhalten eine dritte Strategie neben konzentrierten Ranges und Full-Range-Positionen: exakte Preisorders parken, bei Preisbesuch gefüllt werden, in das Quote-Token abrechnen. Kein aktives Rebalancing für den gefüllten Anteil erforderlich.
• Integratoren können Pools mit dynamischer Gebühr deterministisch modellieren — Algorithmus und Parameter sind vollständig On-Chain, die Kalibrierungs-Tiers sind abfragbar, und der Swap-Pfad ist in seiner Form unverändert (nur die Gebühr pro Schritt variiert).

​

Was sich im Programm geändert hat

​

Neue Accounts

• DynamicFeeConfig — Kalibrierungsdatensatz pro Tier (Filterperiode, Abklingperiode, Reduktionsfaktor, Dynamische-Gebühr-Steuerung, maximaler Volatilitätsakkumulator). Erstellt durch CreateDynamicFeeConfig (Admin), referenziert durch CreateCustomizablePool bei aktivierter dynamischer Gebühr.
• LimitOrderState — Account pro Order (PDA-Seeds: [owner, limit_order_nonce, order_nonce]), der Pool, Tick, Seite, Eingabebetrag, ungefülltes Verhältnis, FIFO-Kohortephase und Buchungs-Snapshots enthält. Der Lebenszyklus ist implizit (filled_amount vs. total_amount plus Account-Existenz): Open → Filled → Settled → Closed.
• LimitOrderNonce — monoton steigender Zähler pro (Owner, Nonce-Index), der die Limit-Order-PDA-Seeds erhält. Der nonce_index: u8 erlaubt es demselben Owner, Orders in bis zu 256 unabhängige Nonce-Streams zu partitionieren.

​

PoolState-Umstrukturierung

​

TickState-Ergänzungen (kein Breaking Change)

• order_phase: u64 — Zähler zur Unterscheidung von Limit-Order-Kohorten an diesem Tick.
• orders_amount: u64 — Gesamter Eingabebetrag aller offenen Orders an diesem Tick (nicht alle davon sind vollständig ungefüllt).
• part_filled_orders_remaining: u64 — Noch ungefüllter Eingabebetrag in der Kohorte, die gerade von Swaps konsumiert wird.
• unfilled_ratio_x64: u128 — Q64.64-Verhältnis zur Berechnung des Füllungsanteils jeder Order.

​

Neue Instruktionen

• CreateDynamicFeeConfig (Admin) — Erstellt einen kalibrierten DynamicFeeConfig-Tier. Berechtigung: dasselbe Treasury-Multisig wie CreateAmmConfig.
• UpdateDynamicFeeConfig (Admin) — Aktualisiert die Parameter eines bestehenden Tiers.
• CreateCustomizablePool — Pool-Erstellungs-Einstiegspunkt, der collect_fee_on, enable_dynamic_fee und dynamic_fee_config exponiert. Koexistiert mit CreatePool; wir empfehlen CreateCustomizablePool für jeden neuen Pool, der die neuen Parameter benötigt.
• OpenLimitOrder — Eröffnet eine Single-Tick-Limit-Order. Erhöht LimitOrderNonce, allokiert LimitOrderState, fügt die Order in die FIFO-Kohorte am Tick ein.
• IncreaseLimitOrder / DecreaseLimitOrder — Passt den ungefüllten Anteil einer Order an. Gibt bei einer vollständig gefüllten Order InvalidOrderPhase zurück.
• SettleLimitOrder — Überweist gefüllten Output in das ATA des Eigentümers. Der Aufrufer kann der Eigentümer oder der limit_order_admin-Keeper des Pools sein.
• CloseLimitOrder — Schließt eine vollständig abgerechnete Order, um die Miete zurückzufordern.

​

Verhaltensänderungen bei SwapV2

1. Dynamische Gebühr (wenn aktiviert): Die DynamicFeeInfo des Pools wird bei jedem Schritt aktualisiert (Abklingen → Akkumulieren → Begrenzen), und der resultierende Aufschlag wird zusätzlich zur Basisgebühr für diesen Schritt addiert.
2. Limit-Order-Matching (wenn der Schritt einen initialisierten Tick mit offenen Orders kreuzt): Ein Teil des Swap-Inputs wird FIFO verbraucht, um die Kohorte an diesem Tick zu füllen, wobei unfilled_ratio_x64 atomar aktualisiert wird.
3. Einseitiges Gebühren-Routing (wenn fee_on != 0): Die Gebühr wird unabhängig von der Swap-Richtung von token_0 oder token_1 erhoben, anstatt immer von der Eingabeseite.

​

Neue Fehlercodes

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

​

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

• Neue Methoden auf raydium.clmm: createCustomizablePool, openLimitOrder, increaseLimitOrder, decreaseLimitOrder, settleLimitOrder, settleAllLimitOrder, closeLimitOrder, closeAllLimitOrder.
• Neue REST-Hilfsmethoden auf raydium.api: getClmmDynamicConfigs, getClmmLimitOrderConfigs.
• Neue Typen: CollectFeeOn-Enum, DynamicFeeConfig, DynamicFeeInfo, LimitOrderState, LimitOrderConfig.
• Interne Umstrukturierung: utils/ wurde nach libraries/ verschoben. Der Paket-Barrel ist unverändert; nur tiefe Imports unter @raydium-io/raydium-sdk-v2/utils/... müssen auf …/libraries/... aktualisiert werden.

​

Was sich in den APIs geändert hat

• api-v3 — zwei neue Endpunkte unter /main/:
  • GET /main/clmm-dynamic-config — Liste der DynamicFeeConfig-Tiers.
  • GET /main/clmm-limit-order-config — Limit-Order-Konfiguration pro Pool.
• temp-api-v1 — drei neue Endpunkte unter /limit-order/:
  • GET /limit-order/order/list?wallet=… — Aktuell geparkter Orders einer Wallet (offen und teilweise gefüllt, aus dem Redis-Cache des Indexers geliefert; derselbe 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 über nextPageId / size (max. 100).
  • GET /limit-order/history/event/list-by-pda?pda=… — Ereignisprotokoll pro PDA (open / increase / decrease / settle / close) für eine oder mehrere kommagetrennte Limit-Order-PDAs. Cursor-paginiert über nextPageId / size (max. 100).

​

Berechtigungsumfang

​

Aktualisierte Seiten

• products/clmm/overview — neuer Abschnitt „Was ist neu” und aktualisierte Verweise auf nächste Schritte.
• products/clmm/accounts — drei neue Accounts, PoolState-Umstrukturierung mit Migrationswarnung, TickState-Ergänzungen, neue PDA-Hilfsfunktionen.
• products/clmm/instructions — sieben neue Instruktionen, SwapV2-Verhaltensanhang, aktualisierte Zustandsänderungsmatrix.
• products/clmm/fees — Abschnitt zur einseitigen Gebühr, Abschnitt zur dynamischen Gebühr mit Parametertabelle.
• products/clmm/math — Limit-Order-Matching-Pseudocode, Herleitung der dynamischen Gebühr.
• products/clmm/code-demos — createCustomizablePool-Demo, vollständiger Limit-Order-Walkthrough, neue Fallstricke.
• algorithms/clmm-math — Querverweise auf Limit-Order-Matching und dynamische Gebühr in der Multi-Tick-Swap-Schleife.
• sdk-api/typescript-sdk — Abschnitt zu CLMM-Modul-Ergänzungen, Migrationshinweis utils/ → libraries/.
• api-reference/openapi/api-v3.yaml — zwei neue Endpunkte mit Response-Schemas.
• api-reference/openapi/temp-api-v1.yaml — drei neue Limit-Order-Endpunkte (/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-Konfigurations-Endpunkte.
• api-reference/temp-api-v1/overview — Hinweis auf die neuen Endpunkte für aktive Orders, Verlauf nach Nutzer und Ereignisse nach PDA.
• reference/error-codes — elf neue CLMM-Fehlercodes (6040–6050) sowie fünf entfernte Legacy-Codes; numerische Codes nach den Entfernungspunkten haben sich verschoben.
• security/admin-and-multisig — neue Admin-Zeile für DynamicFeeConfig und Keeper-Zeile für limit_order_admin mit Erläuterung des begrenzten Berechtigungsumfangs.

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

​

2026-04-26 — Erstveröffentlichung

• Live-Programmdeployments auf Solana Mainnet-Beta.
• @raydium-io/raydium-sdk-v2@0.2.42-alpha.
• Öffentliche Raydium-Dokumentation und On-Chain-Referenzen bis April 2026.

​

Dokumentationskonventionen

• Versionierung: Diese Dokumentation verwendet kalenderbasierte Versionierung (JJJJ-MM-TT). Jede Aktualisierung erzeugt einen neuen Eintrag am Anfang der Datei.
• Verifizierungsdatum: Jeder Eintrag gibt an, wann der Inhalt zuletzt gegen den On-Chain-/API-Zustand und den Programmquellcode abgeglichen wurde. Ist kein Datum angegeben, gilt das Hauptdatum des Eintrags.
• Breaking Changes: Auf betroffenen Seiten in einer hervorgehobenen Warnung ausgewiesen und im jeweiligen Eintrag gekennzeichnet.
• Abdeckung: Dieser Changelog bezieht sich auf den Dokumentationssatz selbst. Die eigene historische Zeitleiste des Protokolls befindet sich unter introduction/history-and-milestones und ist die maßgebliche Quelle dafür, „wann X auf Raydium passiert ist”.

​

Korrekturen

​

Verweise

• introduction/history-and-milestones — die eigene Zeitleiste des Protokolls.
• security/audits — Audit-Verlauf.
• ray/protocol-fees — Aufteilung der Protokollgebühren.
• reference/program-addresses — maßgebliche Quelle für Programm-IDs.