In this guide
Solana’s Token Extension Program extends the familiar token model with program-level features such as transfer fees, custom transfer hooks, metadata pointers, interest-bearing configuration, non-transferability, and confidential-transfer functionality. Issuers can implement behavior that previously required separate programs and fragile integration logic.
That flexibility makes the mint configuration a product architecture decision. Extensions can affect account size, transaction construction, wallet display, DEX support, custody, compliance controls, and user expectations. Some choices cannot be casually reversed.
Translate requirements into extensions
Begin with the use case: payment, loyalty, game asset, stablecoin, permissioned asset, RWA, fee-bearing token, or non-transferable credential. For every desired behavior, identify the extension, authority, user-visible effect, integration dependencies, and legal rationale. Do not enable features because they appear in a checklist.
For a transfer hook, define the invoked program, additional accounts, update authority, failure behavior, and how third-party integrators discover the requirement.
Decide authorities before creating the mint
Inventory mint, freeze, close, metadata, transfer-fee, confidential-transfer, permanent-delegate, and hook authorities that may apply. Assign multisig or controlled roles, rotation, emergency response, and eventual revocation. If an authority can change transfer behavior, disclose that power clearly.
Record immutable choices in the deployment approval. Recreating a token later can fragment liquidity, integrations, and user trust.
- Required extension and business reason
- Authority address, signer policy, and recovery
- Wallet, exchange, DEX, custody, and analytics compatibility
- Mainnet test cases and failure states
- Public disclosure of fees, controls, and upgrade powers
Test the ecosystem, not only the program
Create accounts, mint, transfer, charge or withdraw fees, invoke hooks, freeze and thaw where applicable, integrate with wallets, and test exchange or liquidity flows. Verify how explorers and indexers display supply and metadata. Use the exact program versions and cluster conditions planned for launch.
Solana documentation notes that not every combination behaves together automatically. Maintain a current compatibility matrix rather than relying on an old blog post or prototype.
Package the launch for users and partners
BlockPlanet can scope and implement the approved token configuration, build wallet or web interfaces, prepare technical and public documentation, localize the launch, and coordinate audit and partner testing. The handover should include addresses, build and deployment records, authority map, tests, known limitations, and operating instructions.
Launch content should explain any fee, transfer restriction, privacy behavior, or administrator power before a user encounters it in a failed transaction.
Talk to BlockPlanet
Moving from an idea to a launch-ready product?
We can scope the build, prepare the market assets, coordinate specialists, and operate the launch without hiding critical dependencies.
- Token & MVP build
- Go-to-market
- Listing preparation
Frequently asked questions
Are Token Extensions the same as Token-2022?
Token-2022 is the program’s technical name; Token Extensions commonly refers to the additional capabilities it provides beyond the original SPL Token program.
Can every extension be combined?
No assumption should be made. Check current Solana documentation and test the exact combination, wallet, program, and protocol integrations planned for launch.
Should authorities be revoked immediately?
It depends on the product and operating model. Decide which controls are necessary, how they are secured and disclosed, and whether or when they become immutable before mint creation.
Research
Sources & further reading
Primary references reviewed for this guide. Rules and draft standards can change; confirm the current text before acting.
