What is Dynamic Fee Sharing?

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.

Dynamic Fee Sharing runs on the mainnet program dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh.

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

Fixed Share Splits

A vault stores 2 to 5 recipient entries, each with a wallet address, share amount, and claim checkpoint.

Self-Serve Claims

Recipients claim independently by signing with the wallet configured at their recipient index.

Two Funding Paths

Vaults can be funded manually. PDA vaults can also fund through whitelisted DAMM v2 and Dynamic Bonding Curve claim actions.

Token Support

Vaults support standard SPL Token mints and Token 2022 mints that only use supported extensions.

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:

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.

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.

Dynamic Fee Sharing Design Guide

Choose the recipient set, shares, token mint, vault type, and funding path before initialization.

Dynamic Fee Sharing Compatibilities

Review token support, vault types, source programs, and whitelisted claim actions.

Dynamic Fee Sharing Formulas

Understand fee-per-share accounting, fixed-point precision, rounding, and Token 2022 transfer-fee behavior.

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.

Launchpads and creators

Launchpads and creators can use Dynamic Fee Sharing to split eligible launch revenue between creator, partner, protocol, or campaign wallets.

Ecosystem partners

Partners can receive their share directly from a vault instead of waiting for a centralized operator to reconcile and send payouts.

Integrators and dashboards

Integrators can track funded fees, claim events, recipient allocations, and vault balances as a clear on-chain revenue stream.

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.

User Guides

Core Products

Helper Products

Legacy Products

Overview

Core Features

Fixed Share Splits

Self-Serve Claims

Two Funding Paths

Token Support

Fee Vault Types

Important Constraints

What To Read Next

Dynamic Fee Sharing Design Guide

Dynamic Fee Sharing Compatibilities

Dynamic Fee Sharing Formulas

​Overview

​Why Dynamic Fee Sharing Exists

​Core Features

Fixed Share Splits

Self-Serve Claims

Two Funding Paths

Token Support

​How Dynamic Fee Sharing Works

​Fee Vault Types

​Important Constraints

​What To Read Next

Dynamic Fee Sharing Design Guide

Dynamic Fee Sharing Compatibilities

Dynamic Fee Sharing Formulas

​Who Dynamic Fee Sharing Is For

​What Dynamic Fee Sharing Is Best For

Overview

Why Dynamic Fee Sharing Exists

Core Features

How Dynamic Fee Sharing Works

Fee Vault Types

Important Constraints

What To Read Next

Who Dynamic Fee Sharing Is For

What Dynamic Fee Sharing Is Best For