> ## 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.
# 2026-08-31 — LaunchLab: Plattform-Kurvenregeln ersetzen die Kurvenparameter-Whitelist
> Startparameter-Beschränkungen verschieben sich von PlatformConfig.curve_params in Pro-Konfiguration PlatformCurveRule-Konten mit (Feld, Operator, Wert)-Constraints, Wertbändern, ORed-Prüfgruppen und einer delegierten Manager-Wallet. PlatformConfig behält seine 944-Byte-Größe; das Legacy-Feld und seine zwei Instruktionen werden entfernt, und sieben Fehlercodes werden angehängt.
**Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.**
[Englische Version ansehen →](/reference/changelog/2026-08-31-launchlab-platform-curve-rules)
Dieser Eintrag behandelt ein bevorstehendes LaunchLab-Programm-Update. Er wurde vor der Bereitstellung gegen den lokalen Release-Branch überprüft. Bestätigen Sie das bereitgestellte Programm, bevor Sie sich auf die neuen Konten oder Instruktionen verlassen.
Eine Plattform konnte bereits einschränken, welche Startformen ihre Ersteller wählen dürfen, durch `PlatformConfig.curve_params`. Dieser Mechanismus testete **nur exakte Gleichheit**: Ein Eintrag fixierte entweder ein Feld auf einen Wert oder wildcard-ierte es mit einem Sentinel. Er enthielt auch höchstens 10 Einträge über alle `GlobalConfig`, die eine Plattform unterstützte, und er befand sich auf dem `PlatformConfig`-Konto selbst, wodurch es um 491 Bytes pro Eintrag wuchs.
Diese drei Eigenschaften kollidierten, als das Protokoll Konfigurationen hinzufügte. Um „ein Fundraising-Ziel zwischen 50 und 200 SOL" auszudrücken, brauchte man einen Eintrag pro zulässigem Wert und war daher unmöglich. Die eigenen Floors von `GlobalConfig` waren inzwischen weit geöffnet worden — 1-bps-Raten, 99999-Versorgungsgrenzen — genau damit jede Plattform unter ihnen passt, was Plattformen keine Möglichkeit ließ, sie zu verengen.
Dieses Release ersetzt die Whitelist durch **Kurvenregeln**: ein `PlatformCurveRule`-Konto pro (Plattform, Konfiguration)-Paar, das bis zu 10 Prüfgruppen enthält, jede mit bis zu 25 `(Feld, Operator, Wert)`-Constraints über 19 Startparameter, mit `Eq`, `Gte`, `Lte` und `Neq`. Constraints innerhalb einer Gruppe werden UND-verknüpft, Gruppen werden ODER-verknüpft. Ein Bereich ist ein `Gte` plus ein `Lte` auf demselben Feld.
Das vollständige Modell und neun durchgearbeitete Playbooks befinden sich auf der neuen Seite: [`products/launchlab/curve-rules`](/de/products/launchlab/curve-rules).
## TL;DR für Integratoren
* **`PlatformConfig` behält seine Größe und jeden bestehenden Feld-Offset.** Es ist eine feste 944 Bytes. `curve_params` ist weg; `restrict_curve_param` (`u8`), `curve_rule_manager` (`Pubkey`) und die 4 Bytes, die das Längenpräfix des Vektors belegte, kommen alle aus dem Padding, das von 107 auf 78 schrumpft.
* **Decoder müssen den nachfolgenden Vektor ablegen.** Ein Decoder, der nach dem Padding immer noch `Vec` erwartet, liest die zwei neuen Felder als Vektor-Bytes. Alles vor dem Padding ist unberührt, daher funktioniert ein Decoder, der nur Gebühren-Wallets und Raten liest, unverändert weiter.
* **Launch-Builder benötigen ein weiteres Konto, wenn das Flag an ist.** Während `restrict_curve_param` `1` ist, erfordern `InitializeV2` und `InitializeWithToken2022` die Regel-PDA in `remaining_accounts` — *auch wenn das Konto nicht existiert*, damit das Weglassen es nicht umgehen kann. Ableitung: `[b"platform_curve_rule", platform_config, global_config]`.
* **Keine Plattform ist standardmäßig eingeschränkt.** `restrict_curve_param` ist `0` auf jedem bestehenden Konto, und `0` bedeutet, dass das Programm Regeln überhaupt nicht liest.
* **Zwei Instruktionen werden entfernt:** `UpdatePlatformCurveParam` und `RemovePlatformCurveParam`. Vier werden hinzugefügt: `CreatePlatformCurveRule`, `UpdatePlatformCurveRule`, `RemovePlatformCurveRule`, `ClosePlatformCurveRule`.
* **`UpdatePlatformConfig` erhält zwei Varianten:** `RestrictCurveParam(u64)` bei Dispatch-Index 13 und `CurveRuleManager(Pubkey)` bei 14. Bestehende Indizes 0–12 sind unverändert.
* **Sieben Fehlercodes werden angehängt,** `6024`–`6030`. `6020` `CurveParamIsNotExist` wird als Platzhalter beibehalten, obwohl sein letzter Aufrufer weg ist, daher verschiebt sich nichts danach. Siehe [`reference/error-codes`](/de/reference/error-codes).
* **Eine IDL-Aktualisierung ist erforderlich.** Neuer Kontotyp, vier neue Instruktionen, zwei entfernt, zwei neue Dispatch-Varianten, sieben neue Fehlercodes.
* **Überprüfen Sie Regeln offline, bevor Sie etwas senden.** Das SDK stellt `checkLaunchAgainstCurveRule` bereit (spiegelt die Startzeit-Prüfung, Fail-Closed-Verhalten eingeschlossen) und `checkCurveRuleGroupWritable` (spiegelt die Schreib-Zeit-Validierung). Beide sind reine Funktionen. Siehe [Check before you send](/de/products/launchlab/curve-rules#check-before-you-send).
* **Üben Sie auf Devnet, bevor Sie auf Mainnet aktivieren.** Das Einschalten von `restrict_curve_param` ändert sofort, was Ihre Ersteller tun können. Die empfohlene Sequenz — einschließlich des Starts eines Tokens, der abgelehnt werden sollte, um zu beweisen, dass Ihr Builder wirklich die Regelprüfung besteht — befindet sich in [Test on devnet first](/de/products/launchlab/curve-rules#test-on-devnet-first).
## Was eine Regel ausdrücken kann, das die Whitelist nicht konnte
| Absicht | Whitelist | Kurvenregel |
| ------------------------------------------------------------------- | ------------------------ | -------------------------------------------------------- |
| Eine exakte Startform | Ein Eintrag | Eine Gruppe mit `Eq`-Constraints |
| Ein Fundraising-Ziel in einem Bereich | Nicht ausdrückbar | Zwei Constraints: `Gte` + `Lte` |
| Drei Start-Tiers | Drei Einträge, nur exakt | Drei Gruppen |
| Ein Graduierungs-Bewertungsband unabhängig von der Versorgung | Nicht ausdrückbar | Zwei Constraints auf der abgeleiteten `FundRaisingRateB` |
| Ein Floor für das, was in den graduierten Pool gelangt | Nicht ausdrückbar | Ein Constraint auf der abgeleiteten `MigrateRateA` |
| Nur SPL Token oder nur Token-2022 | Nicht ausdrückbar | Ein Constraint auf `BaseTokenProgram` |
| „Wenn eine Transfergebühr festgelegt ist, begrenzen Sie sie auf 1%" | Nicht ausdrückbar | Zwei Gruppen, gated auf `TransferFeeEnabled` |
| Eine Regel, die an einem Datum unbeaufsichtigt umschaltet | Nicht ausdrückbar | Zwei Gruppen, gated auf `UnixTimestamp` |
Die 19 Felder umfassen die vier abgeleiteten Raten — `SellRateA`, `LockRate`, `MigrateRateA`, `FundRaisingRateB` — was eine Regel über Versorgungen portierbar macht, anstatt an eine festgelegt zu sein.
## Delegierte Verwaltung
`PlatformConfig.curve_rule_manager` ist eine Hot Wallet, die die Regelkonten dieser Plattform erstellen, aktualisieren, entfernen und schließen kann. Das Bearbeiten von Regeln ist Routine und ein Plattform-Admin-Schlüssel ist normalerweise ein Multisig; dies ist das Feld, das das Multisig aus der Schleife hält. Legen Sie es einmal durch `UpdatePlatformConfig::CurveRuleManager` fest.
Der Plattform-Admin behält parallel die gleiche Macht — das Programm akzeptiert es durch Neuableitung der `PlatformConfig`-PDA vom Unterzeichner — daher ist ein verlorener Manager-Schlüssel durch Rotation des Feldes wiederherstellbar. `Pubkey::default()` bedeutet nur Admin.
Ein kompromittierter Manager-Schlüssel kann Parameter-Regeln lockern oder löschen und die Miete eines Regelkontos zurückfordern. Er kann `restrict_curve_param` nicht umschalten, keine Gebühren-Wallet, Vesting-Feld oder CPMM-Konfiguration berühren oder ein `GlobalConfig`-Limit brechen.
## Miete und Größe
Ein Regelkonto wird ohne Gruppe erstellt und bei jeder Änderung neu dimensioniert, daher zahlt eine Plattform für die Regeln, die sie tatsächlich geschrieben hat, und das Entfernen einer Gruppe erstattet die Differenz an den Unterzeichner.
| Regelinhalt | Größe | Miete |
| ----------------------------- | ----------- | ------------ |
| Leer | 150 Bytes | \~0,0019 SOL |
| 1 Gruppe, 2 Constraints | 200 Bytes | \~0,0023 SOL |
| 3 Gruppen, 4 Constraints je | 408 Bytes | \~0,0037 SOL |
| 10 Gruppen, 25 Constraints je | 4.790 Bytes | \~0,034 SOL |
Da die Größe dynamisch ist, müssen Decoder die tatsächliche Länge des Kontos lesen, anstatt eine Konstante anzunehmen.
## Compute-Kosten beim Start
Die Prüfung läuft bei jedem Start, während sie aktiviert ist. Gemessen von Ende zu Ende — PDA-Ableitung, `remaining_accounts`-Scan, Deserialisierung, Auswertung:
| Regelinhalt | Direkte Felder | Abgeleitete Felder |
| ----------------------------- | -------------- | ------------------ |
| Aktiviert, kein Regelkonto | 1.936 | — |
| 1 Gruppe, 2 Constraints | 2.576 | 2.926 |
| 3 Gruppen, 4 Constraints je | 3.624 | 5.724 |
| 10 Gruppen, 25 Constraints je | 24.344 | 68.094 |
Ein abgeleitetes Constraint kostet etwa 223 CU gegenüber etwa 48 für einen direkten Feldlesevorgang. Selbst eine vollständig geladene Regel bleibt unter einem Drittel des Standard-Budgets von 200.000 CU pro Instruktion. Gruppen werden ausgewertet, bis eine passt, daher gehört das am häufigsten verwendete Tier zuerst.
## Die einmalige Migration
Plattformen, die die Whitelist verwendeten, wurden vom Protokoll in einem einzigen Durchgang migriert, bevor das Flag verfügbar war, um es einzuschalten. Eine dedizierte Autorität führte eine Transaktion pro Plattform aus, die jeden Legacy-Eintrag in die Prüfgruppen des Regelkontos der Konfiguration, die er benannte, übersetzt, die Einträge aus `PlatformConfig` gelöscht und dieses Konto auf 944 Bytes zurückgeschrumpft hat.
Die Übersetzung bewahrte die alte Semantik genau: Jeder Eintrag wurde eine Gruppe, jedes Nicht-Sentinel-Feld wurde ein `Eq`-Constraint, und ein All-Sentinel-Eintrag — der jeden Start passte — wurde eine Gruppe ohne Constraints, die auch jeden Start passt.
Die Migration schrieb Regeln, aktivierte sie aber nicht. Eine migrierte Plattform blieb uneingeschränkt, bis sie `restrict_curve_param` selbst auf `1` setzte. Die Migrations-Instruktion wurde aus dem Programm entfernt, jetzt dass der Durchgang abgeschlossen ist, zusammen mit dem Legacy-Feld, das sie las.
## Was sich nicht geändert hat
* **`GlobalConfig`.** Gleiches Layout, gleiche Limits, gleiche Instruktionen. Regeln verengen diese Limits und werden zusammen mit ihnen überprüft; sie können niemals eines verbreitern.
* **Die Kontolisten und Argumente der Start-Instruktionen.** `InitializeV2` und `InitializeWithToken2022` nehmen die gleichen festen Konten und die gleichen Argumente. Nur `remaining_accounts` gewinnt einen Eintrag, und nur während das Flag an ist.
* **Handels-, Graduierungs-, Gebühren- und Vesting-Pfade.** Unberührt.
* **`PlatformAllowConfig`.** Unverändert und unabhängig: Es entscheidet, *welche Konfigurationen* die Starts einer Plattform verwenden dürfen, während eine Regel entscheidet, *welche Parameter* innerhalb einer Konfiguration. Die zwei Flags sind unabhängig.
* **Fehlercodes `6000`–`6023`.** Unverändert, `6020` eingeschlossen.
* **`PlatformConfig`'s Größe und Pre-Padding-Offsets.** Unverändert, daher benötigen bestehende Konten keine eigene Migration.
## Aktualisierte Seiten
* `products/launchlab/curve-rules` — **neue Seite.** Das dreiebenen Modell, die 19-Feld- und 4-Operator-Tabellen, neun Playbooks, die Kurventyp-Beschränkung, die zwei Offline-Prüfhelfer, die Devnet-Probe-Sequenz, delegierte Verwaltung, Miete, Rollout-Reihenfolge und Compute-Kosten.
* `products/launchlab/platform-config` — „Kurvenparameter-Whitelist" ersetzt durch „Start-Parameterregeln"; Layout aktualisiert für `restrict_curve_param`, `curve_rule_manager` und das 78-Byte-Padding; Update-Pfad-Tabelle, Read-Pfad-Snippet und Fallstricke umgeschrieben.
* `products/launchlab/instructions` — neuer Abschnitt „Plattform-Start-Parameterregeln" mit den vier Instruktionen, ihren Konten, Argumenten und Fehlern; Bestandszeile ersetzt.
* `products/launchlab/accounts` — `PlatformCurveRule` zum Bestand hinzugefügt und mit eigenem Abschnitt mit vollständigem Layout und Warnung zur variablen Größe versehen.
* `reference/error-codes` — `6024`–`6030` dokumentiert; `6018` und `6020` kommentiert.