Stellar Token Authorization and Clawback: Read the Issuer Flags

For a Stellar classic issued asset, an existing trustline, permission to transact and an issuer’s clawback capability are different facts. Check the exact asset code and issuer, then examine your own trustline’s state rather than inferring everything from the issuer’s current flags. A clawback-enabled flag describes a capability; it does not establish that a clawback has occurred or that every asset in the wallet is affected.

Know which Stellar asset the screen describes

This article concerns classic assets issued by Stellar accounts. It is not a universal description of custom contract-token code. Stellar’s asset documentation identifies classic assets by the combination of asset code and issuer. The code alone is not unique. Two tokens called USD can therefore refer to different issuers and different obligations.

Start with the asset entry in the account’s public record. Match both identifiers to the project’s independently reached official information and the asset expected by your intended recipient. A token’s display name or icon does not establish that match. If the wallet abbreviates the issuer, compare the complete identifier before drawing a conclusion about a missing payment or a restriction.

Keep XLM separate from an issued token. Native XLM is not an issuer’s credit asset with that issuer’s trustline controls. A restriction involving one issued asset is not by itself evidence that the Stellar network has frozen the entire account. Inspect the operation and asset actually involved instead of describing every failed action as a wallet-wide block.

Separate the holder’s line from the issuer’s permission

The Change Trust operation creates, updates or removes a trustline for an issued asset and includes a holding limit. Establishing that line is not the same action as the issuer granting authorization. Where issuer authorization is required, the line’s existence alone does not show that the holder can transact.

Stellar’s account reference distinguishes issuer settings such as required authorization, revocability and clawback enablement. The Allow Trust reference separately describes authorization of an existing line, including a limited state for maintaining orders. Do not treat that limited state as ordinary permission to make every transfer.

A failed action needs its own diagnosis. Stellar’s operation definitions distinguish missing trustlines, missing authorization and insufficient receiving limits. Read the actual result rather than choosing a remedy from the wallet’s most general error message. If no transaction was submitted, record the local error as such instead of inventing an on-chain failure.

Read clawback as a separate capability and event

The official clawback guide explains that an issuer can burn a specified amount of an enabled issued asset from a trustline. This removes that amount from the holder’s balance. It is different from a restriction that leaves the amount recorded but prevents ordinary movement. The guide also covers claimable balances, which are a distinct ledger object and should not be confused with a normal account balance.

CAP-35 distinguishes the issuing account’s clawback setting from the flag carried by a particular trustline. Its rules apply that capability when the line is created under the relevant setting; it cannot simply be added retroactively to an existing line. Consequently, the issuer’s current page is not enough to establish the state of every older holding.

For a disputed balance change, preserve the relevant transaction and operation history. A line marked clawback-enabled is not an explanation for an unexplained numerical difference until you locate the event. Conversely, the absence of an ordinary outgoing payment does not by itself rule out a different operation affecting the asset. Ask which operation produced the change and keep the amount and asset identifiers attached to that question.

Use a small state record instead of an assumed fix

Consider a fictional holder, Nia. Her wallet shows a trustline and the desired token, but a transfer is rejected. She first records the asset code and issuer, the line’s state, the intended recipient’s requirements and the precise error. If the error concerns authorization, increasing a display limit is not the same as obtaining issuer permission. If it concerns capacity at the recipient, a discussion of clawback may be unrelated.

The point of the example is to keep the investigation tied to one condition. ‘I added the asset’ describes one action, not proof that every later prerequisite is met. Likewise, a successful previous payment is evidence about that earlier transaction, not a promise that current account states and recipient support are unchanged. Preserve a current observation and its time when asking for assistance.

1. Record the network, asset code and complete issuer identifier.
2. Locate the relevant account balance or trustline and distinguish it from a claimable balance or contract-token position.
3. Check current line state and limits separately from general issuer settings.
4. Find the submitted operation’s actual result, or record that the failure happened before submission.
5. If a balance changed, inspect the operation responsible rather than treating a capability flag as the event.
6. Ask the established issuer or service channel about the specific unresolved condition before sending again.

Reserve errors and verification requests need different answers

Trustline creation can also fail for a reserve reason. Stellar documents CHANGE_TRUST_LOW_RESERVE separately from other Change Trust errors. That is not proof of revoked token authorization. Check who must satisfy the reserve requirement in the actual arrangement rather than treating every XLM balance warning as the same event.

If the issuer’s legitimate process requires a review, confirm its scope through the established channel. Do not search for a method to defeat the restriction by routing through another address. A stranger’s promise to ‘clear the flag’ is not an issuer action. Never supply secret keys or recovery phrases to establish ownership for a discussion of public asset identifiers.

For an exchange, asset permission and service acceptance remain separate. Consult KOT.CASH’s supported assets, exchange process and the actual choices in simple swap. These links do not confirm support for every Stellar-issued token. The presence of XLM or a familiar stablecoin code does not establish acceptance of a particular code-and-issuer combination.