When the same AI agent can pay on Ethereum but says "wallet not found" after switching to Solana, the agent is not broken. It has a separate wallet identity on each chain.
Many developers doing cross-chain arbitrage have run into this problem. The agent works fine on Base, the daily limit still has room, but when switching to Solana the transaction fails with "wallet not found." Many wonder why a wallet created from the same mnemonic cannot be found on Solana.
The answer is simple: you configured a private key (or mnemonic). That key derives different addresses on each chain. EVM chain addresses (ETH, Base, Polygon) are the same, but Solana's address format is completely different, and asset balances are fully independent.
First understand the agent wallet identity model
Mainstream AI agent wallets handle "cross-chain identity" in three main ways. Check which one your tool belongs to before fixing the problem:
Mode 1: Each chain independently generates or derives a new wallet (most common)
Representative tools: Phantom MCP Server, MoonPay Open Wallet Standard (OWS), Veridex Agentic Payments
Phantom's approach: Use the same Google account login, but the MCP Server creates a dedicated wallet for the agent instead of reusing your personal Phantom address. This wallet has separate addresses on Solana, Ethereum, Bitcoin, and Sui.
OWS approach: The underlying design is "one wallet across all chains." After generating a mnemonic, it derives a corresponding address on each supported chain. EVM-chain addresses are the same, but non-EVM chain addresses (Solana, Bitcoin) are completely different.
Veridex's approach: It provides ChainClientFactory, so you can create separate client instances for Base, Solana, Stacks, and Monad. Each instance is bound to a dedicated address on that chain.
Mode 2: One identity per chain, no automatic sync (common for advanced users)
Representative tools: Emblem Agent Wallet, Purple Flea Wallet MCP
These tools support multiple chains, but each chain's address is registered or imported independently. You need to use the --profile parameter in the same configuration file to distinguish them. Balances and addresses on different chains are accounted for separately.
Mode 3: EVM-chain addresses are consistent across chains (but only for EVM)
Representative tools: Most solutions based on EOA or smart contract wallets
If your agent runs on an EOA (external account), addresses on Ethereum, Base, Arbitrum, and Polygon are naturally the same. Assets are stored separately, but the account identity is consistent. Solana is not covered.
Symptom check: Which type of "wallet mismatch" do you have?
Case A: Wallet not found between EVM chains
Signs: You have 100 U on Ethereum, but when switching to Base, payment shows the balance as 0.
Cause: Although the address is the same, assets are isolated across chains. Your USDC on Ethereum will not automatically appear on Base. Even with the same address, each chain has its own ledger.
Solution: Use a bridge tool to move assets from the source chain to the target chain. Or directly fund the agent's address on the target chain.
Completion standard: Check the target chain's block explorer and confirm that the address has the corresponding asset balance.
Case B: Wallet not found between EVM and non-EVM chains
Signs: The Ethereum address is 0xabc..., and the Solana address is HSm5... They are completely different.
Cause: EVM addresses and Solana addresses use different generation algorithms and formats. The same mnemonic derives completely different addresses on these two chains.
Solution: Use the get_wallet_addresses or deposit_address function provided by your agent tool to check the agent's address list on all chains, then fund each chain's address separately.
Completion standard: After finding the Solana address, send SOL or USDC directly to that address. The agent's payment on Solana can then execute normally.
Important warning: Do not assume "I sent 100 U to the agent's Ethereum address, so it can spend it on Solana." Cross-chain assets do not share balances. You must fund each chain separately. If you use a cross-chain bridge to move assets from chain A to chain B, confirm that the destination address is the agent's address on chain B. Do not enter the wrong one.
Case C: Different chain "identity" permissions in the same tool are inconsistent
Signs: A single-transaction limit set on Base does not apply on Solana.
Cause: When the Veridex SDK creates a Session Key, it can restrict the allowedChains list. If you only allowed Base and Ethereum when creating the session, the agent's signature will fail on Solana because that session key is not authorized there.
Solution:
- Check the session's allowedChains configuration and add Solana
- Or create a separate session for the new chain and use ChainClientFactory to generate a dedicated client
Completion standard: When the agent initiates a payment on Solana, session validation passes and no longer reports "invalid chain" or a similar error.
Verification wrap-up
Run a complete test flow:
- Have the agent call get_wallet_addresses or deposit_address and print the address list for all chains
- Confirm that addresses on the chains you want the agent to use are generated and have balances
- Execute a tiny test payment on each chain (for example, 0.01 U) to confirm it works
Verification channel: The test transaction on each chain can be found on the corresponding block explorer. The receiving address should be the agent's address on that chain. If a test fails on any chain, check whether that chain has been independently funded and authorized.
