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

# What is Dynamic Fee Sharing?

> Learn how Meteora Dynamic Fee Sharing lets teams fund a token vault and split claimable fees across a small fixed recipient set.

## Overview

Dynamic Fee Sharing is Meteora's on-chain fee distribution program. It lets a team create a fee vault for one token mint, configure a fixed list of recipients and shares, fund the vault, and let each recipient claim their share directly on-chain.

It is a distribution layer for splitting funded token balances across **2 to 5** configured recipient entries.

<Info>
  Dynamic Fee Sharing runs on the mainnet program `dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh`.
</Info>

## Why Dynamic Fee Sharing Exists

Many on-chain fee streams need to be split between a small group: creators, launchpads, protocol treasuries, strategy operators, partners, or contributors. Without a dedicated vault, teams often collect fees into one wallet and reconcile payouts manually.

Dynamic Fee Sharing moves that split into program state:

* The recipient addresses and share weights are stored in the fee vault.
* Fees are added to a program-controlled token vault.
* Each funding event increases cumulative `fee_per_share` accounting.
* Each recipient claims by index, and the program tracks that recipient's checkpoint.

## Core Features

<CardGroup cols={2}>
  <Card title="Fixed Share Splits" icon="chart-pie" iconType="solid">
    A vault stores 2 to 5 recipient entries, each with a wallet address, share amount, and claim checkpoint.
  </Card>

  <Card title="Self-Serve Claims" icon="hand-holding-dollar" iconType="solid">
    Recipients claim independently by signing with the wallet configured at their recipient index.
  </Card>

  <Card title="Two Funding Paths" icon="coins" iconType="solid">
    Vaults can be funded manually. PDA vaults can also fund through whitelisted DAMM v2 and Dynamic Bonding Curve claim actions.
  </Card>

  <Card title="Token Support" icon="certificate" iconType="solid">
    Vaults support standard SPL Token mints and Token 2022 mints that only use supported extensions.
  </Card>
</CardGroup>

## How Dynamic Fee Sharing Works

The program has three main concepts.

| Component   | What It Stores                                                                                                                                       |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fee vault   | Owner field, token mint, token vault, vault type, base account, total shares, total funded fees, cumulative fee per share, and up to 5 user entries. |
| Token vault | The program-controlled token account that holds funded tokens before claims.                                                                         |
| User entry  | A recipient address, share amount, total fee claimed, and fee-per-share checkpoint.                                                                  |

A vault lifecycle is short:

```text theme={"system"}
Initialize a fee vault for one token mint
        |
Store 2-5 user entries and non-zero shares
        |
Fund the token vault manually or through a supported claim action
        |
Recipients claim by index with their configured wallet
```

## Fee Vault Types

Dynamic Fee Sharing supports two fee vault types. Both use the same share and claim accounting after initialization.

| Vault Type        | How It Is Used                                                                                                               |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Non-PDA fee vault | A standalone vault initialized from an externally generated signer account. Best for manual funding.                         |
| PDA fee vault     | A deterministic vault derived from `["fee_vault", base, token_mint]`. Required for whitelisted claim-by-integration funding. |

## Important Constraints

| Constraint          | Program Behavior                                                                                                            |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Recipient entries   | Minimum `2`, maximum `5`.                                                                                                   |
| Shares              | Each share must be greater than `0`.                                                                                        |
| Recipient addresses | Each address must be non-default. The program does not reject duplicate addresses.                                          |
| Token mint          | One token mint per vault.                                                                                                   |
| Updates             | The current program exposes no general instruction to edit recipients, edit shares, withdraw admin funds, or close a vault. |
| Owner field         | `owner` is stored and emitted, but current instructions do not use it as an admin authority.                                |
| Claim authorization | A claim succeeds only when the signer matches the user entry at the provided index.                                         |

<Warning>
  Treat the initialized recipient list and shares as permanent for that fee vault. If a split changes, create a new vault for the new arrangement.
</Warning>

## What To Read Next

<CardGroup cols={2}>
  <Card title="Dynamic Fee Sharing Design Guide" href="/helper-products/dynamic-fee-sharing/design-guide" icon="sliders" iconType="solid">
    Choose the recipient set, shares, token mint, vault type, and funding path before initialization.
  </Card>

  <Card title="Dynamic Fee Sharing Compatibilities" href="/helper-products/dynamic-fee-sharing/compatibilities" icon="plug" iconType="solid">
    Review token support, vault types, source programs, and whitelisted claim actions.
  </Card>
</CardGroup>

<CardGroup cols={1}>
  <Card title="Dynamic Fee Sharing Formulas" href="/helper-products/dynamic-fee-sharing/formulas" icon="calculator" iconType="solid">
    Understand fee-per-share accounting, fixed-point precision, rounding, and Token 2022 transfer-fee behavior.
  </Card>
</CardGroup>

## Who Dynamic Fee Sharing Is For

<AccordionGroup>
  <Accordion title="Protocol teams">
    Protocol teams can route revenue into a fee vault and distribute it to contributors, treasuries, integrations, or strategic partners without manual payout operations.
  </Accordion>

  <Accordion title="Launchpads and creators">
    Launchpads and creators can use Dynamic Fee Sharing to split eligible launch revenue between creator, partner, protocol, or campaign wallets.
  </Accordion>

  <Accordion title="Ecosystem partners">
    Partners can receive their share directly from a vault instead of waiting for a centralized operator to reconcile and send payouts.
  </Accordion>

  <Accordion title="Integrators and dashboards">
    Integrators can track funded fees, claim events, recipient allocations, and vault balances as a clear on-chain revenue stream.
  </Accordion>
</AccordionGroup>

## What Dynamic Fee Sharing Is Best For

Dynamic Fee Sharing is best when a single supported token needs to be split between a small, known, stable recipient set.

Good use cases include:

* Creator and launchpad fee sharing.
* Treasury-funded partner splits.
* DAMM v2 fee or reward sharing through supported claim actions.
* Dynamic Bonding Curve creator, partner, trading-fee, or migration-fee sharing through supported claim actions.
* Campaign or contributor revenue splits where the recipient set is fixed.