Which Solana DEXs Actually Support Token-2022? A Field Map

The Mint That Splits My Router In Half

A new candidate token surfaces in my scanner. The metadata looks reasonable, the liquidity is non-trivial, and the price gap across two pools is wide enough to be interesting. I push it into the simulation pipeline and three things happen at once: one DEX returns a clean quote, another DEX returns an error I have not seen before, and a third DEX returns a quote that is mathematically impossible given the pool reserves.

That is the Token-2022 problem in one paragraph. The newer token standard on Solana introduces extensions — transfer fees, transfer hooks, confidential transfers, interest accrual, metadata, and more — and every DEX on the network has had to decide what to do about it. Some have rebuilt their programs to handle the new program ID. Some have whitelisted a subset of extensions. Some have done nothing and will quietly mishandle any mint that does not live under the legacy SPL Token program. If my arbitrage router does not know which is which, I am quoting fantasy prices.

This is the field map I am building right now: which DEXs explicitly support Token-2022, which extensions they accept without permission, which require a manual application, and which DEXs I have to treat as unknown until I verify them myself. The map is incomplete on purpose. I am writing down what I actually know, not what I wish I knew.

Why DEX Support Is Not Optional

To understand why this matters, the key fact is that Token-2022 is a separate program with a separate address. The legacy SPL Token program lives at one address; Token-2022 lives at another. Per the Solana Foundation's Token-2022 documentation, the new program is TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb, while the original token program lives at TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA.

That split has direct consequences for any program that handles tokens. A DEX that hardcodes a single token program address can only ever route mints owned by that program. If the mint your bot is trying to swap is owned by Token-2022 and the DEX is hardcoded to the legacy program, the transaction either fails outright or — worse — silently produces nonsense. Silently producing nonsense is the failure mode I worry about more, because the bot only notices once a real swap has been broadcast.

The Solana Foundation went out of its way to make Token-2022 a drop-in superset where possible. The docs note that Token-2022 "supports the exact same instruction layouts as Token, byte for byte", which keeps the original twenty-five instructions identical at the same indexes and adds new functionality starting at the next index. Account and Mint structures keep their original byte layout up front and append extension data at the end. That backwards-compatibility design is the only reason the migration is even tractable. It is not, however, automatic. A DEX still has to choose to look at the mint, decide which program owns it, dispatch into the right CPI, and handle the extensions that change the math of a swap.

The most consequential extension for a router is the transfer fee. Per Chainstack's writeup of Token-2022 transfer mechanics, "the recipient is the one who 'pays' for the fee, so if 100 tokens are sent with basis points of 500 (5%), the recipient will receive 95 tokens with five withheld." If your slippage math assumes the recipient gets the full quoted amount, you are wrong by exactly the fee, every time. That is not a rounding error; it is a structural mismatch.

Raydium: CLMM and CPMM Yes, Legacy AMM No

Raydium was one of the first major Solana DEXs to add Token-2022 support. According to the team's official Medium announcement, permissionless creation of Token-2022 CLMM pools went live on July 19, 2023. The announcement specifically calls out Transfer Fees as the headline extension, which is also the extension most likely to actually appear in real meme-coin trading.

Raydium's pool types do not all support Token-2022 equally. The legacy AMM v4 pools — the original constant-product pools that long predate the extension standard — do not handle Token-2022 at all. CLMM (concentrated liquidity) pools support it as of mid-2023, and the newer CPMM (constant product) pool type supports it as well, including the scaled UI amount extension.

The Medium post is also explicit about which extensions a permissionless creator cannot use. Permanent Delegate is excluded because it grants "unlimited delegate privileges over any account for that mint." Non-Transferable tokens are excluded because they are "soul-bound tokens that cannot be moved to any other entity" — useless in a pool by definition. Default Account State is excluded because it "can force all new token accounts to be frozen," which would let an issuer freeze LP positions at will. Those three exclusions are not arbitrary; they all describe extensions whose semantics are flatly incompatible with a public liquidity pool.

