Send Token

intent

Send tokens or native coins from an OpenAnt wallet on Solana or Base networks. Use this when the user requests to transfer, send, pay, or move assets to another address. Covers native coins (SOL, ETH), named tokens (USDC), and arbitrary tokens by mint or contract address. Token transfers are irreversible, so explicit user confirmation on destination address is mandatory before execution.

inputs

OpenAnt CLI Installation and Authentication:

• npx @openant-ai/cli@latest must be available and authenticated
• Run the authenticate-openant skill if auth fails
• Authentication context persists across CLI invocations within the same session

User Inputs (extracted from natural language):

• chain: target blockchain (solana, sol, base, or eth)
• token: token identifier (sol, eth, usdc, or full mint/contract address)
• amount: transfer amount in display units (e.g. 10 = 10 USDC, 0.5 = 0.5 SOL)
• to: destination address (Solana base58 pubkey or EVM 0x address)

Optional Parameters:

• --rpc <url>: override default RPC endpoint (useful for rate limit recovery or custom nodes)

Wallet State (verified via CLI):

• Sufficient token balance for transfer amount
• Sufficient native coin balance for gas/fees (SOL on Solana, ETH on Base)
• Token account exists (for SPL tokens on Solana)

procedure

1. Verify authentication status

   • Input: none
   • Execute: npx @openant-ai/cli@latest status --json
   • Output: JSON with auth status and wallet addresses
   • Decision: if not authenticated, stop and refer user to authenticate-openant skill

2. Check wallet balance and fees

   • Input: chain (inferred from user's request or ask user if ambiguous)
   • Execute: npx @openant-ai/cli@latest wallet balance --json
   • Output: JSON listing all token balances for all provisioned wallets
   • Decision: if balance insufficient for amount plus gas, inform user and stop

3. Extract and normalize user input

   • Input: user's natural language request
   • Output: extracted chain, token, amount, to parameters
   • If chain is ambiguous (e.g. USDC exists on both Solana and Base), ask user explicitly which chain
   • If address is abbreviated, incomplete, or casually typed, ask user to paste the full address again for confirmation

4. Validate destination address format

   • Input: to address and chain
   • Output: validated or rejected address
   • If chain is solana and address does not match base58 pubkey format (32-44 chars, no 0x prefix), stop and clarify
   • If chain is base and address does not start with 0x, stop and clarify
   • Never proceed if address format mismatches chain

5. Display transfer summary and request explicit confirmation

   • Input: chain, token, amount, to address, current balance (from step 2)
   • Output: human-readable summary showing full address, amount, token, chain, and estimated gas cost
   • Display the full destination address and ask user: "please confirm this address is correct"
   • If user does not explicitly confirm, stop

6. Execute token send

   • Input: chain, token, amount, to (all confirmed)
   • Execute: npx @openant-ai/cli@latest wallet send <chain> <token> <amount> <to> --json
   • Output: JSON response with success flag, transaction signature (Solana) or transaction hash (Base), and chain confirmation
   • If execution fails, capture error message and follow error handling guidance

7. Parse and report transaction result

   • Input: CLI response JSON
   • Output: user-facing confirmation with transaction ID and link to block explorer
   • For Solana: provide txSignature and link to Solscan (e.g. https://solscan.io/tx/)
   • For Base: provide txHash and link to Basescan (e.g. https://basescan.org/tx/)

decision points

Authentication missing:

• If status --json returns auth error or missing credentials, stop and refer user to run authenticate-openant skill first. Do not attempt send without valid auth.

Chain ambiguity (USDC case):

• If user says "send USDC" without specifying chain, ask: "which chain, Solana or Base?" Do not guess. USDC contracts differ between chains and sending to wrong chain burns tokens.

Balance insufficient:

• If balance check shows less than (amount + estimated gas), inform user of shortfall and stop. Do not attempt send.
• Solana: reserve ~0.000005 SOL for tx fee minimum. If user is sending entire SOL balance, warn them and ask for explicit approval.
• Base: reserve gas in ETH. Standard transfer costs ~21k gas at current prices. If user is sending entire ETH balance, warn and ask for explicit approval.

Address format mismatch:

• If chain is solana but address starts with 0x, or chain is base but address is base58, stop immediately and ask user to re-verify chain and address.

User does not confirm:

• If user provides address but does not explicitly confirm after seeing summary, do not execute. Ask again: "ready to send?"

Token does not exist:

• If CLI returns "Cannot read decimals for mint" or similar, the token address is invalid or non-existent. Stop, inform user, and ask them to verify the mint/contract address.

Rate limit or network timeout:

• If wallet balance or wallet send times out or returns rate limit error (429, 503), retry once after 2 second delay with optional --rpc <fallback-url> if known. If second attempt fails, inform user to retry in 30 seconds.

output contract

On successful transfer:

• Response JSON structure: { "success": true, "data": { "chain": "solana"|"base", "txSignature": "<sig>" } } (Solana) or { "success": true, "data": { "chain": "base", "txHash": "0x<hash>" } } (Base)
• User message: "transferred to
  on . view transaction: "
• Transaction ID stored in session context for user reference

On failure:

• Response JSON with success: false and error message (e.g. "Insufficient balance", "Unknown chain")
• User message: human-readable error (not raw JSON), with suggested fix if applicable
• No transaction executed, no funds moved

Balance check output:

• JSON listing token balances by chain (e.g. { "solana": { "sol": 2.5, "usdc": 1000 }, "base": { "eth": 0.02, "usdc": 500 } })
• User can inspect before proceeding with send

outcome signal

User knows it worked when:

• CLI returns success JSON with transaction ID
• User sees confirmation message with full address, amount, token, chain, and block explorer link
• User can click link and see transaction on-chain within 30 seconds (Solana) to 2 minutes (Base) with status "confirmed" or "finalized"
• Token balance decreases by sent amount (plus gas fee) on next balance check

User knows it failed when:

• CLI returns success: false with an error code and message
• Error message explains the issue (e.g. "insufficient balance", "invalid address format") and suggests a fix
• No transaction ID is provided
• Balance remains unchanged (token was not sent)