> ## Documentation Index
> Fetch the complete documentation index at: https://docs.meteora.ag/llms.txt
> Use this file to discover all available pages before exploring further.

# Dynamic Fee Sharing Compatibilities

> Review Dynamic Fee Sharing limits, supported token mints, vault types, funding paths, and whitelisted source-program actions.

Dynamic Fee Sharing is intentionally narrow. This page is the compatibility reference for what the current program accepts.

## Compatibility Overview

| Area                                 | Supported                                                     |
| ------------------------------------ | ------------------------------------------------------------- |
| Recipient count                      | 2 to 5 recipients per fee vault                               |
| Share values                         | Non-zero `u32` shares for each user entry                     |
| Recipient address                    | Non-default public key                                        |
| Token standard                       | SPL Token and Token 2022 mints with supported extensions only |
| Vault types                          | Non-PDA fee vault and PDA fee vault                           |
| Funding methods                      | Manual funding and supported claim-by-integration funding     |
| Claim-by-integration source programs | Whitelisted DAMM v2 and Dynamic Bonding Curve actions         |

## Recipient Limits

A fee vault supports **2 to 5 recipients**.

Each recipient needs:

* A wallet address.
* A non-zero share value.
* A recipient index used when claiming.

The program rejects the default public key as a recipient address. It does not reject duplicate recipient addresses, so clients and teams should treat uniqueness as an operational requirement unless duplicate entries are intentional.

<Warning>
  The program stores the configured recipient list in the fee vault and does not expose a general edit-recipient or edit-share instruction.
</Warning>

## Token Compatibility

Dynamic Fee Sharing can distribute fees in one token mint per vault.

Supported token types include:

* Standard SPL Token mints.
* Token 2022 mints with supported extensions.

For Token 2022, the program accepts mints whose extension list contains only:

* `TransferFeeConfig`
* `MetadataPointer`
* `TokenMetadata`

If a Token 2022 mint uses any other extension, initialization fails with `InvalidMint`.

<Info>
  If a project wants to split fees for multiple token mints, it should create one fee vault per token mint.
</Info>

## Vault Types

Dynamic Fee Sharing supports two fee vault types.

| Vault Type        | Compatible With                                               | Best For                                                |
| ----------------- | ------------------------------------------------------------- | ------------------------------------------------------- |
| Non-PDA fee vault | Manual fee funding                                            | Standalone fee-sharing agreements.                      |
| PDA fee vault     | Manual fee funding and supported claim-by-integration funding | Protocol-integrated fee sharing tied to a base account. |

## Funding Paths

Dynamic Fee Sharing supports two funding paths.

### Manual Funding

Manual funding works for both Non-PDA and PDA fee vaults.

A funder signs for the source token account. The program transfers `min(max_amount, source_balance)` into the token vault, records the net amount for supported transfer-fee mints, and updates fee-per-share accounting.

### Funding by Claiming Fees

Funding by claiming fees works for PDA fee vaults and only for whitelisted source-program actions.

The vault calls a supported fee-claim action, receives claimed tokens into its token vault, and then adds the token-vault balance increase to fee-sharing accounting.

Additional requirements:

* The `source_program` and instruction discriminator must match a whitelisted action.
* The whitelisted token-vault account index must point to the fee vault's token vault.
* The signer must be one of the configured share-holder addresses.
* The fee vault must be a PDA vault.

## Compatible Source Programs and Actions

Dynamic Fee Sharing currently whitelists supported actions from DAMM v2 and DBC.

### DAMM v2

Supported DAMM v2 claim actions include:

| Whitelisted Action | Token Vault Account Index | Product Meaning                                                |
| ------------------ | ------------------------- | -------------------------------------------------------------- |
| `ClaimPositionFee` | `4`                       | Claim trading fees from a DAMM v2 position into the fee vault. |
| `ClaimReward`      | `5`                       | Claim DAMM v2 reward emissions into the fee vault.             |

### Dynamic Bonding Curve (DBC)

Supported DBC claim and withdrawal actions include:

| Whitelisted Action       | Token Vault Account Index | Product Meaning                                     |
| ------------------------ | ------------------------- | --------------------------------------------------- |
| `CreatorWithdrawSurplus` | `3`                       | Route creator surplus into the fee vault.           |
| `ClaimCreatorTradingFee` | `3`                       | Route creator trading fees into the fee vault.      |
| `PartnerWithdrawSurplus` | `3`                       | Route partner surplus into the fee vault.           |
| `ClaimTradingFee`        | `4`                       | Route eligible DBC trading fees into the fee vault. |
| `WithdrawMigrationFee`   | `3`                       | Route eligible migration fees into the fee vault.   |

<Note>
  The token-vault index is part of the program's whitelist check. If an integration changes account ordering, Dynamic Fee Sharing must whitelist the matching action and account index before that claim path works.
</Note>

## What Is Not a Fit

Dynamic Fee Sharing may not be the right product when:

* The recipient set changes frequently.
* There are more than 5 recipients.
* The token mint uses unsupported Token 2022 extensions.
* The fee source requires an unsupported cross-program claim action.
* The payout requires complex conditional logic instead of fixed shares.
* The setup needs owner-managed edits, admin withdrawals, or vault closure through the current program.

For those cases, teams should either use manual operational flows or build a custom distribution layer around their requirements.