Skip to main content

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.

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

​
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

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.

​
How Dynamic Fee Sharing Works

The program has three main concepts.
ComponentWhat It Stores
Fee vaultOwner 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 vaultThe program-controlled token account that holds funded tokens before claims.
User entryA 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 TypeHow It Is Used
Non-PDA fee vaultA standalone vault initialized from an externally generated signer account. Best for manual funding.
PDA fee vaultA deterministic vault derived from ["fee_vault", base, token_mint]. Required for whitelisted claim-by-integration funding.

​
Important Constraints

ConstraintProgram Behavior
Recipient entriesMinimum 2, maximum 5.
SharesEach share must be greater than 0.
Recipient addressesEach address must be non-default. The program does not reject duplicate addresses.
Token mintOne token mint per vault.
UpdatesThe current program exposes no general instruction to edit recipients, edit shares, withdraw admin funds, or close a vault.
Owner fieldowner is stored and emitted, but current instructions do not use it as an admin authority.
Claim authorizationA 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.

​
Who Dynamic Fee Sharing Is For

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 can use Dynamic Fee Sharing to split eligible launch revenue between creator, partner, protocol, or campaign wallets.
Partners can receive their share directly from a vault instead of waiting for a centralized operator to reconcile and send payouts.
Integrators can track funded fees, claim events, recipient allocations, and vault balances as a clear on-chain revenue stream.

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