How To Verify a DEX Pair Is Real: Fake Pairs, Fake Routers, Fake Aggregators

A DEX trade usually touches four separate components. Confusing them is how most “fake pair” scams work.

• First comes the token contract. That is the ERC-20 that holds balances and enforces transfer rules.
• Second comes the pool contract. In Uniswap v2-style designs it is a “pair” contract that holds reserves and issues LP tokens. In Uniswap v3-style designs it is a “pool” contract with concentrated liquidity.
• Third comes the router contract. This is the contract a wallet calls to perform swaps, add liquidity, and unwrap WETH-like assets. A legitimate router can still route into a malicious token, so router verification is necessary but not sufficient.
• Fourth comes the front-end or aggregator. A front-end is a website that helps build transactions. An aggregator is a smart contract layer that can route across multiple venues. Scams often combine a lookalike front-end with a malicious router or a malicious “spender” address.

A “real” DEX pair is not a brand claim. It is an on-chain relationship: a known factory created a pool for two known token addresses, and the pool bytecode matches the expected implementation for that factory.

Step 1: Start From the Token Address, Not the Chart

Charts are easy to spoof. A token address is harder to fake because it anchors every other check. Open the token address on a block explorer and confirm it is a contract, not an externally owned account. Confirm the name, symbol, and decimals match what the UI claims. Verify the contract source code is published when possible, but do not treat “verified” as a safety stamp.

Next, check for upgradeability and indirection. If the explorer labels the contract as a proxy, the logic can change later. That does not automatically mean it is unsafe, but it means “looks safe today” is not the same as “stays safe tomorrow.” Proxy mechanics are a common rug pull lever, especially when there is no timelock or multisig.

Check whether transfers have special rules. Many honeypots hide behind transfer restrictions, dynamic taxes, blacklists, or whitelist gates. Transaction simulation helps here, but the fastest first-pass is to scan for functions that can change trading behavior.

Step 2: Confirm the Pool Exists in a Known Factory

A fake “pair” scam usually relies on one of two tricks:

1. The UI points to a pool that is not created by the canonical factory for that DEX.
2. The UI points to a real pool address but swaps through a different router or spender.

The cleanest verification is to confirm the pool address comes from a known factory.

For Uniswap v2-style pools, the canonical lookup is the factory’s getPair(tokenA, tokenB). If it returns a non-zero address, that factory recognizes the pair. Uniswap’s SDK guide shows both the on-chain getPair approach and the deterministic CREATE2 computation approach for the same outcome.

Uniswap v2 deployments also publish the factory and router addresses per chain. If a UI claims “Uniswap v2 on Ethereum mainnet,” but the factory address does not match that list, treat it as untrusted.

For Uniswap v3-style pools, the equivalent lookup is the factory’s getPool(tokenA, tokenB, fee). The Uniswap v3 deployments reference points to getPool as a canonical way to find an existing pool.

If a UI provides a pool address, validate it from the pool itself:

A v2 pair exposes token0 and token1 and reserves via getReserves. If token0 or token1 does not match the token addresses being marketed, it is not the pool being claimed.

Also check factory() on the pool contract when available. A genuine v2 pair points back to its factory, and the factory emits PairCreated events on creation.

Step 3: Confirm the Router Is the Intended Router

A “fake router” is usually a real smart contract that looks like a router but adds one malicious behavior:

• It redirects outputs to an attacker-controlled recipient.
• It requests unlimited approvals to a suspicious spender.
• It wraps extra calls that drain tokens using permit signatures.

Router verification has two parts: address sanity and behavior sanity.

Address sanity means the router address matches an official deployment list for that protocol and chain. For Uniswap v2 on Ethereum mainnet, UniswapV2Router02 has a well-known deployment address and is listed in the deployments reference. For Uniswap’s Universal Router, the overview covers what the contract is and emphasizes it is unowned and non-upgradeable, which helps narrow down expected bytecode patterns.

Behavior sanity means the wallet confirmation screen matches expectations. A normal swap transaction calls a router function and does not ask for unrelated permissions. If the confirmation shows an approval for a spender that does not match the router or an expected permit contract, it needs extra scrutiny.

A common trap is mixing “swap” and “approve” in one flow. Sometimes this is legitimate, especially with signature-based approvals such as Permit2, but it is also a favorite place to hide a drain. Permit2 combines signature-based transfers and allowance-based approvals in a single framework. A safe flow is one where the spender and the scope make sense for the exact action.

Step 4: Treat Aggregators as Contracts, Not Brands

Aggregators often feel safer because they are well-known names. The exploit surface is different, not smaller. A fake “aggregator” scam typically does one of these:

• Uses a lookalike domain to get a user to sign a permit message for a malicious spender.
• Routes through a fake router that is not part of the real aggregator’s execution path.
• Uses a real aggregator contract address but changes the parameters so output goes elsewhere.

The defense is to verify the spender and settlement contract, not the website logo.

For CoW Swap, a core on-chain component is the settlement contract, and the protocol docs reference deterministic deployments for their contracts. If a UI asks to approve a different spender than the known settlement contract, that is a red flag.

For any aggregator, confirm the spender address in the approval matches a known, verified contract on the correct chain explorer. If the UI cannot explain why that spender is needed, treat the trade as unsafe.

Fake Patterns and the Checks That Break Them

The table below maps common scams to the concrete check that usually catches them.

A Low-Risk Execution Playbook

Verification reduces risk, but execution habits close the remaining gap. A conservative approach starts with a separate “interaction wallet.” Funds stay in a cold or vault wallet and only a small amount moves to the interaction wallet for swaps.

Before signing, the user checks three numbers and two addresses: the token being spent, the token being received, the amount, the spender, and the recipient.

If the wallet shows an approval, the approval amount is limited. Unlimited approvals remain the most common post-swap drain vector because they make later theft cheaper.

After the swap, stale approvals are revoked. Revoke.cash lists approvals per chain and allows revocation through a normal on-chain transaction.

Conclusion

A “real” DEX pair is verifiable through factory relationships, pool internals, and router and spender identities. The fastest wins come from starting with token addresses, confirming the pool through getPair or getPool, and treating approvals and permit signatures as first-class risk signals.

The post How To Verify a DEX Pair Is Real: Fake Pairs, Fake Routers, Fake Aggregators appeared first on Crypto Adventure.