The practical takeaway for my router is that for any Raydium pool, I have to know which Raydium pool type I am looking at before I trust the quote. A legacy AMM v4 pool with a Token-2022 mint as one side cannot exist as a valid pool in the first place — but I still have to verify that, because finding such a configuration would mean my pool indexer mislabeled the program. CLMM and CPMM pools, on the other hand, can carry Token-2022 mints, and I have to apply the right transfer-fee adjustment to the output amount.

Orca Whirlpool: TokenBadge as Whitelist

Orca took a different approach. The Whirlpools developer documentation records that "on May 28th 2024, Whirlpool program has been upgraded to support TokenExtensions (aka Token-2022 program)." InterestBearing was added later, on October 11, 2024.

What sets Orca apart is the TokenBadge mechanism. The docs describe a TokenBadge as "a PDA which allows pools and rewards to be initialized for such tokens." The badge is configured per WhirlpoolsConfig — meaning it is a config-level whitelist, not a global Solana state — and it gates which extensions are allowed for which mints.

Orca splits extensions into two buckets. Permissionless extensions, which work without a TokenBadge, are TransferFee, InterestBearing, MemoTransfer, MetadataPointer, TokenMetadata, and ConfidentialTransfer (only the non-confidential transfer path; actually-confidential transfers are excluded). Permissioned extensions, which require a TokenBadge, are PermanentDelegate, TransferHook, MintCloseAuthority, DefaultAccountState (and only when the default state is Initialized), and FreezeAuthority — the last one is technically not an extension but the docs note it gets the same gating treatment.

For my router, the TokenBadge concept means that two pools with structurally similar mints can have different routability depending on whether their badges are issued. There is no way to derive that from the mint alone; I have to look up the badge state on-chain. Discovering this the hard way after a quote returned cleanly but the swap reverted would be a very American kind of mistake — the equivalent of assuming a chain restaurant menu is identical at every location and then ordering the wrong thing in a different state.

There are also a couple of operational footguns that the Orca docs surface explicitly. One is wrapped SOL: a Token-2022 wrapped SOL mint exists, but Whirlpools cannot use it; pools have to use the original WSOL mint at So11111111111111111111111111111111111111112. Another is TransferHook: a hook program cannot call back into Whirlpool, and it cannot change the transfer amount. That last constraint is worth pausing on, because it kills a whole category of "tax token" designs that founders sometimes try to build on top of hooks.

The Whirlpool docs also clarify that Token-2022 pools have to use the V2 instruction set, and that "V1 instructions cannot process Token-2022 pools." That has implications for any client library: if you are still on a V1 SDK call path, your transaction will fail when it touches a Token-2022 pool, and the failure mode will not necessarily be obvious.

Meteora DLMM: Five Free, Twenty-Five Gated

Meteora's DLMM pools support Token-2022, and the Meteora documentation lays out the rules in unusually clean form. Five extensions are permissionless: TransferFeeConfig, MetadataPointer, TokenMetadata, TransferHook (with a hard condition I will come back to in a moment), and MemoTransfer. Everything else — and the docs list twenty-five extensions in the gated bucket — requires a Token Badge, which Meteora hands out manually.

The TransferHook condition is the part that bears reading carefully. Meteora allows TransferHook permissionlessly only when both hook_program and hook_authority have been revoked. In other words, the hook has to be inert: the issuer must have given up the ability to ever change it. An active hook is not allowed without a badge. That is the same architectural concern Orca raised in different language, and it traces back to the broader pattern that hooks which try to mutate transfer amounts run into what one third-party writeup calls "fundamental architectural walls" — a phrasing from RareSkills' Token-2022 specification post that I keep returning to because it captures the design tension cleanly.

The Meteora badge process is straightforward but not automated. Per the docs, "Start by completing this Google Form indicating which extensions you require. After submitting it, open a Discord ticket to inform us so we can review your request." If you are an issuer, the practical implication is that anything beyond the five permissionless extensions has a turnaround time measured in human-review hours, not seconds. If you are a router, the implication is that the set of badged tokens on Meteora at any given moment is curated, not algorithmic, and the only authoritative source is on-chain state plus the team's review queue.

Jupiter: An Aggregator's Problem Is Different

