AMM Pool Creation: Why a Duplicate Pair Can Fail

An AMM factory can reject a second pool for the same pair when that factory treats the token addresses and pool settings as an identity already in use. The rule varies by protocol: some allow one pool per token pair, while others allow separate pools when a fee tier or another identity setting differs.

Why does a duplicate pair fail?

A factory may sort the two token addresses into a standard order, then check its registry for that pair before deploying a contract. In Uniswap v2’s factory, for example, the same two addresses map to one pair in either order; a second creation attempt reverts because the pair already exists.

That check is about contract addresses, not the token names shown in an interface. Two tokens with similar names can have different addresses, while entering the same addresses in reverse order still refers to the same pair. For a fuller explanation of choosing a base swap pool, see the separate guide.

When can the same tokens have multiple pools?

The same tokens can have multiple pools when the protocol includes another parameter in the pool’s identity. Uniswap v3, for example, permits pools for a token pair at different fee tiers, but a pair and fee tier identify a single pool in that factory.

In Uniswap v4, a pool key includes the two currencies, a fee field, tick spacing and a hook. Changing a key component can define a distinct pool; changing a setting stored outside that key does not. Other AMMs may use different rules, so “same pair” alone does not tell you whether a creation will succeed.

What should you check before creating a pool?

Check the factory contract and network you intend to use, then read the protocol’s pool identity rules. A pool on another chain or under another factory is recorded separately, even if it uses the same token addresses. A different fee tier may also create a distinct pool, depending on the design.

• Confirm both token contract addresses and the chain.
• Query the intended factory for an existing pool using its required parameters.
• Check whether fee tier, tick spacing or hook settings are part of pool identity.

A failed creation can also come from invalid inputs, such as identical token addresses or a zero address, rather than a duplicate. Read the transaction’s revert reason and compare the exact factory inputs before retrying; switching to another factory or configuration creates a different pool and may split liquidity among venues.

What happens after the duplicate check?

If the registry shows no matching pool and the inputs meet the factory’s rules, creation can proceed; the creator may still need to initialize the pool and add liquidity before traders can use it. If a matching pool already exists, use its address and assess its liquidity instead of repeating the same creation call. The next step is to verify the pool identity against the factory before submitting the transaction.