Token-2022 extensions, explained

What the standard adds

The original SPL token program does one thing well: it moves fungible balances between accounts with no opinion about who or why. That simplicity is a feature, because it means every token behaves identically and every integration works the same way.

Token-2022 keeps that core and allows optional modules to be attached when a mint is created. Some are administrative conveniences, some change how transfers work, and one allows arbitrary program logic to run whenever the token moves.

The reason this matters to anyone buying or trading is that "it is an SPL token" stopped being a complete description of behaviour. Two tokens can look identical in a wallet and behave differently on transfer, and the difference is not visible unless you look for it.

The extensions that change behaviour

The bottom row is most of what the standard is actually used for and it is not what this page is about. The rows above it are the ones worth checking, and the permanent delegate row deserves particular attention because it is the strongest power on the list and the least discussed.

What they do to trading

Three practical effects, each of which surprises somebody regularly.

Transfer fees change the arithmetic. If a percentage is charged on every movement, then every swap loses that percentage in addition to venue fees and price impact. For a campaign routing many round trips, the effect compounds in exactly the way pool fees do, and it is invisible in any quoted swap price. Anyone modelling costs on a token with this extension needs to add it explicitly.

Hooks can restrict who trades. A hook is arbitrary logic, which means it can permit or refuse a transfer based on anything the program checks. That produces the same visible symptom as a freeze authority, and it is behind a share of the situations covered in the sell failure guide, where the reason is neither depth nor slippage.

Venue support is fragmented. Not every DEX handles every extension, and some decline tokens using the standard entirely. A token launched with extensions may therefore find fewer venues willing to host a pool, which narrows routing and reduces the liquidity available to anyone trying to buy.

Legitimate uses

It is worth being clear that these mechanisms were not built for abuse and most implementations are entirely reasonable.

Transfer fees fund treasuries and reward mechanisms in ways that would otherwise require off-chain accounting. Hooks enable compliance checks for tokens that genuinely need them. Default frozen state and permanent delegates exist for regulated instruments where an issuer has obligations that the original standard could not express.

The problem is not the capability. It is that the same capability can be used to build a token that is easy to buy and difficult to sell, and the mechanism is less visible than the older authority fields because it lives in program logic rather than in a field on an account page.

That asymmetry is why the sensible posture is neither alarm nor indifference. A token using extensions is asking to be understood rather than assumed, and the understanding takes a few minutes.

How to check a token

1. Check which program owns the mint. Explorers display this, and it tells you immediately whether extensions are even possible.
2. List the extensions in use. If it is the newer program, the mint account shows what is attached.
3. Read the parameters. A transfer fee has a rate; a hook has a program address. Both are specific rather than abstract.
4. Check for change authorities. Some extensions can have their parameters updated later, which is a separate question from whether they exist.
5. Test a small sell. The definitive check on whether you can exit is exiting, at a size you are content to lose.
6. Check venue support by seeing where the token actually has pools, since fragmented support shows up as thin liquidity.

Steps one and two take seconds. Step five is the one that matters most for a buyer, because everything else is inference and a completed sell is evidence. The on-chain reading guide covers the rest of the same screens, including the older authority fields that remain relevant.

There is a practical wrinkle for anyone running activity against such a token. A transfer fee applies to every leg, so a round trip pays it twice, and a campaign consisting of many round trips pays it on every one. That has to be added to the venue fee rather than replacing it, and the combination can be materially larger than either alone. It is entirely workable once accounted for and it is a genuinely unpleasant surprise when discovered afterwards from a shortfall nobody could explain.

If you are considering using them

For a team the calculation is different, and it comes down to whether the capability is worth the friction it creates.

Every extension narrows compatibility. Fewer venues will host the token, some tools will handle it imperfectly, and every buyer performing diligence has one more thing to satisfy themselves about. For a token that genuinely needs a compliance hook or a fee mechanism, that cost is worth paying and should be explained prominently rather than discovered.

For an ordinary community token, the honest answer is usually that the extensions are not needed and their presence creates questions that the token does not benefit from answering. The same reasoning applies as with the older authority fields, which the authorities explainer covers: capability retained without a stated purpose reads as an open-ended risk, and holders price it accordingly.

If you do use them, publish what they do in plain language alongside the technical details. The people who will find them are the people performing diligence, and finding a clear explanation is a very different experience from finding an unexplained program address attached to every transfer of a token they were considering buying.