Jupiter is not really a DEX in the same sense as the others. It is an aggregator that routes through DEX pools — including the ones above — and so its Token-2022 story is partly its own and partly inherited from the underlying venues.

The archived Jupiter forum post on Token-2022 support describes the team's approach in some detail. Jupiter rolled out support "after rigorous testing," and the integration required "significant upgrades to our backend, UI and aggregator program." The first Token-2022-native venue Jupiter integrated was a small specialty DEX, and the post mentions early Token-2022 examples including a meme token with a 6.9% transfer fee and another fee-on-transfer-style token used as deflationary.

Three details from that forum post matter for anyone building on top of Jupiter. First, Jupiter built a separate token list API specifically so it would not affect existing partners — which means that any consumer of the Jupiter token list has to know whether they are reading the Token-2022 list or the legacy list. Second, the team explicitly cautioned that "not all of whom support 2022 yet" — meaning some wallets and dApps that trust Jupiter quotes will fail when they try to actually settle a Token-2022 swap themselves. Third, the team's general advice was, in its own words, that users "should stick to the standard token library unless there is a strong need for those specific features." That is a striking statement coming from the team that just shipped support.

More recently, Jupiter's Ultra v3 release continued evolving the offering — including support for Token-2022 and meme-coin-to-meme-coin pairs and a reduced minimum trade size around the $10 mark. For arbitrage purposes, the salient fact is that Jupiter's Token-2022 support is fundamentally derivative: it can only route through underlying pools that themselves support Token-2022. If Raydium's CLMM, Orca's Whirlpool V2, and Meteora's DLMM all support a given mint, Jupiter can stitch them together; if none of them do, no amount of aggregation will help.

Phoenix, OpenBook, Lifinity: The Unknown Tier

This is where the field map gets honest. Three names that show up in any Solana DEX list — Phoenix, OpenBook, and Lifinity — do not have, as far as I have been able to find, a clear public statement on Token-2022 support.

Phoenix is an on-chain CLOB built by Ellipsis Labs. Its design is fundamentally different from an AMM: rather than constant-product math against pooled reserves, it matches limit orders. I cannot find an official Phoenix announcement that confirms or denies Token-2022 routability. Absence of a statement is not the same as a denial, and the only honest thing to do is mark Phoenix as "verify directly against the program" until I can confirm.

OpenBook is a community-run fork of the older Serum CLOB. Its docs reference "any SPL token" — and that phrasing is genuinely ambiguous, because in Solana developer parlance "SPL token" sometimes means the legacy program specifically and sometimes means the broader family. Without an explicit Token-2022 statement, I cannot tell from documentation alone which interpretation applies here.

Lifinity is an oracle-based AMM. There is one floating mention I came across suggesting service wind-down plans, but it is a single source and I would not bet on it without verification. There is no Token-2022 support announcement that I can find. Same conclusion as Phoenix: unknown until I check on-chain.

The practical handling for the unknown tier is the same in all three cases. The router treats them as legacy-only by default, which is the safe assumption. If I want to expand coverage to Token-2022 mints through any of them, I need to do my own verification — read the program, write a probe transaction on devnet, watch what happens — and only then update the routing table.

The Two Architectural Patterns

Stepping back from the per-DEX detail, there are really only two patterns at work. Each protocol has different characteristics; the choice of which to support matters more than the per-extension table.

The first pattern is dynamic token program detection. The pool program inspects the mint at runtime, identifies which token program owns it, and dispatches into the appropriate CPI path. Raydium CLMM/CPMM, Orca Whirlpool V2, and Meteora DLMM all fall into this bucket. Importantly, dynamic detection requires more than just the right CPI — it also requires extension-aware swap math. A pool that detects Token-2022 but applies legacy math will misquote any mint with a transfer fee.

The second pattern is a fixed token program ID. The pool program assumes one specific token program, hardcoded as a constant. Any mint owned by a different program will either be rejected at the account-validation step or, in the worst case, processed against the wrong assumptions. Raydium AMM v4 falls in this bucket explicitly. Phoenix, OpenBook, and Lifinity I cannot confirm one way or the other without direct inspection.

