Skip to main content
Before getting started building on Dynamic Fee Sharing, you should read the following resource to get a better understanding of how Meteora’s Dynamic Fee Sharing works:

What's Dynamic Fee Sharing?

Dynamic Fee Sharing is a program that allows any project to configure a fee sharing mechanism for their fees earned by initializing a fee vault and funding fees into the vault.

​
Dynamic Fee Sharing Program

At Meteora, we’ve developed a Node.js <> Typescript SDK to make deploying and managing your Dynamic Fee Sharing vault easier. The following sections includes information on installing and using the SDK. It also covers where to find the latest code, and how to contribute to these repositories.

​
Program Details

Dynamic Fee Sharing Program

Meteora Dynamic Fee Sharing Program

Dynamic Fee Sharing IDL

Meteora Dynamic Fee Sharing Program IDL
NetworkProgram ID
Mainnetdfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh
Devnetdfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh

​
Fee Vault Types

Dynamic Fee Sharing offers two types of fee vaults to accommodate different use cases:

Non-PDA Fee Vault

A fee vault created with an external keypair. Provides flexibility for standalone fee-sharing arrangements.

PDA Fee Vault

A fee vault derived from a base account. Ideal for protocol integrations where the vault is tied to another entity.

​
Non-PDA Fee Vault

A Non-PDA Fee Vault uses a regular Solana account (keypair-based) for the fee vault address. The vault address is generated externally and must be provided as a signer during initialization. Characteristics:
  • Fee vault address is a randomly generated keypair
  • The keypair must be stored and managed externally
  • Multiple vaults can be created for the same token mint and owner
  • Simpler to understand and implement
When to Use:
  • Creating standalone fee vaults without ties to other protocol entities
  • Need to create multiple fee-sharing arrangements for the same token
  • Vault lifecycle is independent of any base account
  • Simpler integration without deterministic address requirements
Address Derivation: 
Fee Vault Account: External keypair (random address)
Token Vault: PDA([TOKEN_VAULT_PREFIX, fee_vault_address], program_id)

​
PDA Fee Vault

A PDA Fee Vault uses a Program Derived Account (PDA) for the fee vault address. The vault address is deterministically derived from a base account and token mint, making it recoverable and tied to a specific entity. Characteristics:
  • Fee vault address is derived from seeds: [FEE_VAULT_PREFIX, base_address, token_mint]
  • No external keypair storage needed - address is always recoverable
  • Only ONE vault per (base account, token mint) combination
  • Base account must sign during initialization
When to Use:
  • Vault is logically tied to another account (e.g., AMM pool, bonding curve, liquidity position)
  • Need deterministic address derivation for protocol integration
  • Want to avoid external keypair management
  • Address should be recoverable from (base, token_mint) pair
  • Integrating with features that reference a base entity
Address Derivation: 
Fee Vault Account: PDA([FEE_VAULT_PREFIX, base_address, token_mint], program_id)
Token Vault: PDA([TOKEN_VAULT_PREFIX, fee_vault_address], program_id)

​
Comparison

AspectNon-PDA Fee VaultPDA Fee Vault
Address GenerationExternal keypair (random)Derived from seeds (deterministic)
Address RecoveryRequires storing keypairDerivable from (base, token_mint)
UniquenessMultiple vaults per (owner, token_mint)One vault per (base, token_mint)
Signer RequirementFee vault keypair signs initBase keypair signs init
Tied to EntityNoYes (via base account)
Use CaseStandalone vaultsProtocol-integrated vaults
Both vault types share the same underlying state structure and support identical operations after initialization: funding fees, claiming fees, and fee distribution via the checkpoint mechanism.

​
Official SDKs

Typescript SDK

Official Meteora Dynamic Fee Sharing Typescript SDK