Skip to main content
  • initialize_pool_with_static_config needs a static config. The pool address is derived from "pool", the config and the two mints.
  • initialize_pool_with_dynamic_config needs a dynamic config and the signature of its pool creator authority. The pool address is derived the same way, from "pool", the config and the two mints.
  • initialize_launch_pool needs no config. The pool address is derived from "l_pool" and the two mints.
A pool created from a static config takes its tick spacing, fee schedule, fee token, activation type and extensions from the config. None of them can be chosen or changed by the pool creator, so picking a config is how you pick those settings. This page explains what the published configs contain, how they are numbered, and lists every config address. For the three ways to create a pool and what each one lets you choose, see Pool Creation and Activation.

Static Config Fields

A StaticConfig account holds the fields below. The byte layout is on the Accounts page. Three rules follow from how static-config pools are created:
  • A pool address comes from the config and the mint pair, so each config allows one pool per pair. Two pools for the same pair need two different configs.
  • A static-config pool has no ActivationAccess extension. It is open for swaps, deposits and withdrawals as soon as it is created, and its activation point is the moment of creation. A time scheduler therefore starts counting when the pool is created.
  • A static-config pool has no partner, and the protocol takes 10% of the LP part of each fee. See Fees.
On a config whose collect_fee_mode is OnlyY, token Y must be wrapped SOL, USDC or a mint with a token badge. See Token 2022 Support.

Published Configs

There are 1,848 static configs, with indexes 0 to 1847. They exist at the same addresses on mainnet and devnet. Every one of them is public (its pool_creator_authority is the default key) and uses the timestamp activation type, so fee scheduler periods are in seconds. The configs are the full combination of four choices: 33 × 7 × 4 × 2 = 1,848.

Tiers

A tier pairs a tick spacing with a base fee. The base fee is the fee a fixed-fee config charges and the fee a scheduled config falls to. Fee numerators are over 1,000,000,000. The last two columns apply to the variants with the dynamic fee on. variable_fee_control is set per tier so that the dynamic fee tops out at about 20% of the base fee.

Fee Schedules

A scheduled config starts at a high fee when the pool is created and lowers it once per period until the last period, after which the fee stays where it settled. A linear schedule subtracts the same amount each period. An exponential schedule multiplies the fee by the same factor each period. See Base Fee Schedules for the curves. The reduction per period is a whole number, so a schedule does not always land exactly on the tier’s base fee. A linear schedule settles within 0.00002% of it. An exponential schedule reduces the fee by a whole number of basis points per period and can settle up to about 0.07% above it on the 6% tier, and by smaller amounts on lower tiers. The address tables below give the fee each config settles at.

Variants

With the dynamic fee on, every config uses the same timing and differs only in variable_fee_control (per tier, in the table above) and min_delta_tick_for_significant_swap: See Dynamic Fee for what each parameter does.

Extensions

Config Index

The index of a published config follows from the four choices:
For example, tick spacing 16 with a 0.15% base fee is tier 12. A config for that tier whose fee starts at 50% and falls exponentially (schedule 5), with fees in token Y and the dynamic fee on (variant 1), on a pool with liquidity mining (extension 1), has index 924 × 1 + 132 × 5 + 4 × 12 + 1 = 1633. Derive the address from the index, then read the account to confirm it holds the settings you expect before creating a pool:
The formula describes the configs listed on this page. A config created later may not follow it, and the account, not the index, decides a pool’s settings.

Listing Configs On-Chain

To read the current set of configs from the chain, fetch every StaticConfig account. This uses getProgramAccounts, which some public RPC endpoints limit or disable.
Without getProgramAccounts, derive the addresses with deriveStaticConfig for a range of indexes and read them with getMultipleAccountsInfo, 100 addresses per call.

Static Config Addresses

The tables below were read from mainnet on 14 November 2026. Each table covers one extension and one fee schedule, and lists its 132 configs by tier and variant. Settled fee is the base fee once the schedule has finished, as a numerator over 1,000,000,000.

Dynamic Configs

A dynamic config does not fix a pool’s settings. It authorizes one wallet, its pool_creator_authority, to create pools with settings chosen at creation, and makes that wallet the partner of each pool. A DynamicConfig account holds: With a dynamic config, the creator passes the pool’s fee schedule, dynamic fee, tick spacing, fee token, initial price, activation type, activation point, extensions and activation rules in the instruction. The instruction reference lists each parameter and the limits the program enforces, and Pool Parameters with a Dynamic Config shows them in the SDK. Dynamic configs are created by Meteora for one authority at a time and are not listed here. Launchpads and integrators that want one can ask in the Meteora Discord.

Launch Pools

A launch pool needs no config. The creator passes the same parameters as with a dynamic config, the pool address comes from the mint pair alone, and anyone holding both tokens can create it. There is one launch pool per pair, it has no partner, and the protocol takes 20% of the LP part of each fee instead of 10%.

Pool Creation and Activation

The three ways to create a pool and what each one lets you choose.

TypeScript SDK Examples

Create pools, positions and limit orders with the SDK.