> ## 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-09-13 — CPMM: Das Protokoll behält einen Anteil der Creator-Gebühr

> CPMM kann nun einen konfigurierbaren Anteil der Creator-Gebühr einbehalten, angewendet bei der Erhebung statt bei der Berechnung. AmmConfig erhält creator_fee_share_rate (aus dem Padding geschnitten, gleiche Größe), ein neues CreatorFeeShare-PDA überschreibt es pro Creator, und CreateCreatorFeeShare / CloseCreatorFeeShare verwalten es. Beide CollectCreatorFee-Pfade ändern ihre Kontolisten — Breaking Change für bestehende Clients. UpdateAmmConfig erhält Parameter 8. Keine neuen Fehlercodes, keine PoolState-Änderung, Swap-Mathematik unverändert.

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

  [Englische Version ansehen →](/reference/changelog/2026-09-13-cpmm-creator-fee-protocol-share)
</Info>

<Info>
  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.
</Info>

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:** `8` → `creator_fee_share_rate`.
* **Keine neuen Fehlercodes.** Die neuen Pfade verwenden `InvalidOwner` (`6001`), `InvalidInput` (`6003`) und `MathOverflow` (`6011`) erneut. `6000`–`6015` 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:

```rust theme={null}
// states/creator_fee_share.rs
shared_amount  = floor(creator_fee * share_rate / 1_000_000);
creator_amount = creator_fee - shared_amount;
```

```rust theme={null}
// states/pool.rs — PoolState::settle_creator_fee
self.protocol_fees_token_i = self.protocol_fees_token_i.checked_add(shared_amount_i)?;
self.creator_fees_token_i  = 0;
// creator_amount_i wird zurückgegeben und an den Creator übertragen
```

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.

<Note>
  **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.
</Note>

## Kontolisten-Änderungen

`CollectCreatorFee` — eine Einfügung:

| #   | Vorher                                             | Nachher                                              |
| --- | -------------------------------------------------- | ---------------------------------------------------- |
| 1–4 | `creator`, `authority`, `pool_state`, `amm_config` | unverändert                                          |
| 5   | `token_0_vault`                                    | **`creator_fee_share`** (neu)                        |
| 6.. | —                                                  | `token_0_vault` und alles danach, um eins verschoben |

`CollectCreatorFeePermissionless` — zwei Einfügungen:

| #   | Vorher                                        | Nachher                                              |
| --- | --------------------------------------------- | ---------------------------------------------------- |
| 1–4 | `payer`, `creator`, `authority`, `pool_state` | unverändert                                          |
| 5   | `token_0_vault`                               | **`amm_config`** (neu)                               |
| 6   | `token_1_vault`                               | **`creator_fee_share`** (neu)                        |
| 7.. | —                                             | `token_0_vault` und alles danach, um zwei verschoben |

<Warning>
  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.
</Warning>

Vollständige Kontotabellen in [`products/cpmm/instructions`](/de/products/cpmm/instructions#collectcreatorfee).

## `CreateCreatorFeeShare` und `CloseCreatorFeeShare`

```rust theme={null}
pub struct CreatorFeeShare {
    pub bump: u8,
    pub creator: Pubkey,
    pub amm_config: Pubkey,
    pub share_rate: u64,
    pub padding: [u64; 8],
}
// CreatorFeeShare::LEN == 145
```

`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`](/de/reference/program-addresses#cpmm-creator-fee-share-authority).

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

```rust theme={null}
Some(8) => update_creator_fee_share_rate(amm_config, value),   // asserts value <= 1_000_000
```

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.** `6000`–`6015` 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-comparison` — `creator_fee_share_rate` als vierter CPMM-Satz mit einer anderen Basis hervorgehoben.