Skip to main content
Associated Token Accounts are the #1 hallucination LLMs make on Solana. The derivation combines the owner, mint, and SPL Token program with a PDA hash. Agents constantly guess. This endpoint returns the correct ATA every time, plus an exists flag so you know whether it needs to be created before you can send tokens to it.
Paid endpoint. Pass your key in the x-api-key header. See Get an API key.

Why agents use this

  • LLM guesses are wrong most of the time. The ATA derivation isn’t obvious, and models trained on general web data confidently produce garbage addresses.
  • exists: false saves you a failed transaction. Sending SPL tokens to a non-existent ATA fails with a cryptic error. Check first, create the ATA if needed, then send.
  • Batch-friendly. Cheap enough to call across hundreds of wallets when running eligibility checks.

Use cases

  • Airdrop pre-flight for 500 wallets. Loop through your list, call find-ata for each (wallet, mint) pair, and only air-drop to wallets whose ATA already exists (or fund a create instruction where it doesn’t).
  • Pre-trade ATA verification. Before your agent builds a Jupiter swap, confirm the destination ATA exists so the swap doesn’t fail on the first hop.
  • Wallet UI “receive” address. Show the exact ATA a user should share to receive a specific SPL token, without asking them to trust the LLM’s answer.
  • MCP tool for Claude Desktop. Users type “what’s my USDC address?” and Claude calls this instead of hallucinating.
  • Multi-token dashboard. Given one wallet and a list of tracked mints, resolve every ATA in parallel for a live balance grid.

Recipe: safe airdrop eligibility check

airdrop-check.ts
Pair with Token Profile to reject the mint entirely if it looks like a honeypot before you compute a single ATA.