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 intentionally narrow. This page is the compatibility reference for what the current program accepts.

​
Compatibility Overview

AreaSupported
Recipient count2 to 5 recipients per fee vault
Share valuesNon-zero u32 shares for each user entry
Recipient addressNon-default public key
Token standardSPL Token and Token 2022 mints with supported extensions only
Vault typesNon-PDA fee vault and PDA fee vault
Funding methodsManual funding and supported claim-by-integration funding
Claim-by-integration source programsWhitelisted DAMM v2 and Dynamic Bonding Curve actions

​
Recipient Limits

A fee vault supports 2 to 5 recipients. Each recipient needs:
  • A wallet address.
  • A non-zero share value.
  • A recipient index used when claiming.
The program rejects the default public key as a recipient address. It does not reject duplicate recipient addresses, so clients and teams should treat uniqueness as an operational requirement unless duplicate entries are intentional.
The program stores the configured recipient list in the fee vault and does not expose a general edit-recipient or edit-share instruction.

​
Token Compatibility

Dynamic Fee Sharing can distribute fees in one token mint per vault. Supported token types include:
  • Standard SPL Token mints.
  • Token 2022 mints with supported extensions.
For Token 2022, the program accepts mints whose extension list contains only:
  • TransferFeeConfig
  • MetadataPointer
  • TokenMetadata
If a Token 2022 mint uses any other extension, initialization fails with InvalidMint.
If a project wants to split fees for multiple token mints, it should create one fee vault per token mint.

​
Vault Types

Dynamic Fee Sharing supports two fee vault types.
Vault TypeCompatible WithBest For
Non-PDA fee vaultManual fee fundingStandalone fee-sharing agreements.
PDA fee vaultManual fee funding and supported claim-by-integration fundingProtocol-integrated fee sharing tied to a base account.

​
Funding Paths

Dynamic Fee Sharing supports two funding paths.

​
Manual Funding

Manual funding works for both Non-PDA and PDA fee vaults. A funder signs for the source token account. The program transfers min(max_amount, source_balance) into the token vault, records the net amount for supported transfer-fee mints, and updates fee-per-share accounting.

​
Funding by Claiming Fees

Funding by claiming fees works for PDA fee vaults and only for whitelisted source-program actions. The vault calls a supported fee-claim action, receives claimed tokens into its token vault, and then adds the token-vault balance increase to fee-sharing accounting. Additional requirements:
  • The source_program and instruction discriminator must match a whitelisted action.
  • The whitelisted token-vault account index must point to the fee vault’s token vault.
  • The signer must be one of the configured share-holder addresses.
  • The fee vault must be a PDA vault.

​
Compatible Source Programs and Actions

Dynamic Fee Sharing currently whitelists supported actions from DAMM v2 and DBC.

​
DAMM v2

Supported DAMM v2 claim actions include:
Whitelisted ActionToken Vault Account IndexProduct Meaning
ClaimPositionFee4Claim trading fees from a DAMM v2 position into the fee vault.
ClaimReward5Claim DAMM v2 reward emissions into the fee vault.

​
Dynamic Bonding Curve (DBC)

Supported DBC claim and withdrawal actions include:
Whitelisted ActionToken Vault Account IndexProduct Meaning
CreatorWithdrawSurplus3Route creator surplus into the fee vault.
ClaimCreatorTradingFee3Route creator trading fees into the fee vault.
PartnerWithdrawSurplus3Route partner surplus into the fee vault.
ClaimTradingFee4Route eligible DBC trading fees into the fee vault.
WithdrawMigrationFee3Route eligible migration fees into the fee vault.
The token-vault index is part of the program’s whitelist check. If an integration changes account ordering, Dynamic Fee Sharing must whitelist the matching action and account index before that claim path works.

​
What Is Not a Fit

Dynamic Fee Sharing may not be the right product when:
  • The recipient set changes frequently.
  • There are more than 5 recipients.
  • The token mint uses unsupported Token 2022 extensions.
  • The fee source requires an unsupported cross-program claim action.
  • The payout requires complex conditional logic instead of fixed shares.
  • The setup needs owner-managed edits, admin withdrawals, or vault closure through the current program.
For those cases, teams should either use manual operational flows or build a custom distribution layer around their requirements.