A successful Token-2022 transfer can leave the recipient with fewer spendable tokens because the mint has a transfer-fee extension. Check the exact mint, its fee configuration and the receiving account's usable amount. This token-denominated deduction is separate from the transaction's SOL network cost, and it does not apply automatically to every Token-2022 asset.
Begin with the mint, not the ticker
Solana's Token Extensions Program supports optional features attached to mints and token accounts. The official extensions overview lists transfer-fee configuration separately from other capabilities. The presence of Token-2022 as the governing program therefore tells you which feature set is possible; it does not tell you which extensions a particular token enabled.
Record the actual mint from the transaction and compare it with the issuer's verified reference. A token with the same symbol under a different mint is a different asset. Then inspect whether a transfer-fee configuration exists. Without that evidence, a shortfall should remain an unexplained difference rather than immediately being labeled a protocol fee. A wallet's familiar logo cannot supply the missing configuration.
Reconcile the gross amount, fee and usable receipt
The Token-2022 extension guide explains that transfer fees are configured on a mint and withheld on recipient accounts. The recipient cannot simply spend the withheld portion as ordinary received tokens. The configuration includes a rate in basis points, a maximum fee and separate authorities for changing the fee and withdrawing withheld tokens. These roles are not supplied merely by knowing the recipient address.
Keep that accounting distinct from the fee paid to submit the Solana transaction. One charge concerns the token's transfer rules; the other concerns network execution and is denominated in SOL. Depending on the sender's application, the displayed amount may emphasize what leaves the source or what is expected to become usable at the destination. Reconcile the actual executed transfer instead of comparing two interface labels with different meanings.
| Record to inspect | What it answers | Unit or identity to preserve | What not to assume |
|---|---|---|---|
| Mint and governing program | Which asset and token rules apply | The full mint and program identity | Every token with this ticker has the same behavior |
| Transfer-fee configuration | Whether a configured token deduction exists | Applicable rate and cap | Every Token-2022 transfer has a fee |
| Executed transfer amount | The gross token amount in this operation | Raw units and verified decimals | A rounded wallet figure is exact |
| Usable receiving amount | What the destination can ordinarily spend | The specific recipient token account | The withheld amount is freely available to its owner |
| Withheld-fee state | Whether the configured deduction explains the difference | Token-denominated fee accounting | A separate SOL top-up releases those tokens |
| Solana transaction fee | What network submission and execution cost | SOL paid by the relevant fee payer | It is the same quantity as the token deduction |
A cap can matter more than the displayed percentage
Consider a hypothetical token transfer of 100 units. Suppose its configured rate is 200 basis points, or two percent, and its maximum fee is one token. Ignoring other effects, the percentage calculation is two tokens, but the cap limits the fee to one. The recipient's usable addition is then 99 tokens. These numbers are teaching assumptions, not a quoted rate for an actual mint.
This is why recording only the percentage is insufficient. The cap and the amount use compatible token units, and the raw representation must be interpreted with the asset's decimals. For very small raw amounts, integer calculation can also matter, so use the protocol's verified calculation rather than approximate floating-point arithmetic when reconciling a real receipt. Keep the original raw values alongside any rounded explanation.
A fee authority may be able to change the configuration under the token's rules. An earlier screenshot is not automatically evidence of the setting applicable to your transfer. Establish the relevant configuration for that executed operation. If you cannot retrieve it reliably, state the missing evidence rather than selecting whichever rate makes the arithmetic fit.
Exclude other explanations before sending more
Check whether you are looking at the correct receiving account and whether the wallet hides part of a small balance. Verify the actual execution outcome, because a submitted signature is not enough to establish success. Also separate additional token behavior from the transfer-fee extension; the extensions overview describes several features, and one explanation should not be used to stand in for all of them.
When the destination is an exchange or swap service, inspect its supported token standard and crediting rules. Acceptance of an asset with a similar ticker does not prove acceptance of this particular Token-2022 mint and extension combination. Do not send a second transfer to make up the apparent shortage until the first receipt and receiving conditions have been reconciled. The second transfer can create its own fee and an additional deposit to identify.
A diagnostic sequence for a smaller receipt
- Find the actual Solana transaction and confirm the intended operation succeeded. Save its signature and the source and destination token accounts.
- Identify the mint and governing token program. Compare the mint with the issuer's verified asset reference.
- Inspect the relevant transfer-fee configuration and record both rate and cap. Keep raw amounts and decimals so units can be checked.
- Compare the gross transfer, ordinary usable receipt and any withheld fee. Record the SOL transaction charge on a separate line.
- If the destination is a platform, check its support for the exact asset and standard. Send verified support the discrepancy and evidence before authorizing another payment.
For transaction reading, the Solscan guide helps locate the relevant records. The native coin and token overview explains why the transferred asset and network-fee currency differ. These checks should make the accounting clearer without requiring a recovery phrase or permission to move another person's withheld tokens.
What to ask a receiving service
State the mint, transaction signature, gross amount and smaller amount you observed. Ask whether the asset and extension are supported and which received amount its system used. That is more useful than assuming the shortfall is a hidden exchange commission. The on-chain configuration may explain the token deduction; the service must explain its own separate accounting.
Before creating a no-account swap, verify the supported asset and network shown in the current order. Do not infer Token-2022 support from this educational diagnostic or from a general Solana label. A service fee description and a mint's transfer-fee extension describe different layers of cost, so retain both sets of evidence when comparing the final result.
FAQ
Does every Solana Token-2022 token charge a transfer fee?
No: extensions are optional, and the mint's actual configuration determines whether the transfer-fee feature applies. The program name alone is not enough to calculate a deduction.
What does the Token-2022 program ID tell me?
It identifies the governing token program, which is separate from the mint identifying the asset. Inspect both, then check the mint's enabled extensions rather than relying on a ticker.
Where is a Token-2022 transfer fee configured?
The relevant fee configuration belongs to the mint and includes a rate and maximum fee. Withheld amounts are accounted for separately from the recipient's ordinary spendable tokens and from SOL transaction costs.