> ## 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 Design Guide

> Choose Dynamic Fee Sharing recipients, shares, token mint, vault type, and funding method before initializing a fee vault.

Dynamic Fee Sharing is simple after initialization, so most design work happens before a vault is created. Use this page to turn a fee-sharing agreement into a vault configuration.

## Start With the Revenue Stream

Before configuring a vault, identify the fee stream you want to split.

Answer these questions first:

* What product or campaign generates the fees?
* Which token mint will the fees be paid in?
* Who should receive the fees?
* Are there 2 to 5 stable recipient entries?
* Will fees be manually funded or claimed from a compatible Meteora product?

A clear revenue stream makes the vault easier to design and easier for recipients to understand.

## Choose the Vault Type

| Vault Type        | Choose This When                                                                                                    |
| ----------------- | ------------------------------------------------------------------------------------------------------------------- |
| Non-PDA fee vault | The vault is standalone and will be manually funded.                                                                |
| PDA fee vault     | The vault should be deterministic from `base` and `token_mint`, or it needs supported claim-by-integration funding. |

<Info>
  If you are unsure and only need to transfer tokens into the vault manually, a Non-PDA fee vault is usually simpler.
</Info>

## Choose the Token Mint

A fee vault distributes one token mint.

If your revenue stream has multiple tokens, create separate vaults. For example:

* One vault for USDC fees.
* One vault for SOL fees.
* One vault for a reward token.

This keeps each vault's accounting clear and avoids mixing assets with different decimals, transfer behavior, or recipient expectations.

## Choose Recipients

Dynamic Fee Sharing supports 2 to 5 recipients.

Good recipient entries include:

* Creator wallet
* Launchpad wallet
* Treasury wallet
* Strategy operator wallet
* Campaign partner wallet
* Contributor multisig

Because the recipient list is fixed at creation, use durable wallets. For teams, a multisig or treasury-controlled wallet is usually better than a personal hot wallet.

The program rejects the default public key, but it does not reject duplicate recipient addresses. Unless duplicate entries are intentional, check for duplicates before initialization.

## Choose Shares

Shares are relative weights. They do not need to add up to 100, but percent-style totals are easier to communicate.

Common share patterns:

| Split              | Share Setup                |
| ------------------ | -------------------------- |
| 50/50              | 50 and 50                  |
| 70/30              | 70 and 30                  |
| 80/15/5            | 80, 15, and 5              |
| Basis points style | Total shares add to 10,000 |

Use basis-points style shares when you want more precise allocations, such as 12.5% or 2.75%.

```text theme={"system"}
12.5% = 1,250 shares out of 10,000
2.75% = 275 shares out of 10,000
```

<Note>
  The program stores each share and total shares as `u32` values. Choose a share scale that is precise enough for the agreement but still easy for humans to audit.
</Note>

## Choose the Funding Method

### Manual Funding

Manual funding is best when fees are collected outside the Dynamic Fee Sharing program or need to be batched before distribution.

Use manual funding for:

* Treasury distributions.
* Partner payouts.
* Revenue that arrives from off-chain operations.
* Unsupported fee sources.
* Campaign budgets.

### Funding by Claiming Fees

Funding by claiming fees is best when a PDA fee vault is integrated with a supported Meteora product action.

Use this path for:

* Supported DAMM v2 fee or reward claims.
* Supported DBC fee, surplus, or migration-fee claims.
* Product-native revenue sharing where the fee vault should receive claimable fees directly.

See [Compatibilities](/helper-products/dynamic-fee-sharing/compatibilities) for the exact whitelisted actions and signer requirements.

## Communicate the Vault Clearly

Before recipients rely on a fee vault, share the key details:

```text theme={"system"}
Fee vault address:
Token mint:
Vault type: Non-PDA / PDA
Base account, if PDA:
Recipient list:
Recipient shares:
Funding method: Manual / supported claim action
Recipient index for each recipient:
Expected funding cadence:
```

For public or partner-facing setups, a simple table of recipients and shares is usually enough.

If funding amounts are very small relative to total shares, tell recipients to claim only when their displayed claimable amount is greater than zero. The program advances a recipient checkpoint even when the rounded claim amount is zero.

## Avoid Common Mistakes

<AccordionGroup>
  <Accordion title="Using one vault for multiple tokens">
    A fee vault is tied to one token mint. Create separate vaults for separate fee tokens.
  </Accordion>

  <Accordion title="Choosing personal wallets for long-term splits">
    Recipient addresses are fixed. Prefer durable wallets such as treasuries or multisigs for long-lived revenue streams.
  </Accordion>

  <Accordion title="Accidentally duplicating a recipient address">
    The program does not reject duplicate recipient addresses. Check the recipient list before initialization so dashboards, claims, and expectations are clear.
  </Accordion>

  <Accordion title="Using too many recipients">
    Dynamic Fee Sharing supports up to 5 recipients. If your payout design needs a large recipient set, use a different distribution approach.
  </Accordion>

  <Accordion title="Assuming all Token 2022 mints are supported">
    The program supports a limited set of Token 2022 extensions. Check compatibility before creating the vault.
  </Accordion>

  <Accordion title="Expecting unsupported products to claim directly">
    Claim-by-integration funding only works for whitelisted actions. Other revenue can still use manual funding.
  </Accordion>

  <Accordion title="Treating owner as an admin">
    The fee vault stores an `owner` field, but the current instructions do not use it for editing recipients, changing shares, withdrawing funds, or closing the vault.
  </Accordion>
</AccordionGroup>

## Recommended Designs

| Scenario                      | Recommended Design                                                             |
| ----------------------------- | ------------------------------------------------------------------------------ |
| Simple partner split          | Non-PDA vault, 2 recipients, manual funding.                                   |
| Creator and launchpad revenue | PDA vault if integrated with DBC, otherwise Non-PDA vault with manual funding. |
| DAMM v2 fee sharing           | PDA vault tied to the relevant base account and token mint.                    |
| Reward token sharing          | Separate vault for the reward token mint.                                      |

## Pre-Launch Checklist

Before creating a fee vault, confirm:

* The token mint is correct.
* The token standard is supported.
* There are 2 to 5 recipients.
* Every recipient wallet is correct.
* Recipient addresses are unique unless duplicates are intentional.
* Every share is non-zero.
* The share split matches the agreement.
* The vault type matches the funding method.
* The `base` account can sign initialization if this is a PDA vault.
* A configured share-holder can sign claim-by-integration funding if needed.
* Recipients know how and when to claim.

Once those are true, the vault can become the on-chain source of truth for that fee split.