Native ALGO is not an ASA you must add to receive it
Algorandโs transaction reference describes a Payment transaction as sending the native Algo currency. Its ASA documentation describes the separate opt-in requirement before an account can receive a particular Algorand Standard Asset. Do not apply that ASA step to native ALGO merely because both holdings appear in the same wallet.
For a USDT-to-ALGO purchase, identify the native receiving account and the selected payout route. If a wallet or page asks you to add an unfamiliar asset first, clarify what asset and action it actually describes. A display name containing ALGO is not enough to establish that a prompt is necessary for the intended purchase.
Give each Algorand identifier its proper role
| Information | Useful purpose | Wrong substitution |
|---|---|---|
| Receiving account address | Identifies the intended account for native ALGO | An ASA identifier pasted into the recipient field |
| ASA identifier | Identifies a specific issued asset when relevant | Treating it as the destination of a native payout |
| Native ALGO receipt | Shows a corresponding payment to the account | Assuming an unrelated asset holding proves the purchase arrived |
| ASA opt-in record | Concerns permission to receive that particular ASA | Using it as evidence that an exchange order has paid out |
Pause an unexplained asset prompt before signing
- Identify where the request came from
- Open the receiving wallet through your established route and inspect the intended account. Do not rely on a message that calls itself an activation step without identifying the asset and operation. The exchange purchase should have a clear receiving instruction rather than a chain of unexplained signatures.
- Read the action proposed for the account
- Ask whether the request concerns a particular ASA, an application action or merely the wallet display. Those are different tasks. This guide does not supply a transaction to sign, and the presence of an opt-in feature in the protocol does not prove that your native ALGO receipt needs it.
- Keep other account requirements separate
- Account balances and service deposit limits still need their own checks. The distinction between ALGO and ASA is not a promise that every receiving account is ready or that a payout has no constraints. Verify the current instruction for the actual account rather than replacing it with a generic โno opt-inโ slogan.
Verify the purchase through the relevant native payment
- Retain the receiving account chosen for the order
Link it with the exchange reference so that a later balance investigation starts from the account you intended to fund. An asset list from another wallet account cannot establish whether this particular payout reached its destination.
- Inspect the actual payout event
Compare the native payment amount and recipient with the exchange result. Do not interpret the absence of a new ASA line as evidence that native ALGO is missing; those display rows describe a different class of asset.
- Describe any unresolved observation
If the event cannot be located or the account record disagrees, provide the relevant references through support. Keep the USDT payment reference distinct from the Algorand payout, and do not repeat a purchase or sign an asset operation simply to change a wallet display.
Questions about ALGO and asset opt-in
- Do I need an ASA opt-in to receive native ALGO?
- The ASA opt-in concerns a particular issued asset. Native Algo uses the payment flow; verify that the intended purchase is native ALGO and keep other account requirements separate.
- Can an ASA identifier replace the receiving account address?
- No. It identifies an asset, not the recipient account for your native payout. Use the account instruction issued for the actual receiver.
- Does no new ASA row mean ALGO failed to arrive?
- Inspect the relevant native payment and account balance. A new ASA entry is a different observation and is not the confirmation of a native-coin purchase.
Algorand asset documentation
Reviewed: