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.

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 TypeChoose This When
Non-PDA fee vaultThe vault is standalone and will be manually funded.
PDA fee vaultThe vault should be deterministic from base and token_mint, or it needs supported claim-by-integration funding.
If you are unsure and only need to transfer tokens into the vault manually, a Non-PDA fee vault is usually simpler.

​
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:
SplitShare Setup
50/5050 and 50
70/3070 and 30
80/15/580, 15, and 5
Basis points styleTotal shares add to 10,000
Use basis-points style shares when you want more precise allocations, such as 12.5% or 2.75%. 
12.5% = 1,250 shares out of 10,000
2.75% = 275 shares out of 10,000
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.

​
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 for the exact whitelisted actions and signer requirements.

​
Communicate the Vault Clearly

Before recipients rely on a fee vault, share the key details: 
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

A fee vault is tied to one token mint. Create separate vaults for separate fee tokens.
Recipient addresses are fixed. Prefer durable wallets such as treasuries or multisigs for long-lived revenue streams.
The program does not reject duplicate recipient addresses. Check the recipient list before initialization so dashboards, claims, and expectations are clear.
Dynamic Fee Sharing supports up to 5 recipients. If your payout design needs a large recipient set, use a different distribution approach.
The program supports a limited set of Token 2022 extensions. Check compatibility before creating the vault.
Claim-by-integration funding only works for whitelisted actions. Other revenue can still use manual funding.
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.
ScenarioRecommended Design
Simple partner splitNon-PDA vault, 2 recipients, manual funding.
Creator and launchpad revenuePDA vault if integrated with DBC, otherwise Non-PDA vault with manual funding.
DAMM v2 fee sharingPDA vault tied to the relevant base account and token mint.
Reward token sharingSeparate 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.