For a builder, knowing which pattern a given DEX uses is more useful than memorizing the extension support table, because the pattern determines whether the DEX can ever support Token-2022 without a program upgrade. If a pool is on the fixed-program path, it is a redeploy away from being relevant; until then, it is structurally legacy-only.

How a Router Should Behave

Given all of this, the routing logic I am converging on has a few invariants.

The first invariant is that the token program owning the mint is part of the routing key, not just the mint address. Two mints with identical-looking addresses can be on different token programs, and the wrong assumption silently corrupts every downstream calculation. Every quote pipeline has to record which program owns the mint as a first-class field.

The second invariant is that DEXs have to be tagged with their Token-2022 capability per pool type, not per protocol. Raydium-the-protocol is not a single answer; Raydium-AMM-v4 and Raydium-CLMM are different answers. The same holds for any future split where a protocol ships a new pool type that has different program-level support.

The third invariant is that extension semantics have to be respected in the math, not just the dispatch. Transfer fees in particular need to be folded into output-amount calculations on the recipient side, because that is who actually "pays" the fee per the chain's mechanics. A router that gets the dispatch right but applies legacy math gets every Token-2022 quote wrong by exactly the fee.

The fourth invariant is that the unknown tier stays in a default-deny state. If I have not verified a DEX-pool-mint combination against an actual on-chain probe, I do not route through it for Token-2022 mints. Optimism is the wrong default in a domain where the failure mode is silent miscalculation followed by a real, broadcast, settled transaction.

Implications: A Slow Migration That Is Not Done

What this map shows me, more than any individual DEX detail, is that Solana's Token-2022 transition is a slow, partial migration. The big AMMs have moved. The biggest legacy pool type on Raydium has not. The biggest aggregator has shipped support but kept its standard advice conservative. Meteora gates the more dangerous extensions behind a manual review desk. The CLOBs are still mostly silent.

The Solana Foundation's docs note that Token-2022 has been audited extensively — Halborn (2022, 2024), Zellic (2022), Trail of Bits (2023), NCC Group (2023), OtterSec (2023, twice), and Certora (2024) — for a total of seven firms across eight engagements. That is a lot of audit coverage by any measure. The remaining friction is not in the program itself; it is in the long tail of integrations that have to opt in to a more complex token model.

For an arbitrage builder, the takeaway is that the migration is real but uneven, and the cost of treating it as binary — "Token-2022 supported" vs not — is paying for fantasy quotes against pools that cannot actually fulfill them. The map has to be built per-DEX, per-pool-type, and ideally per-extension, and it has to be re-checked over time because the entries that say "unknown" today might say "supported" after the next protocol upgrade.

Key Takeaways

• Token-2022 lives at a different program address from the legacy SPL Token program, so any DEX that hardcodes a single program ID is structurally unable to route Token-2022 mints until it is upgraded.
• Three big AMMs explicitly support Token-2022 today: Raydium's CLMM and CPMM (announced July 19, 2023), Orca's Whirlpool V2 (announced May 28, 2024), and Meteora's DLMM. Raydium's legacy AMM v4 does not.
• Each supporting DEX draws its own permissionless-vs-permissioned line. Orca uses a TokenBadge whitelist; Meteora uses a Google Form plus Discord review for twenty-five gated extensions; Raydium permits a smaller set of extensions but blocks Permanent Delegate, Non-Transferable, and Default Account State.
• Jupiter's Token-2022 support is derivative — it can only aggregate through underlying pools that themselves support the standard, and the team built a separate token list API to keep legacy partners isolated.
• Phoenix, OpenBook, and Lifinity have no clear public confirmation of Token-2022 support, so a router should treat them as legacy-only by default until verified directly against the on-chain program.

Sources

• TokenExtensions Support — Whirlpools docs
• Raydium Support for Token-2022 — Raydium Medium
• Token 2022 Extensions — Meteora Documentation
• Jupiter Token 2022 Support (Archived) — Jupiter Forum
• Token-2022 Program Documentation — Solana Foundation
• What is Token-2022 — Helius Blog
• Solana Token-2022: Transfer Hooks and Fee-on-Transfer — Chainstack
• The Solana Token 2022 Specification — RareSkills