Skip to main content
Diese Seite wurde mit KI automatisch übersetzt. Maßgeblich ist stets die englische Version.Englische Version ansehen →
Dieser Eintrag behandelt ein bevorstehendes CPMM-Programm-Update. Er wurde vor der Bereitstellung gegen den lokalen Release-Branch (0dde43d, 11. September 2026) verifiziert. Bestätigen Sie das bereitgestellte Programm, bevor Sie sich auf die neuen Anweisungen oder die geänderten Kontolisten verlassen.
Die Creator-Gebühr von CPMM ging bisher vollständig an den Pool-Creator. Dieses Release ermöglicht es dem Protokoll, einen Anteil davon zu behalten — verhandelbar pro Gebührentier oder pro Creator auf einem Gebührentier — ohne zu ändern, wie die Gebühr berechnet wird. Die Designentscheidung, die den Blast-Radius klein hält: Die Aufteilung erfolgt bei der Erhebung, nicht beim Swap. Ein Swap berechnet weiterhin creator_fee_rate und sammelt den gesamten Betrag in creator_fees_token_{0,1} an. Wenn CollectCreatorFee oder CollectCreatorFeePermissionless ausgeführt wird, wird der angesammelte Saldo aufgeteilt, der Anteil des Protokolls wird als Protokollgebühr im selben Pool neu gekennzeichnet, und nur der Anteil des Creators verlässt den Vault. Quotes, die Kurve, k und alle LP-seitigen Pfade sind unberührt.

TL;DR für Integratoren

  • Beide Anweisungen zur Erhebung der Creator-Gebühr haben ihre Kontolisten geändert. Dies ist ein Breaking Change. CollectCreatorFee erhält creator_fee_share an Position 5. CollectCreatorFeePermissionless erhält amm_config an 5 und creator_fee_share an 6. Beide Einfügungen sitzen vor den Vaults, daher verschiebt sich alles danach. Erstellen Sie diese Transaktionen neu; patchen Sie sie nicht.
  • creator_fee_share muss auch dann übergeben werden, wenn es nicht existiert. Es wird mit einer Seed-Constraint deklariert, aber als unkontrolliertes Konto gelesen, daher muss die Adresse das kanonische PDA bei ["creator_fee_share", creator, amm_config] sein, während das Konto selbst optional ist. Wenn es leer ist, fällt das Programm auf AmmConfig.creator_fee_share_rate zurück.
  • AmmConfig erhält creator_fee_share_rate, geschnitten aus dem Padding. Das Konto ist immer noch 236 Bytes und jede bestehende Config deserialisiert weiterhin — aber das erste u64 des alten padding: [u64; 15] ist jetzt ein aktives Feld. Decoder, die den Tail als 15-Element-Array modellieren, lesen die Share-Rate als padding[0].
  • PoolState ist unverändert. 637 Bytes, gleiche Offsets, gleiche Felder. Der Anteil des Protokolls wird in die bestehenden protocol_fees_token_{0,1}-Zähler gebucht — es gibt keinen neuen Zähler und keine neue Erhebungsanweisung dafür.
  • protocol_fees_token* wächst nun außerhalb von Swaps. Jeder Monitor, der die Protokoll-Abgrenzung gegen das Handelsvolumen abgleicht, sieht Sprünge bei jeder Creator-Gebührenerhebung.
  • Ein Creator-Auszahlungs-Estimator, der creator_fees_token* liest, überschätzt nun. Multiplizieren Sie mit (1 − share_rate / 1_000_000), aufgelöst für das (creator, amm_config)-Paar.
  • Zwei Admin-Anweisungen werden hinzugefügt: CreateCreatorFeeShare und CloseCreatorFeeShare. Ein neuer UpdateAmmConfig-Parameter: 8creator_fee_share_rate.
  • Keine neuen Fehlercodes. Die neuen Pfade verwenden InvalidOwner (6001), InvalidInput (6003) und MathOverflow (6011) erneut. 60006015 sind unverändert.
  • Eine IDL-Aktualisierung ist erforderlich — zwei neue Anweisungen, ein neuer Kontotyp, zwei geänderte Kontolisten, ein neues Config-Feld.

