A liquidity pool holds two assets in an on-chain program so users can exchange one for the other according to the pool’s rules. Creating a pool is more than a listing step: the initial deposit defines an opening ratio, and the liquidity provider accepts market, inventory, execution, and smart-contract risk.
Only commit assets you are authorized and prepared to use. This article is educational and is not financial advice.
Understand the two sides of the pool
A pool pairs a base token with a quote token. For a new community token, the base side may be the newly created token while the quote side may be a widely used asset.
The deposit ratio implies the starting price:
starting price in quote units = quote amount / base amount
If a pool starts with 1,000,000 base tokens and 10 quote tokens, the implied starting price is 0.00001 quote tokens per base token. This arithmetic does not establish fair value. It only describes the initial pool ratio before trades and fees change the balances.
Collect and verify:
- the mint address for each token;
- the token program used by each mint;
- wallet balances available for the deposit;
- decimals for both tokens;
- the intended deposit ratio;
- estimated network and platform fees;
- the wallet that will receive or control the liquidity position;
- the plan for retaining, locking, transferring, or burning that position.
Check for existing pools for the same pair. Multiple pools can fragment liquidity and confuse users. Confirm that your selected assets and program versions are supported by the creation tool.
Calculate the initial ratio
Work backward from a clearly documented allocation rather than choosing numbers because the displayed price looks attractive.
Suppose:
- total supply is 100,000,000 tokens;
- 60,000,000 tokens are allocated to liquidity;
- 12 quote tokens are deposited.
The initial ratio is:
12 / 60,000,000 = 0.0000002 quote tokens per token
You should also calculate the implied valuation using the entire supply, not only the amount in the pool. A tiny unit price can still imply a large total valuation when the supply is large.
Use exact decimal arithmetic. Browser displays may round very small values, so review the raw amounts and decimals before signing.
Create the pool through a guided flow
A typical no-code workflow is:
- Connect the wallet holding both deposit assets.
- Select the first token by verified mint address.
- Select the paired asset.
- Enter the amount of each asset.
- Review the displayed ratio and minimum balance requirements.
- Check platform fees, network costs, and all accounts being created.
- Confirm the transaction in the wallet.
- Wait for on-chain confirmation.
Do not submit repeatedly when confirmation is slow. First check the transaction signature to avoid creating unintended duplicate accounts or pools.
Understand the liquidity position
Depending on the pool design, the provider may receive fungible LP tokens or another form of position record. This position represents rights associated with the deposited liquidity.
Whoever controls it may be able to remove some or all liquidity. That fact should be disclosed. If the position is transferred, locked, or burned, verify the action on-chain and explain precisely what changed.
Locking a position can restrict access for a period. Burning can permanently destroy the credential needed to redeem it. Both can be irreversible and should be tested and documented. Neither action guarantees trading activity, price stability, or protection from every vulnerability.
Review price impact and pool depth
Small pools can experience large price movements from modest trades. This is often called price impact. More deposited value can reduce the impact of a given trade, but it also increases the provider’s capital at risk.
Liquidity providers may also experience impermanent loss, where the value of the pooled assets differs from simply holding them as relative prices change. Fees may offset some outcomes, but they are not guaranteed to do so.
Do not describe a pool as deep, stable, or low-slippage without current, measurable evidence.
Verify the created pool
After confirmation, record:
- pool address or identifier;
- creation transaction signature;
- both token mint addresses;
- deposited raw and displayed amounts;
- initial ratio;
- fees paid;
- liquidity position address or balance;
- wallet controlling the position.
Open the transaction and pool through independent explorers or analytics tools. Confirm that the mints are correct before publishing a link. Scam tokens frequently reuse names and symbols.
Communicate control clearly
Public documentation should answer:
- Who supplied the initial liquidity?
- Who controls the liquidity position?
- Can liquidity be removed?
- Is any lock active, and when does it end?
- Was any position burned?
- Are additional pools planned?
- Can the team change token supply or freeze accounts?
Avoid claiming that a token “cannot be rugged” based on one setting. Liquidity control is one risk signal among many.
Common pool creation mistakes
Reversing the ratio
Entering base and quote amounts in the wrong order can produce an unintended starting price. Read the displayed units rather than assuming field order.
Depositing the wrong token
Names and symbols can be copied. Verify the complete mint address.
Using all available SOL
Keep enough native balance for network fees, account creation, and recovery actions. A max button should not leave the wallet unable to complete the transaction.
Forgetting who controls the position
Record the receiving wallet and custody plan before creation, especially when multiple team members are involved.
Treating liquidity as demand
A funded pool enables swaps; it does not create users, revenue, or guaranteed value.
Final checklist
Create the pool only after you can confirm:
- both mint addresses and decimals;
- the deposit ratio and implied valuation;
- exact amounts at risk;
- all fees;
- ownership of the resulting position;
- withdrawal, lock, or burn plans;
- public disclosures;
- sufficient wallet balance for completion.
Liquidity is an operational commitment. A careful setup makes the ratio, ownership, and risks legible before any transaction is signed.