2026-08-31 — LaunchLab: Plattform-Kurvenregeln ersetzen die Kurvenparameter-Whitelist

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.

​

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<PlatformCurveParam> 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.
• 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.
• Ü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.

​

Was eine Regel ausdrücken kann, das die Whitelist nicht konnte

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. 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: 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.