# Token Authority Management Solana tokens have three distinct authorities that each carry different risk profiles: mint authority, freeze authority, and metadata update authority. Each of these authorities, if mismanaged, can be used to attack your token holders in different ways. Mint authority can create unlimited new tokens -- infinite inflation. Freeze authority can freeze any token account -- locking user funds indefinitely. Metadata update authority can change the token's name, symbol, and image -- enabling phishing and impersonation. This article covers what each authority does, when to keep or revoke each one, how to transfer authorities to multisigs or PDAs, how to revoke authorities permanently, and how to document and monitor authority changes. **Applies to:** All Solana protocols that issue or manage tokens **Audience:** Token issuers, protocol developers, security auditors **Related:** [[upgrade-authority]], [[squads]], [[authority-design]], [[pdas-and-authority]] --- ## 1. The Three Token Authorities Every SPL Token mint has three authority fields. Each can be set to a pubkey (EOA, multisig vault PDA, or program PDA) or set to `None` (permanently revoked). ### 1.1 Mint Authority The mint authority is the account authorized to call `MintTo` or `MintToChecked`, creating new tokens out of thin air and depositing them into any token account for that mint. **What it can do:** - Create unlimited new tokens at any time - Cause infinite inflation, diluting all existing holders - Mint tokens to the attacker's own account - Destroy the token's economic model **Why it exists:** - Reward emission (staking rewards, liquidity mining) - Scheduled vesting or unlock programs - Protocol-controlled inflation (e.g., rebasing tokens) - Governance-authorized supply expansions **The danger:** If compromised, a mint authority is a money printer. The attacker mints billions of tokens, dumps them on a DEX, and drains all liquidity. This has happened repeatedly across multiple chains. There is no recovery -- the tokens are minted, the liquidity is drained, and the market cap is destroyed. ### 1.2 Freeze Authority The freeze authority can call `FreezeAccount` to freeze any token account for the given mint. A frozen token account cannot send or receive tokens. The freeze authority can also unfreeze accounts with `ThawAccount`. **What it can do:** - Freeze any holder's token account, preventing transfers - Selectively freeze specific addresses (censorship) - Freeze DEX liquidity pool token accounts, halting trading - Effectively lock user funds indefinitely **Why it exists:** - Regulatory compliance (e.g., freezing sanctioned addresses for stablecoins) - Emergency response (freeze a hacker's token account during an exploit) - Token migration (freeze old token accounts during a migration to a new mint) **The danger:** A compromised freeze authority can lock every token holder out of their tokens. For DeFi tokens, freezing LP token accounts on a DEX effectively kills the market. Even without draining funds directly, this can destroy the token's value and usability. ### 1.3 Metadata Update Authority If using Metaplex Token Metadata (the standard for Solana token metadata), the update authority on the metadata account can change the token's name, symbol, URI (which points to the token image and description), and other metadata fields. **What it can do:** - Change the token name and symbol to impersonate another token (e.g., rename your token to "USDC") - Change the token image to a phishing link or a different brand - Change the URI to point to a malicious metadata JSON - Modify the `isMutable` flag to lock in malicious changes **Why it exists:** - Correcting metadata errors after initial token creation - Updating branding (new logo, name change) - Pointing to updated off-chain metadata **The danger:** A compromised metadata authority turns your legitimate token into a phishing tool. The attacker renames it, changes the image, and tricks users or aggregators into treating it as a different token. While this does not directly drain funds, it enables social engineering attacks at scale. --- ## 2. When to Keep vs. Revoke Each Authority The decision to keep or revoke an authority depends on whether the protocol has a legitimate future need for it. Revoking an authority permanently eliminates a class of attacks but also permanently eliminates a capability. ### 2.1 Mint Authority **Keep if:** - The token has a planned inflation schedule (staking rewards, emission curves) - The protocol needs to mint tokens for incentives, grants, or ecosystem funding - The token has governance-controlled supply adjustments - The token is used as a receipt/share token that must be minted when users deposit **Revoke if:** - The token supply is meant to be fixed forever (e.g., a governance token with a fixed cap that has been fully minted) - All tokens have been minted and distributed - The protocol's value proposition depends on a provably fixed supply **If keeping:** Transfer to a multisig or use a PDA controlled by your program (see Sections 3 and 4). Never leave it as a single EOA keypair on mainnet. ### 2.2 Freeze Authority **Keep if:** - The token is a stablecoin or regulated asset that requires compliance freezing - The protocol has specific, documented regulatory requirements that mandate freeze capability - The token is used in a system that requires emergency freeze as an incident response mechanism **Revoke if:** - The token is a DeFi governance token - The token is a utility token - The token is an LP token - The protocol has no regulatory requirement for freezing - Users and integrators expect sovereign ownership of their tokens **For most DeFi tokens, freeze authority should be revoked.** The presence of a freeze authority creates trust assumptions that DeFi integrators may not accept. Many protocols and aggregators will not integrate tokens with an active freeze authority. ### 2.3 Metadata Update Authority **Keep temporarily if:** - The token was just launched and metadata may need corrections - Branding is still being finalized - You need to update the metadata URI to point to a new off-chain storage location **Revoke when:** - Metadata is finalized and correct - The token is listed on exchanges and aggregators (metadata changes after listing can cause confusion) - Usually within days to weeks of launch, not months **Best practice:** Set up metadata correctly before launch. Verify it renders correctly in wallets, explorers, and aggregators. Then revoke the update authority. If you need to keep it temporarily, transfer it to the same multisig that holds other protocol authorities. --- ## 3. The PDA Authority Pattern A common and important pattern on Solana is to set token authorities to PDAs (Program Derived Addresses) controlled by your program. This means the program logic determines when minting, freezing, or metadata updates can occur -- not a human signer. ### 3.1 How It Works Instead of setting the mint authority to a keypair, you set it to a PDA derived from your program: ``` Seeds: ["mint_authority"] Program: YourProgramId ``` The resulting PDA has no private key. Only your program can sign for it using `invoke_signed` with the correct seeds and bump. This means minting can only happen when your program's instruction logic allows it. ### 3.2 The Authority Chain When a token authority is a PDA, the real authority chain is: ``` Mint Authority (PDA) -> Controlled by: Program Logic -> Controlled by: Upgrade Authority -> Controlled by: Multisig / Governance ``` **This is critical to understand:** The PDA is controlled by program logic. But the upgrade authority can change the program logic. Therefore, the upgrade authority is the true root of trust for any PDA-controlled token authority. A program with a PDA mint authority and a single-keypair upgrade authority is NOT meaningfully more secure than having a single-keypair mint authority. The upgrade authority holder can deploy new code where the PDA mints unlimited tokens unconditionally. **The security of PDA authorities is bounded by the security of the upgrade authority.** See [[upgrade-authority]] for securing the upgrade authority and [[pdas-and-authority]] for the full treatment of PDA authority chains. ### 3.3 When to Use PDA Authorities Use PDA authorities when: - Minting, freezing, or metadata updates should be governed by program logic (e.g., "only mint when a user deposits collateral") - You want the rules for token operations to be auditable, deterministic, and on-chain - You want to remove human discretion from token operations Use multisig authorities (not PDAs) when: - Token operations require human judgment that cannot be encoded in program logic - The authority should be independent of any specific program's upgrade cycle - You want the authority to be directly visible on explorers without needing to trace through program logic --- ## 4. Managing Authorities with the CLI ### 4.1 Inspecting Current Authorities Check the current authorities on a mint: ``` spl-token display <MINT_ADDRESS> ``` Example output: ``` SPL Token Mint Address: 7dHbWXmci3dT8UFYWYZweBLXgycu7Y3iL6trKn1Y7ARj Program: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA Supply: 1000000000 Decimals: 6 Mint authority: 5Yd3... (or "Disabled" if revoked) Freeze authority: 8Kp2... (or "Disabled" if revoked) ``` For metadata authority, use the Metaplex CLI or inspect the metadata account directly. ### 4.2 Transferring Mint Authority to a Multisig Transfer the mint authority to a Squads vault PDA: ``` spl-token authorize <MINT_ADDRESS> mint <NEW_AUTHORITY_PUBKEY> ``` Example: ``` spl-token authorize 7dHbWXmci3dT8UFYWYZweBLXgycu7Y3iL6trKn1Y7ARj \ mint \ 5Yd3nR1pKmQxYgS2bR7mA1vCkPHq9fXgU2VwJ8hT4KmN ``` **Verification steps:** 1. Before transferring, confirm the current authority with `spl-token display` 2. Double-check the new authority address character by character with a second team member 3. After transferring, run `spl-token display` again to verify the authority changed 4. Test by minting a small amount through the new authority to confirm the workflow works ### 4.3 Transferring Freeze Authority ``` spl-token authorize <MINT_ADDRESS> freeze <NEW_AUTHORITY_PUBKEY> ``` ### 4.4 Revoking Mint Authority Permanently ``` spl-token authorize <MINT_ADDRESS> mint --disable ``` **This is irreversible.** After this command, no one can ever mint new tokens for this mint. Verify that you truly intend to fix the supply permanently before executing. ### 4.5 Revoking Freeze Authority Permanently ``` spl-token authorize <MINT_ADDRESS> freeze --disable ``` **This is irreversible.** After this command, no one can ever freeze token accounts for this mint. ### 4.6 Revoking Metadata Update Authority Using the Metaplex CLI: ``` metaboss update immutable --mint <MINT_ADDRESS> --keypair <CURRENT_AUTHORITY_KEYPAIR> ``` Or set `isMutable` to `false` on the metadata account, which permanently locks the metadata. ### 4.7 Critical Warnings - **Double-check every address.** A typo in the new authority address means permanent loss of that authority. There is no recovery. - **Test on devnet first.** Run the entire authority transfer workflow on devnet before doing it on mainnet. - **Coordinate with the team.** At least two people should independently verify the target address before executing. - **Do not confuse `--disable` with a transfer.** `--disable` is permanent revocation. You cannot undo it. - **Confirm authority type.** Do not accidentally revoke the wrong authority (e.g., revoking freeze when you meant to revoke mint). --- ## 5. Documentation Requirements Every token authority should be documented with the following information. This documentation should live in your asset inventory and be reviewed during [[access-reviews]]. ### 5.1 What to Document For each authority (mint, freeze, metadata) on each token mint your protocol manages: | Field | Description | |-------|-------------| | Mint address | The token mint pubkey | | Authority type | Mint, freeze, or metadata | | Current holder | The pubkey currently holding the authority (EOA, multisig vault PDA, program PDA, or "revoked") | | Holder type | EOA keypair, Squads multisig vault, program PDA, governance, or revoked | | If multisig: members and threshold | Who are the signers and what is the quorum | | If PDA: program ID and seeds | Which program controls this PDA and with what seed derivation | | If PDA: upgrade authority of that program | Who controls the program that controls the PDA -- this is the real root | | Rationale for keeping | Why this authority has not been revoked (e.g., "needed for staking reward emissions") | | Revocation plan | When and under what conditions this authority will be revoked, if applicable | ### 5.2 Example Documentation ``` Token: EXAMPLE (7dHbWXmci3dT8UFYWYZweBLXgycu7Y3iL6trKn1Y7ARj) Mint Authority: Holder: PDA of StakingProgram (seeds: ["mint_auth"], bump: 254) Program: ExampleStaking111111111111111111111111111 Upgrade Authority: Squads vault 5Yd3... (4-of-7, timelocked 48h) Rationale: Required for staking reward emissions Revocation Plan: Will revoke when emission schedule concludes (est. Q4 2026) Freeze Authority: Status: REVOKED (disabled at token creation) Rationale: No regulatory requirement. DeFi token with sovereign ownership. Metadata Update Authority: Status: REVOKED (set to immutable after launch verification) Rationale: Metadata is finalized. No further changes needed. ``` --- ## 6. Monitoring Authority Changes Authority changes are critical events that should always trigger alerts. An unexpected authority change is a potential compromise in progress. ### 6.1 What to Monitor | Event | Severity | Response | |-------|----------|----------| | Mint authority changed | Critical | Immediate investigation. Verify this was an authorized, planned change. | | Freeze authority changed | Critical | Immediate investigation. | | Metadata update authority changed | High | Verify this was planned. Check if metadata was also changed. | | Mint authority revoked | High | Verify this was intentional. This is permanent. | | Freeze authority revoked | Medium | Verify this was intentional. Usually positive. | | Metadata set to immutable | Medium | Verify this was intentional. | | Large mint event | Critical | Verify this matches expected emission schedule. Unexpected minting is a compromise indicator. | | Token account frozen | High | Verify this was authorized (compliance action) or investigate (potential abuse). | | Metadata changed (name, symbol, URI) | High | Verify this was planned. Check for phishing indicators. | ### 6.2 How to Monitor Set up monitoring for `SetAuthority` instructions targeting your token mints. Most on-chain monitoring solutions (see [[monitoring]]) can filter for specific instruction types on specific accounts. For `MintTo` / `MintToChecked` instructions, set up alerts that compare minted amounts against your expected emission schedule. Any minting outside the schedule is an anomaly. For metadata changes, monitor the Metaplex Token Metadata program for `UpdateMetadata` instructions targeting your metadata accounts. --- ## 7. Common Mistakes | Mistake | Consequence | Prevention | |---------|-------------|------------| | Leaving mint authority as a single EOA keypair on mainnet | One compromised key = infinite inflation and total market value destruction | Transfer to multisig or PDA before mainnet launch | | Not revoking freeze authority on a DeFi token | Integrators may refuse to integrate. Users face censorship risk. Compromised freeze authority can lock all holders. | Revoke freeze authority unless there is a specific regulatory requirement | | Keeping metadata update authority indefinitely | Phishing attack vector. Attacker changes name/symbol/image to impersonate another token. | Revoke after metadata is finalized, usually within days of launch | | Believing a PDA mint authority is secure without securing the upgrade authority | The upgrade authority can change the program to mint unconditionally via the PDA | Secure the upgrade authority with the same rigor as the mint authority itself | | Not documenting which PDAs control which authorities | Team cannot quickly verify who truly controls the authority during an incident | Maintain authority documentation with full PDA derivation details | | Not testing authority transfers on devnet | Typo or wrong address on mainnet = permanent loss | Always test the full flow on devnet first | | Revoking the wrong authority type | Permanently losing a capability you needed | Read the CLI output carefully. Verify you are revoking the intended authority type. | | Not monitoring authority changes | Authority compromise goes undetected until the attacker acts | Set up alerts for `SetAuthority` instructions on your mints | | Confusing Token-2022 authorities with legacy SPL Token | Token-2022 has additional authority types (transfer fee authority, confidential transfer authority, etc.) | Understand which token program your mint uses and document all applicable authorities | --- ## 8. Token-2022 Additional Authorities If your token uses the Token-2022 (Token Extensions) program, there are additional authority types beyond the standard three: | Authority | What It Controls | Risk Level | |-----------|-----------------|------------| | Transfer fee authority | Can change transfer fee rate and withdraw collected fees | High -- can set fees up to 100% of transfers | | Confidential transfer authority | Can configure confidential transfer settings | Medium | | Transfer hook authority | Can change the transfer hook program | Critical -- malicious hook can block or redirect transfers | | Metadata pointer authority | Can change where metadata is stored | Medium | | Group pointer authority | Can change group membership | Low | | Close authority | Can close the mint account | High -- destroys the token | Each of these authorities follows the same security principles: document who holds it, transfer to multisig or PDA, revoke if not needed, and monitor for changes. --- ## Relevant Controls The following controls from the [[general/control-registry|Control Registry]] apply to this topic. Refer to the Control Registry for level-specific requirements (L1/L2/L3/L4). Relevant control families: **SOS-TOK**. --- ## Related Articles - [[upgrade-authority]] -- Program upgrade authority management (the true root of PDA authorities) - [[squads]] -- Squads Protocol v4 multisig for holding token authorities - [[authority-design]] -- In-protocol authority architecture and separation - [[pdas-and-authority]] -- How PDAs interact with authority design - [[monitoring]] -- On-chain monitoring and alerting - [[access-reviews]] -- Periodic access reviews including token authority review --- *This article is part of the [[README|SOS Standard Security Knowledge Base]]. For the complete standard, see [[general/sos-standard|SOS Standard]].*