Orca
Orca pool creation with starting price and tick spacing
Orca pool creation initializes a Whirlpool for a chosen token pair, starting price, and supported fee tier. Tick spacing sets the grid for liquidity position boundaries; the initial price establishes the pool’s starting exchange ratio. Pool initialization creates the pool and its token vaults. Trading requires liquidity, so a successfully created pool can still have no usable trading depth.
The creation path depends on whether a suitable pool already exists and which position ranges the new pool should support. Mint order, decimal precision, and tier configuration determine whether the intended setup matches the onchain pool.
Key takeaway: A pool’s tick spacing constrains liquidity ranges, while its initial price must match token order and decimal precision.
Existing pools and range requirements determine the creation path
An existing Whirlpool with the required pair and tier provides a place to open a position without initializing another pool. Creating a new pool makes sense when the required configuration does not exist. Pools for the same pair can have different tier identities and separate liquidity. A new pool therefore begins a separate market with its own price state, even when another pool already trades the same tokens.
Splash Pools support full-range positions through a dedicated tick-spacing setting. Pools permitting custom ranges let providers choose narrower boundaries within the supported grid. Fee behavior presents another choice: fixed-fee initialization uses a configured fee tier, while adaptive-fee initialization uses an adaptive tier and creates additional fee-tracking state. Adaptive tiers can allow permissionless creation or require a designated initialization authority. A wallet’s ability to fund creation does not establish that authority.
Mint order and tier configuration fix the pool identity
The program identifies a pool through its configuration account, ordered token mints, and fee-tier index under the selected program deployment. Standard fixed-fee initialization uses tick spacing as that index. Adaptive tiers have a separate index and supply their own tick spacing. Locating an existing pool or deriving a new address requires that tier identity and mint accounts from the selected network. Their addresses establish the assets; symbols do not determine mint ordering. The program requires token A’s mint public key to precede token B’s in byte order. Compatibility also depends on the selected initialization instruction and the mints’ token extensions.
The selected tier must belong to the intended configuration. Certain Token-2022 features require a token badge. The funder needs enough network currency for account storage and transaction fees.
Token decimals determine the encoded starting price
The starting price expresses token B per token A in whole-token units defined by their mint decimals. Reversing the display direction requires the reciprocal ratio. Canonical mint ordering determines which asset occupies each side, regardless of its familiar trading label.
Token decimals convert whole-token prices into ratios of the smallest token units. If P denotes the whole-token B-per-A price, and dA and dB denote mint decimals, the raw-unit ratio equals P × 10^(dB − dA). Equal decimal precision leaves that ratio unchanged.
The Whirlpools program stores the square root of this raw-unit ratio as a Q64.64 integer. The conversion is floor(2^64 × sqrt(P × 10^(dB − dA))). Decimal-aware SDK helpers handle this encoding; ordinary floating-point arithmetic can lose precision.
A missing decimal adjustment can produce a different price even when the displayed ratio appears sensible. The program rejects encoded starting prices outside its supported bounds. Once liquidity backs the pool, a price inconsistent with other markets can expose that liquidity to arbitrage. A trader exchanging against the mispriced pool changes the deposited token mix. Correct encoding and a suitable economic starting price address different problems.
Tick spacing determines the available position boundaries
A Whirlpool position’s lower and upper tick indices must be multiples of the pool’s tick spacing. The lower boundary must also precede the upper boundary, and both must fit the program’s supported range. Smaller spacing provides finer boundary choices, while larger spacing places usable boundaries farther apart. This grid governs where providers can define ranges. The current square-root price can lie between usable boundaries, so pool initialization does not need to round the starting price to a position boundary.
Tick spacing also remains distinct from a position’s chosen width. A pool with fine spacing can support a broad range. Full-range-only settings impose an additional restriction and reject narrower positions, including ranges whose endpoints otherwise fit the grid.
Initialization creates vaults before liquidity supplies trading depth
Pool initialization records the starting price, current tick, token mints, vault addresses, and initial fee settings. It starts the pool’s liquidity at zero. Each vault is a token account for one of the paired mints under the Whirlpool’s authority, and adaptive-fee initialization adds an Oracle account for adaptive-fee state. These accounts establish the market’s structure before positions contribute liquidity.
Position opening and liquidity increases perform different jobs. A position defines its tick boundaries and ownership. Increasing its liquidity transfers the required tokens into the pool vaults and updates liquidity accounting. The current price and selected boundaries determine the token amounts, with ranges outside that price contributing no active depth there. Pool-level tick spacing governs every position’s available boundaries, while each position retains its own range.
An application can group supported instructions into a transaction or separate them across transactions.
A hypothetical starting price checked against the initialized pool
Consider a hypothetical setup with compatible token A and token B mints in canonical order, equal decimal precision, and a starting price of 2.37 units of B per A. An existing fixed-fee tier supplies spacing s, the pool does not yet exist, and the funder can cover initialization. No deposit or later transaction changes the pool before the account read. The creator wants an empty pool at this ratio before funding a position.
Equal decimals make the raw-unit ratio 2.37. Its reciprocal is approximately 0.42194 A per B. The creator uses the decimal-aware price helper to encode its square root, then submits initialization with the selected tier and required signers. After successful confirmation, the pool contains the selected mints and spacing s. Initialization alone leaves its liquidity at zero.
A separate read through the network’s remote procedure call (RPC) service retrieves the account at the derived pool address. Decoding its square-root price should recover approximately 2.37 B per A, allowing for encoding precision. The account’s owner program, mints, configuration, and spacing must also match the intended setup. A matching account establishes the initialized pool; a generated address alone does not. Changing either token’s decimal precision would change the encoded integer required for the same whole-token price.
Account storage drives setup costs independently of deposited liquidity
On Solana, initialization funding covers the accounts the transaction creates, including the Whirlpool and token vaults. Required vault sizes can vary with token extensions. Tick-array accounts hold grouped tick data; dynamic arrays begin with minimal storage and expand as liquidity operations require more space. The initial allocation avoids funding a large fixed array before its storage becomes useful. The minimum allocation for a new dynamic array is a nonrefundable creation cost. Expansion rent deposits for a position return when that position closes. Closing a position does not refund the pool’s entire setup funding.
Transaction fees add a base fee and any chosen prioritization fee. An SDK’s initialization-cost estimate may cover account funding without including those execution fees or the tokens for a liquidity deposit. Adding a position to an existing pool avoids creating another pool account and its vaults. It can still require position accounts and tick storage, so the relevant comparison follows the accounts each action actually creates.
What readers ask about Orca pool creation
Does creating a Whirlpool require ownership of the token mints?
Standard fixed-fee pool initialization does not require the paired tokens’ mint authorities to sign. The funder and required account signers authorize initialization, while the program checks mint ordering and compatibility. An adaptive tier can separately require a designated initialization authority. Supplying that authority differs from controlling either token’s mint.
Which initialization instruction supports Token-2022 pairs?
For fixed-fee pools, initialize_pool_v2 supports compatible Token-2022 mints as well as legacy Token Program mints. The initialize_pool_with_adaptive_fee instruction supports those mints for adaptive-fee pools. The legacy initialize_pool instruction uses legacy Token Program mint accounts. Token-2022 support still depends on each mint’s extensions and any required token badge; choosing the V2 instruction does not make every extension combination acceptable.
Can the pool funder differ from the owner of the first position?
The pool funder can differ from the owner of the first liquidity position. Initialization and position opening have their own account roles. During position opening, the funder pays for new accounts, while the owner receives the position token. Paying account storage costs alone grants no control over another owner’s position.
What happens if initialization succeeds but a later deposit fails?
A successful initialization remains in place if a separate deposit transaction fails. Solana applies atomicity within each transaction, so a failure rolls back that transaction’s state changes. If initialization and deposit share one transaction, a failing deposit also prevents that transaction’s initialization from committing. Executed failed transactions can still charge network fees.
When can trading begin in an adaptive-fee pool with a scheduled start?
The scheduled trading restriction ends when the onchain clock reaches the accepted trade-enable timestamp. Adaptive-fee initialization allows a future start only for a permissioned tier, at most 72 hours ahead of the clock during initialization. Permissionless tiers cannot set this delay. Omitting the timestamp applies no scheduled delay, and trading still requires usable liquidity.
Will creating a Whirlpool change either paired token’s total supply?
Whirlpool initialization creates pool infrastructure without minting more of either paired token. It uses existing mint accounts and creates vaults to hold their tokens. A later liquidity deposit transfers tokens into those vaults. Any token-creation or supply-management operation has its own authorization and remains separate from initializing this trading pool.
How can a transfer-fee token affect the first liquidity deposit?
A supported Token-2022 transfer fee can increase the amount the depositor must send to supply the required net liquidity amount. The V2 liquidity-increase instruction includes applicable transfer fees when checking each token’s maximum permitted contribution. If either amount including transfer fees exceeds its maximum, the liquidity increase fails. Pool account funding does not cover this token deduction, and the applicable transfer-fee configuration can change.
Will leaving the SDK’s initialPrice option unset select a market price?
Omitting initialPrice does not instruct the TypeScript pool builder to discover a market price. The @orca-so/whirlpools creation helpers use a default price of 1 B per A when initialPrice is absent. An explicit starting ratio preserves the intended token-B-per-token-A price, with both mint decimals governing its conversion into the pool’s stored square-root value.