The admin plane of Token-2022 tokens

A Token-2022 mint is not only a supply and a decimals field. Depending on its extensions, it can name more than a dozen keys that can mint, freeze, move holders' tokens, change fees, change what the token is called, or decide whether a transfer succeeds at all. Those keys are the token's admin plane, and anyone holding or integrating the token should know who holds each one.

The Token-2022 source lists every authority type in one enum [1]. This post goes through the ones that matter most, then shows how to read them from public data.

The authorities, one by one

Mint authority. Can create new tokens [1]. For a stablecoin this is the issuance key. If it is set to none, supply is fixed for good.

Freeze authority. Can freeze any token account of the mint, and thaw it [1]. A frozen account cannot send. Integrators need to know that a deposit address can be frozen by someone other than its owner.

Permanent delegate. Can "transfer or burn any tokens for a mint" [1], from any holder's account, without the holder signing [3]. This is the strongest power on the list. The Solana Foundation lists "stablecoin regulatory compliance with freeze & seize orders" as its use case [12]. For a holder, it means the balance in their account is one the issuer can take back.

Transfer hook program and its authority. When a mint has a transfer hook, every transfer calls the hook program, and if that call fails, the transfer fails [3]. The transfer hook authority can point the mint at a different hook program [1][2]. There is a second key behind this one: the hook program's own upgrade authority, which can change the hook's code without touching the mint. An integrator who checks only the mint misses it.

Confidential transfer authority and auditor key. The confidential transfer mint configuration has an authority, a flag saying whether new accounts are approved automatically, and an optional auditor ElGamal public key [2]. The source describes the auditor key as "Authority to decode any transfer amount in a confidential transfer" [2]. Solana's docs say the holder of the auditor secret key can decrypt transfer amounts for that mint, but cannot authorise transfers or read an account's full confidential balance, and that the authority can set, rotate or clear the auditor key [8]. Whoever holds the auditor secret can read every confidential transfer amount on the mint.

Metadata update authority. For metadata stored with the token metadata extension, this key can change the name, symbol, URI and any extra fields, and hand the authority to someone else [6]. A separate metadata pointer authority can change which account the mint says holds its metadata [1][2]. Wallets and explorers show this text to users, so whoever holds it can make a token look like something else.

Mint close authority. Can close the mint account, but only when supply is zero [4]. Integrators that keep a mint on an allowlist should not assume the account exists forever.

Interest-bearing rate authority. Can change the interest rate [1][2]. The rate does not create tokens: the extension converts a raw amount into a displayed amount [2]. Any system that reads the displayed ("UI") amount instead of the raw amount will see balances change when the rate changes.

Transfer fee config authority and withdraw-withheld authority. The first can set a new fee, in basis points up to 100%, with a maximum per transfer [2]. The program schedules a new fee two epochs ahead, with the comment "set two epochs ahead to avoid rug pulls at the end of an epoch" [5]. The second key collects the fees withheld from transfers [2]. A payment flow that assumes the amount sent is the amount received breaks the day a fee is turned on.

The enum lists others too, such as pause, scaled UI amount and group pointers. It is the complete list for the release you are looking at [1].

Confidential transfers are back

Confidential transfers were switched off in June 2025 after a reported flaw in the ZK ElGamal Proof program, with no known exploit [10]. In the Token-2022 repository's tracking issue, a comment on 29 June 2026 records the feature as live on mainnet again, and the issue was closed on 3 September 2026 [11]. Solana's docs now say the proof program "is enabled on mainnet and devnet" [9]. For an issuer turning this on, the auditor key and the confidential transfer authority join the admin plane, and should be held with the same care as the mint authority.

Why this matters for stablecoin issuers

Regulated issuers usually want freeze, seize and pause powers, and Token-2022 provides them. The Solana Foundation notes that issuers have used permanent delegation, metadata pointers and transfer hooks to launch stablecoins [12]. Solana's Token ACL guide moves a mint's freeze authority to a program-derived address controlled by a gating program [13], which means the real holder of the freeze power is whoever can upgrade that program.

So the questions an exchange, card programme or payments team should ask are not "does the token have a permanent delegate?" but:

• Who holds each authority: one key, a multisig, or a program?
• If it is a program, who can upgrade that program?
• If it is a multisig, what is its threshold and time lock?
• Which authorities could be set to none and have not been?

How to inspect a mint

Both methods below are read-only. The spl-token CLI prints every authority and extension of a mint [7]:

spl-token display <mint-address> --url mainnet-beta

The same data is available from any RPC endpoint with jsonParsed encoding:

curl -s https://api.mainnet-beta.solana.com \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getAccountInfo","params":["<mint-address>",{"encoding":"jsonParsed"}]}' \
  | jq '.result.value.data.parsed.info | {mintAuthority, freezeAuthority, extensions}'

Replace <mint-address> with the mint. In the extensions array, look for these fields:

If metadataAddress points to an account other than the mint, read that account too. For a transfer hook programId, or any authority that is a program, check who can upgrade that program. Our open-source scanner does this read-only, including Squads v4 multisig settings [14]:

cargo install --locked solana-authority-scan
export SOLANA_MAINNET_RPC_URL=https://api.mainnet-beta.solana.com
solana-authority-scan --cluster mainnet <hook-program-id>

None of this tells you how the keys are stored or who holds them. That takes asking the issuer.

What we do: our stablecoin and admin-plane reviews map who controls a token and the programs behind it. They are not audits and not legal or regulatory advice. See https://centrob.co/#solana.