Full ASA, NFT, and contract support.

The ASA opt-in flow.

Algorand requires accounts to opt in to any ASA before the asset can be received. This is a deliberate spam-prevention property — your account cannot be force-fed unwanted tokens.

The mechanics: an opt-in is a transaction from your account to itself, transferring zero of the target asset. Submitting this transaction signals to the network that your account accepts the asset. After confirmation, the asset can be sent to your address.

Opt-in safety: Some ASAs have malicious metadata, frozen-by-default behavior, or other characteristics that make them undesirable to hold. Review the asset's properties (creator address, total supply, freeze/clawback addresses, decimals) before opting in. MyAlgo displays these properties in the opt-in confirmation dialog.

Removing opt-in (opt-out): If you no longer want to hold an asset and your balance is zero, you can opt out of the asset to recover the 0.1 ALGO minimum-balance reservation. This is supported in MyAlgo's asset detail view.

NFT standards on Algorand.

Three NFT standards are currently in production use on Algorand. Each has different metadata storage and use-case fit.

ARC-69 — Note-field metadata.

The most common Algorand NFT standard. ARC-69 NFTs store metadata as JSON in the asset's transaction note field. The metadata includes name, description, image URL (typically IPFS), traits, and other attributes. Strengths: Simple, well-supported, small on-chain footprint. Metadata can be updated by re-issuing the asset's note field (if the manager address is set). Limitations: Note field is limited in size. Off-chain image hosting is the norm — if the IPFS pin disappears, the image is gone. MyAlgo displays ARC-69 NFT metadata directly in the asset view, including image preview when the metadata URL is reachable.

ARC-19 — Mutable IPFS metadata.

ARC-19 uses IPFS-based addressing for metadata, with a specific pattern: the asset's URL field references an IPFS CID that can be updated. This allows metadata to evolve over time (project updates, evolving NFTs) while maintaining the same on-chain asset. Strengths: Flexible storage, supports larger metadata payloads, allows post-mint updates. Limitations: Requires IPFS gateway availability for image display. CID rotation requires the asset's manager address to remain controlled. MyAlgo resolves ARC-19 metadata through public IPFS gateways for display.

ARC-200 — Fungible token standard.

Strictly speaking, ARC-200 is a fungible token standard inspired by Ethereum's ERC-20 — used for newer dApps that need fungible token characteristics distinct from the original ASA framework. ARC-200 tokens are typically smart-contract-issued rather than directly created via the ASA framework. Use cases: DeFi protocol tokens, governance tokens, more complex tokenomics than ASAs natively support. MyAlgo behavior: ARC-200 tokens are visible and transferable. Some advanced ARC-200 features (e.g., contract-mediated transfers with custom logic) require interaction with the issuing dApp's interface; MyAlgo signs the resulting transactions.

Atomic transfers — multi-asset operations.

Algorand's atomic transfers allow you to bundle up to 16 transactions into a single group that succeeds or fails as a unit. This matters for trades (send X ALGO + receive Y USDC — the swap fails if either side doesn't execute), multi-asset payments (pay 100 USDC for an NFT and receive the NFT in the same group), and multi-recipient transfers (send 10 ALGO to each of 5 recipients in one atomic group). In MyAlgo, the atomic transfer builder in the Send section lets you add each transaction to the group (up to 16), specify counterparty signers, construct the group locally, have each signer sign their portion, and broadcast the fully-signed group as a single atomic unit.

Common pattern: P2P NFT trade. Alice and Bob want to swap NFT-A for NFT-B without trust. They construct an atomic group with two transactions (Alice → Bob: NFT-A; Bob → Alice: NFT-B), both sign their respective transactions, and the trade executes atomically — neither party can take the other's NFT without giving up their own.

Smart contract calls.

Algorand smart contracts are invoked via Application Calls — transactions that target a specific contract (identified by an Application ID) with arguments and (optionally) ASA transfers. In MyAlgo: the wallet's contract-call interface accepts an Application ID; you specify call arguments (typed: bytes, address, integer, etc.); optionally include ASA transfers as part of the same atomic group; sign and submit. For most users, you won't construct contract calls manually. Instead, you'll connect MyAlgo to a dApp (Folks Finance, Tinyman, Pact, etc.) via WalletConnect — the dApp constructs the contract call, MyAlgo signs it.

Connecting MyAlgo to dApps.

MyAlgo supports WalletConnect v2 and the legacy AlgoSigner-style dApp connection patterns. To connect: on the dApp, choose "Connect Wallet" → "MyAlgo"; the dApp displays a QR code or pairing URI; in MyAlgo, open Connections → Connect to dApp; scan the QR code or paste the URI; approve the connection. The dApp can now request transaction signatures from your account.

Per-transaction approval: Even after connecting, every transaction the dApp requests requires your explicit approval in MyAlgo. You see the full transaction details (asset transfers, smart contract calls, fees) before signing. Disconnecting: Manage active connections from the Connections view. Disconnect any dApp at any time. Common dApps: Folks Finance (lending, liquid staking), Tinyman and Pact (DEXs), HumbleSwap (DEX), Lofty (real estate fractionals), NFD (Algorand naming). See also Algorand staking and About Algorand.