Wie die Aufteilung funktioniert

Auflösung in Prioritätsreihenfolge:
  1. CreatorFeeShare-PDA bei ["creator_fee_share", creator, amm_config] — wenn das Konto existiert und von CPMM besessen wird, gewinnt sein share_rate.
  2. AmmConfig.creator_fee_share_rate — der Standard des Gebührentiers, sonst verwendet.
Beide sind u64 über FEE_RATE_DENOMINATOR_VALUE = 1_000_000 und beide werden gegen diese Obergrenze geprüft. Dann pro Token-Seite:
Drei Eigenschaften, die die Programm-Tests festlegen:
  • Rundung bevorzugt den Creator. Der Anteil wird abgerundet, daher bleibt der Staub beim Creator — die gleiche Richtung wie Fees::protocol_fee und Fees::fund_fee, die auch einen Anteil aus einer bereits angesammelten Gebühr schneiden. 20% einer 1-Unit-Gebühr sind 0, nicht 1.
  • Der Wert bleibt erhalten. creator_amount + shared_amount == creator_fee für jeden Satz und jede Gebühr bis u64::MAX.
  • share_rate = 0 ist genau das alte Verhalten. Sowohl der Standard-Config-Wert als auch ein fehlendes PDA geben dem Creator die gesamte Gebühr, daher ändert sich nichts für einen bestehenden Pool, bis ein Admin einen Satz festlegt.
Da protocol_fees_token* und creator_fees_token* beide bereits in vault_amount_without_fee subtrahiert werden, ändert das Verschieben von Wert zwischen ihnen nicht die Sicht der Kurve auf den Vault. Kein LP sieht eine Preisänderung über eine Creator-Gebührenerhebung hinweg, und die k-Prüfung ist unverändert.
Der Satz wird bei der Erhebung gelesen, nicht bei der Abgrenzung. Gebühren, die sich angesammelt haben, während der Satz 0 war, werden mit dem Satz abgerechnet, der gerade in Kraft ist, wenn jemand schließlich Collect* aufruft. Es gibt keinen Pro-Epoche- oder Pro-Swap-Snapshot.

Kontolisten-Änderungen

CollectCreatorFee — eine Einfügung: CollectCreatorFeePermissionless — zwei Einfügungen:
Keine der beiden Änderungen schlägt auf hilfreiche Weise fehl. Die eingefügten Konten befinden sich nicht am Ende der Liste, daher „fehlt” einem alten Client kein Konto — es übergibt dem Programm einen Vault, wo eine Config erwartet wird, und die Transaktion schlägt bei der Deserialisierung fehl. Regenerieren Sie aus der neuen IDL und überprüfen Sie, dass jede SDK-Version, die Sie festlegen, die neuen Konten trägt, bevor Sie sie auf das aktualisierte Programm verweisen.
Vollständige Kontotabellen in products/cpmm/instructions.

CreateCreatorFeeShare und CloseCreatorFeeShare

CreateCreatorFeeShare(share_rate: u64) initialisiert das PDA; CloseCreatorFeeShare schließt es und gibt die Miete an den Unterzeichner zurück. Beide akzeptieren den gemeinsamen Programm-Admin oder einen dedizierten Creator-Fee-Share-Owner — ein neuer hardcodierter Schlüsselpaar nach dem gleichen Devnet/Mainnet-cfg-Muster wie die anderen delegierten Autoritäten des Programms. Adressen in reference/program-addresses. Beachtenswerte Punkte:
  • Der Pool-Creator ist keine Partei für eine der beiden Anweisungen und unterzeichnet nicht. Das creator-Konto ist unkontrolliert — das PDA kann für einen Schlüssel erstellt werden, der noch keinen Pool besitzt.
  • Ein Konto deckt ein (creator, amm_config)-Paar ab, daher regelt es jeden Pool, den dieser Creator auf diesem Gebührentier besitzt. Ein Creator mit Pools auf zwei Tiers benötigt zwei Konten, um auf beiden abgedeckt zu sein.
  • Es gibt keinen Update-Pfad. init schlägt bei einer zweiten Erstellung für das gleiche Paar fehl; um einen Satz zu ändern, schließen und neu erstellen.

