> ## 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

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:

<CardGroup cols={1}>
  <Card title="What's Dynamic Fee Sharing?" icon="question" iconType="solid" href="/overview/other-products/dynamic-fee-sharing/what-is-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.
  </Card>
</CardGroup>

***

# 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

<CardGroup cols={2}>
  <Card title="Dynamic Fee Sharing Program" icon="rust" iconType="solid" href="https://github.com/MeteoraAg/dynamic-fee-sharing">
    Meteora Dynamic Fee Sharing Program
  </Card>

  <Card title="Dynamic Fee Sharing IDL" icon="code" iconType="solid" href="https://github.com/MeteoraAg/dynamic-fee-sharing-sdk/blob/main/src/idl/idl.json">
    Meteora Dynamic Fee Sharing Program IDL
  </Card>
</CardGroup>

<div className="overflow-x-auto">
  <table className="w-full border-collapse">
    <thead>
      <tr className="border-b border-gray-300 dark:border-gray-600">
        <th className="text-left py-3 px-4 font-semibold text-gray-900 dark:text-gray-100">Network</th>
        <th className="text-left py-3 px-4 font-semibold text-gray-900 dark:text-gray-100">Program ID</th>
      </tr>
    </thead>

    <tbody>
      <tr className="border-b border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-800">
        <td className="py-3 px-4"><strong className="text-gray-900 dark:text-gray-100">Mainnet</strong></td>
        <td className="py-3 px-4"><code className="bg-gray-100 dark:bg-gray-800 px-2 py-1 rounded text-sm font-mono">dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh</code></td>
      </tr>

      <tr className="border-b border-gray-200 dark:border-gray-700 hover:bg-gray-50 dark:hover:bg-gray-800">
        <td className="py-3 px-4"><strong className="text-gray-900 dark:text-gray-100">Devnet</strong></td>
        <td className="py-3 px-4"><code className="bg-gray-100 dark:bg-gray-800 px-2 py-1 rounded text-sm font-mono">dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh</code></td>
      </tr>
    </tbody>
  </table>
</div>

## Fee Vault Types

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

<CardGroup cols={2}>
  <Card title="Non-PDA Fee Vault" icon="key" iconType="solid">
    A fee vault created with an external keypair. Provides flexibility for standalone fee-sharing arrangements.
  </Card>

  <Card title="PDA Fee Vault" icon="link" iconType="solid">
    A fee vault derived from a base account. Ideal for protocol integrations where the vault is tied to another entity.
  </Card>
</CardGroup>

### 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

| Aspect                 | Non-PDA Fee Vault                        | PDA Fee Vault                      |
| ---------------------- | ---------------------------------------- | ---------------------------------- |
| **Address Generation** | External keypair (random)                | Derived from seeds (deterministic) |
| **Address Recovery**   | Requires storing keypair                 | Derivable from (base, token\_mint) |
| **Uniqueness**         | Multiple vaults per (owner, token\_mint) | One vault per (base, token\_mint)  |
| **Signer Requirement** | Fee vault keypair signs init             | Base keypair signs init            |
| **Tied to Entity**     | No                                       | Yes (via base account)             |
| **Use Case**           | Standalone vaults                        | Protocol-integrated vaults         |

<Note>
  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.
</Note>

***

## Official SDKs

<CardGroup cols={2}>
  <Card title="Typescript SDK" icon="node-js" iconType="solid" href="/developer-guide/guides/dynamic-fee-sharing/typescript-sdk/getting-started">
    Official Meteora Dynamic Fee Sharing Typescript SDK
  </Card>
</CardGroup>