Solana Token Authorities Explained
- DEXArea
- Wiki
- Solana
- Token Security
- Token Authorities
Introduction
Token authorities on Solana are special keys or programs. They control specific actions related to SPL tokens. Understanding these authorities is crucial for managing token projects. It also helps ensure safety and build trust. This page covers different authority types, their functions, and best practices for their management.

Token Authorities - Understanding Control and Permissions on Solana
Simple Definitions
| Term | Definition | Scope |
|---|---|---|
| Authority | A keypair or program that has the power to perform specific, restricted actions on a token mint or account | Token mint or account level |
| Owner | The keypair that controls a specific token account. The owner can transfer tokens from their account or delegate spending permissions | Individual token account |
| Delegate | A temporary permission granted by an account owner to another key. This allows the delegate to act on the owner’s account, typically for a specified amount | Temporary, account-specific |
| Immutability | A state where certain token properties, like metadata, cannot be changed. This is achieved by setting the update authority to null | Permanent, irreversible |
Authority Types (At a Glance)
Solana’s SPL Token Program defines several types of authorities. Each has a distinct role:
Core Authority Overview
| Authority Type | Scope | Primary Function | Risk Level |
|---|---|---|---|
| Mint authority | Mint (global) | Increase total supply by minting new tokens | High |
| Freeze authority | Mint (global) | Freeze/unfreeze token accounts | Medium |
| Update authority (metadata) | Metadata account (Metaplex) | Change name, symbol, or URI | Low |
| Account owner | Single token account | Transfer/spend tokens | Low |
| Delegate | Single token account | Spend within allowance | Medium |
| Permanent delegate (Token-2022) | Mint-configured | Policy-bound operations | High |
Mint authority: This authority can increase the total supply of a token. It does this by minting new tokens into existence.
Freeze authority: This authority can freeze or unfreeze token accounts. When an account is frozen, no tokens can be transferred from it.
Update authority (metadata): This authority can change the name, symbol, or URI of a token’s metadata. This power exists until the metadata is made immutable. Note: This applies to the Metadata account from the Metaplex Token Metadata program, not to the SPL mint itself.
Account owner & delegate: The account owner has full control over their token account. They can transfer tokens. They can also delegate temporary spending permissions to another key.
Permanent delegate (Token-2022): Introduced with Token-2022, this is an always-on delegate. It is configured at the mint level. It allows for policy-bound operations on token accounts.
Actions & Who Can Do Them
Each authority type is responsible for specific actions. Understanding these roles is key to secure token management. The principle of least privilege is important here. This means granting only the necessary permissions to each key or program.
Setting, Transferring, and Delegating
Authorities are typically set during mint creation. For example, the mint authority and freeze authority are defined when the token is first created. However, most authorities can be transferred later. This means assigning control to a new key or a multisig program.
Delegation is different from transferring an authority. Delegation grants temporary permission to spend tokens from a specific account. The account owner approves this with an allowance. This is common for dApps that need to spend tokens on a user’s behalf.
Authority Types Overview Table
| Authority Type | Scope | Typical Actions | How to Grant/Change | Can Revoke? | Key Risks |
|---|---|---|---|---|---|
| Mint authority | Mint (global) | Mint new supply | Set at creation or transfer later | ✅ | Over-minting, dilution |
| Freeze authority | Mint (global) | Freeze/unfreeze accounts | Set/transfer | ✅ (or unset entirely at creation) | Abuse, user lockouts |
| Update authority (metadata) | Metadata account (Metaplex) | Change name/symbol/URI | Set/transfer; or nullify | ✅ | Brand spoof, confusion |
| Account owner | Single token account | Transfer/spend | Ownership of the account | ❌ (ownership only changes if account is reassigned) | Key loss, theft |
| Delegate | Single token account | Spend within allowance | Owner approves with allowance | ✅ (by account owner) | Excess allowance misuse |
| Permanent delegate (Token-2022) | Mint-configured | Policy-bound operations | Set at mint creation | ❌ (irreversible) | Overreach if mis-set |
Revoking & Locking (Safety Controls)
Revoking authorities is a critical security measure. It reduces the risk of unauthorized actions. It also enhances trust in a token.
Security Control Checklist
✅ Revoke mint authority: This prevents any further tokens from being minted. It effectively caps the token’s supply. This is often done after the initial token distribution is complete.
✅ Revoke freeze authority: This ensures that no one can freeze token accounts. It gives users full control over their tokens. This is important for decentralization.
✅ Make metadata immutable: This is done by setting the update authority to null. Once immutable, the token’s name, symbol, and URI cannot be changed. This provides permanence and builds trust.
Here’s a typical order of operations for a token project:
Governance & Multisig
For enhanced security and decentralized control, authorities can be held by a multisig wallet or a DAO (Decentralized Autonomous Organization). A multisig requires multiple approvals for any action. This prevents a single point of failure.
Governance Best Practices
✅ Key rotation: Regularly changing the keys that hold authorities reduces risk
✅ Role separation: Assigning different authorities to different keys or entities minimizes impact if one key is compromised
✅ Emergency playbooks: Establishing clear procedures for emergency situations
✅ Audit trails: Maintaining comprehensive logs of all authority changes and actions
Lifecycle Recommendations Table
| Phase | Mint Authority | Freeze Authority | Update Authority | Notes |
|---|---|---|---|---|
| Development (devnet) | Enabled | Enabled (or unset entirely) | Enabled | Fast iteration; document changes |
| Launch (mainnet, early) | Enabled (limited) | Enabled (incident-ready) | Enabled (stability) | Publish policy & schedule |
| Post-stabilization | Consider revoke | Consider revoke | Consider immutable | Improve trust & listings |
| Mature/Final | Revoked | Revoked | Immutable | Strong trust signals |
📝 Conclusion
Token authorities are powerful tools. They shape the control and trust associated with an SPL token. Minimizing privileges over time is a key best practice. Clearly communicating changes to users is also vital. Proper management of authorities ensures the long-term health and security of a token project.
❓ FAQ
Q: What should I revoke first: mint or freeze authority?
A: The order of revocation depends on your project’s needs. Often, mint authority is revoked first to cap supply, followed by freeze authority to prevent account freezes.
Q: Does making metadata immutable affect supply?
A: No, making metadata immutable only affects the ability to change the token’s descriptive information (name, symbol, URI). It does not impact the token’s supply.
Q: How is a delegate different from an authority?
A: An authority is a key or program with a broad power over a token or mint. A delegate is a temporary permission granted by an account owner to another key to perform specific actions on their behalf, usually for a limited amount or time.
Q: Can I move authorities to a multisig later?
A: Yes, authorities can be transferred to a multisig wallet or a DAO program. This is a common practice for enhancing security and decentralizing control over critical token functions.
📚 References and Further Reading
- Solana SPL Token Program Documentation - Official token program reference
- Metaplex Token Metadata - Metadata authority management
- Solana Security Best Practices - Security guidelines