TOKEN STANDARDS — Solana × Token-2022

Token-2022's Newest Extensions: Pausable and Permissioned Burn

6 min read
SolanaToken-2022RWASecurity

The post on permissioned tokens explained Token ACL: an allowlist that is a compliance feature when a regulated issuer runs it and a honeypot when an anonymous deployer does. The same year that program shipped, Token-2022 gained two extensions with the same double edge. Pausable lets an authority halt every transfer, mint and burn on a mint. Permissioned Burn puts a gate on who may destroy tokens.

Both are legitimate, both are on mainnet, and both appear in the validator's own account decoder — which is how you can tell whether the RPC you are reading even knows they exist. Here is what each one does, why regulated issuers asked for them, and the three questions that separate a compliance control from a trap.


Pausable: One Authority Stops the Mint

The Pausable extension adds a pause authority and a paused flag to a mint. When paused, the token program rejects transfers, mints and burns on that mint. Account creation and closing still work; balances do not move.

Why an issuer wants it: an exchange-listed stablecoin with a court order, a fund token during a redemption freeze, a security token under a trading halt. Every one of those is a legal requirement in the issuer's jurisdiction, and before the extension they were implemented with freeze authority applied account by account — slow, leaky and impossible to reverse cleanly. Pause is the same power, applied once, reversed once.

Why a buyer fears it: paused is "you cannot sell", and there is no difference at the program level between a regulated halt and a rug pull. The mechanism is identical. The difference is entirely in who holds the authority and whether that identity is accountable.


Permissioned Burn: The Gate on Destruction

Burning a token normally requires only the holder's signature. On a mint with the Permissioned Burn extension the token program rejects the standard burn instruction outright, and the extension's own burn instruction requires two signers: the holder (or their delegate) and the burn authority configured on the mint. If that authority is set to none, the program sends you back to the standard burn. Supply cannot be reduced by holders acting alone.

Why an issuer wants it: a tokenised asset whose supply is meant to track a real-world reserve cannot let holders destroy units at will — a burned token would strand its backing. Redemptions are meant to go through the issuer, who burns against a redemption. The extension makes the token's supply an issuer-controlled number in both directions.

Why it matters to a holder: less than Pausable. A permissioned burn does not stop you selling. It stops you burning, which most holders never do. But it is another authority on the mint, and every authority is a question.


Your RPC May Not Be Able to See Them

The validator's account decoder is what turns a mint's raw bytes into the JSON your wallet reads. It recognises both extensions by name. But it has a rule for extensions it does not know: it emits an entry called unparseable extension rather than failing. A wallet or explorer running against an older node, or using an older client library, will show a mint with an unnamed extension and no detail.

That is the tell to watch for. A mint whose decoded output contains an unparseable extension has a capability newer than the software reading it. Until the reader is updated, nobody using it can say what that capability is — and "I do not know what this authority does" is not a state to buy in.


The Three Questions That Separate Compliance From a Trap

The audit page on this site runs these for every mint it checks, and the logic is short enough to run by hand.

  • Who holds the authority? A pause or permissioned-burn authority held by a named issuer's known key, a multisig with published signers, or a program with published rules is a control. The same authority held by a fresh wallet with no history is a switch in an anonymous hand.
  • Does the token have an allowlist, and is it the same operator? A regulated token almost always carries Token ACL or a transfer hook with an on-chain policy alongside the pause authority. A pausable mint with no other compliance structure, launched on a memecoin launchpad, is the pattern to walk away from.
  • Can the authority be removed, and has the issuer said whether it will? Both extensions allow the authority to be set to none. An issuer that documents when and why it would pause, and what would make it renounce, is telling you the control is a control. Silence is an answer too.

Worth knowing: the platform behind this site will build permissioned tokens for issuers and will not build pause-then-rug configurations for anyone. That line is drawn on the same three questions; it is not a matter of technology.


For Issuers: The Honest Way to Hold These

If you are launching a token that legitimately needs a pause or a burn gate, the extensions are the right tool, and the way to avoid being mistaken for a rug is disclosure at the mint level, not in a chat pin:

  • Hold the authority in a multisig or a program, never a hot key.
  • Pair it with an allowlist or hook that encodes the policy, so the audit can see a compliance structure rather than a lone switch.
  • Publish the conditions under which you would pause, and the conditions under which the authority is renounced.

The audit reads on-chain state. Make the state tell the truth.


Pausable and Permissioned Burn: Questions People Actually Ask

What does the Token-2022 Pausable extension do?

A pause authority can halt every transfer, mint and burn on the mint at once, and unpause the same way. Balances do not move while paused; account creation and closing still work.

What does the Permissioned Burn extension do?

It moves burning behind a mint authority. On a mint with the extension the standard burn instruction is rejected, and the extension’s own burn needs two signers: the holder (or delegate) and the mint’s burn authority. Set the authority to none and ordinary burns work again. It is used where supply must track a real-world reserve and redemptions go through the issuer.

Why does my explorer show “unparseable extension” on a Solana mint?

The node or client library reading the mint is older than the extension. The mint has a capability the reader cannot name; update the reader before trusting the display.

Is a pausable token a scam?

Not by itself. The mechanism is the same for a regulated halt and a rug. What separates them is who holds the authority, whether it sits beside an allowlist or hook that encodes a policy, and whether the issuer has said when it would pause and renounce.


Before You Hold a Token With Either Extension

Read the mint, not the website. Both extensions appear in the decoded mint data if your reader is current; if it shows an unparseable extension, update the reader before you decide anything.

Then ask the three questions. A named authority with a policy is a token you may choose to hold under its rules. An anonymous authority with none is a token whose exit is not yours to control.

— The Mint Tells You, If You Read It —

Every authority on a mint is a question. The audit asks all of them.

The token audit reads a mint's extensions, authorities, supply and holder concentration straight from the chain — including the extensions an out-of-date explorer can only show you as "unparseable".

Audit a Token ↗Launch a permissioned token

A different pair of extensions makes a balance move with no transaction at all — interest-bearing and scaled-UI mints — and they are worth reading before you price anything issued under Token-2022.

Decoder behaviour read from the Agave validator source at commit beee69b958: account-decoder/src/parse_token_extension.rs. The semantics of Permissioned Burn described above — the standard burn rejected, the extension's own burn requiring both the holder and the mint's burn authority, and the fall back to the standard burn when that authority is none — were read from the Token-2022 program source and checked against mainnet on 17 September 2026.

xroot.devOn-chain research, published in full
𝕏 @xrootdev
← Back to all notes