UpdateAmmConfig-Parameter 8

Legt den Standard-Anteil des Gebührentiers fest. Es ist unabhängig von protocol_fee_rate (Parameter 1), das die Handels-Gebühr aufteilt — ein Punkt, auf den in Admin-Tools zu achten ist, da die beiden ähnlich aussehen und beide in protocol_fees_token* landen.

Mitfahrer

CollectExcessLamports-Reihenfolge-Fix. Die Anweisung macht nun zwei Durchläufe über remaining_accounts — zuerst jeden Token-Programm-CPI, dann die direkten Belastungen von CPMM-eigenen PDAs — statt in Aufrufer-Reihenfolge zu versenden. Das Verschachteln der beiden brach mit der UnbalancedInstruction-Laufzeit ab („Summe der Kontostände vor und nach der Anweisung stimmen nicht überein”), wann immer ein PDA vor einem CPI belastet wurde, da die ausstehenden Lamport-Änderungen des Aufrufers nur in die Konten geleert werden, die ein CPI tatsächlich trägt. Die Schnittstelle der Anweisung ist unverändert; Aufrufer übergeben Quellen immer noch in beliebiger Reihenfolge, und jetzt ist das wirklich sicher. Verifiable-Build-Metadaten. Die Workspace-Cargo.toml deklariert [workspace.metadata.cli] solana = "3.1.10", daher löst ein verifizierbarer Build die gleiche Solana CLI auf, gegen die das Programm erstellt wurde. Keine On-Chain-Auswirkung.

Was sich nicht geändert hat

  • PoolState — 637 Bytes, gleiche Felder, gleiche Offsets. Der Anteil des Protokolls verwendet den bestehenden Protokoll-Bucket, statt Zähler hinzuzufügen.
  • AmmConfig::LEN — immer noch 236 Bytes.
  • Swap-Mathematik, Quoting und die k-Prüfung. Die Creator-Gebühr wird genau wie zuvor berechnet.
  • CollectProtocolFee / CollectFundFee — gleiche Konten, gleiche Unterzeichner. CollectProtocolFee hat einfach mehr zu erheben.
  • Fehlercodes. 60006015 unverändert; nichts angehängt.
  • Jede andere Anweisung und die Programm-ID.

Aktualisierte Seiten

  • products/cpmm/fees — neuer Abschnitt „Protokoll-Anteil der Creator-Gebühr” mit Satzauflösung, Aufteilungsarithmetik, Rundung und Integrator-Konsequenzen; creator_fee_share_rate zur Sätze/Einheiten-Liste und zur Standardparameter-Tabelle hinzugefügt; Erhebungsfluss-Tabelle überarbeitet.
  • products/cpmm/instructions — Breaking-Change-Warnung oben; vollständige Kontotabellen für beide Creator-Fee-Pfade; neue CreateCreatorFeeShare- und CloseCreatorFeeShare-Abschnitte; UpdateAmmConfig-Parameter 8; CollectExcessLamports-Reihenfolge-Notiz; Zusammenfassungs- und Zustandsänderungs-Matrix-Zeilen.
  • products/cpmm/accounts — neuer CreatorFeeShare-Kontoabschnitt; AmmConfig-Layout und Padding-Schnitt-Warnung; PoolState-Gebühren-Zähler-Notizen; Konto-Lebenszyklus-Zeilen.
  • products/cpmm/overview — Creator-Fee-Callout und die Bullet „Vorhersehbare Gebühren”.
  • products/cpmm/math — eine Notiz, dass die Aufteilung absichtlich aus der Swap-Mathematik fehlt.
  • products/cpmm/code-demos — Warnung, dass Pre-Upgrade-SDK-Builder die alten Kontolisten ausgeben; Snippet für angesammelte Gebühren kommentiert.
  • reference/program-addresses — neuer Abschnitt „CPMM-Creator-Fee-Share-Autorität”; creator_fee_share zum PDA-Seed-Block hinzugefügt.
  • reference/fee-comparisoncreator_fee_share_rate als vierter CPMM-Satz mit einer anderen Basis hervorgehoben.