Skip to main content
Dynamic Fee Sharing is intentionally narrow. This page is the compatibility reference for what the current program accepts.

​
Compatibility Overview

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

​
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.
A fee vault is designed to support a single token mint and a single token vault, and fund_by_claiming_fee credits only the balance increase of that one token vault. The source pool’s CollectFeeMode must therefore be configured to collect fees only in the fee vault’s token mint: OnlyB or Compounding for DAMM v2 and QuoteToken for DBC.

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

​
Dynamic Bonding Curve (DBC)

Supported DBC claim and withdrawal actions include:
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.