Yes, a wallet API can support EVM and Solana addresses within the same service by validating each address against its network and routing reads separately. That does not mean one address works on both networks, or that one request returns both balances. BuildAWallet NON-HUMAN is the machine-facing side for AI agents and the developers building them; HUMAN is a separate wallet-blueprint design experience.
- A wallet API supporting EVM and Solana addresses needs explicit network selection and separate address validation.
- BuildAWallet NON-HUMAN describes Base and Solana balance reads; verify deployment and operation-specific availability before integration.
- Multichain support does not establish combined requests, shared ownership, synchronized balances, or signing authority.
- Keep each balance attached to its network, address, asset identity, precision, and freshness evidence.
Can a wallet API support both EVM and Solana addresses at once?
Yes: one API can serve both address families without treating them as interchangeable. For developers building an agent balance tool, the useful capability is network-aware routing, not a universal address parser.
EVM means Ethereum Virtual Machine, the execution environment used by Ethereum and networks such as Base. Solana uses a different account model and address representation. A shared interface can hide some transport differences, but your application still needs to preserve those distinctions.
| Address family | Standard address representation | Best for | Validation limit |
|---|---|---|---|
| EVM | 20 bytes, commonly displayed as 0x followed by 40 hexadecimal characters | Reading accounts on a specifically supported EVM network | Address format alone does not identify the network |
| Solana | A base58-encoded 32-byte public key | Reading accounts on the supported Solana network | Valid encoding does not establish account ownership or account existence |
The BuildAWallet homepage describes Base and Solana balance access alongside deployment and RPC configuration requirements. RPC means remote procedure call: the interface used to communicate with a blockchain node. Those requirements are deployment dependencies, not proof that a particular read is operational.
Why network-aware address handling matters
A balance without network context is incomplete. An EVM address can have different balances on different EVM networks, even when its displayed address stays identical.
Solana introduces a separate validation path. A parser that accepts only hexadecimal EVM addresses cannot validate Solana addresses by removing a prefix or changing letter case.
The practical consequence is simple: make the network part of the request identity, not an inference from the address alone. Keep that identity through validation, caching, logging, and the response consumed by your agent.
This also prevents an integration from confusing a read with permission to act. A public address is enough to request public balance data; it is not enough to authorize a transaction.
What does “at once” mean for your integration?
Multichain support and combined-request support answer different questions. Define the behavior you need before choosing an integration pattern.
| Integration pattern | Best for | Advantage | Limitation |
|---|---|---|---|
| Separate reads | Applications that track each network independently | Clear per-network validation and failure handling | Your application combines the results |
| Application-side aggregation | Agents that need one internal balance report | You control the combined response and partial-failure policy | You own orchestration and freshness checks |
| Provider batch operation | Workflows with a verified batch contract | The provider defines the combined request and response | Availability and error behavior need operation-specific verification |
A service advertising Base and Solana support does not establish that it accepts both addresses in one request. It also does not establish that a batch response represents a synchronized cross-network snapshot.
Prefer separate reads when the combined operation is undocumented or unverified. Application-side aggregation is a design you can implement; it is not evidence of an officially supported framework integration.
Build a read-only validation path
Use the following sequence as an application design, not as a claim about a provider's endpoint names or response fields. Implement it against the operation you have actually verified.
Select network
Require the caller to choose an allowed network explicitly. Reject unsupported selections before sending a paid request.
For EVM reads, keep the specific network rather than storing only the label EVM. Support for Base does not imply support for every EVM chain.
Validate address
Use the validator for the selected address family. For EVM, check the expected hexadecimal representation and apply the checksum rules supported by your chosen library.
For Solana, decode the address with an appropriate library and verify the expected public-key length. Do not require every address to be on the Ed25519 curve: Solana program-derived addresses are deliberately off-curve.
Syntax validation does not prove that an address belongs to your user. Treat ownership verification as a separate requirement when the workflow needs it.
Route read
Send the validated network-and-address pair to the matching read adapter. An adapter is your application component that translates a common internal request into the provider-specific operation.
Keep RPC credentials and other service secrets on the appropriate trusted side of your deployment. The agent's balance tool does not need private keys or recovery phrases.
Normalize result
Return a common application envelope while preserving network-specific meaning. Useful internal fields include network, address, asset identifier, raw balance, decimal precision, observation time, and read status.
These are proposed application fields, not a documented provider schema. Add block or slot information only when the actual response supplies it.
Handle failure
Keep errors attached to the affected network and address. If one read succeeds and the other fails, return an explicit partial result rather than inventing a combined total.
A useful acceptance test starts with independently checked public addresses on each intended network. Compare the returned asset and balance with a separate trusted read, then exercise invalid input and partial failures before connecting the result to an agent decision.
Keep raw balances separate from display amounts
Balance normalization means consistent structure, not identical units. Preserve the integer amount returned by the operation before formatting it for display.
Ethereum's native ETH uses 18 decimal places; Solana's native SOL uses 9. Token precision is asset-specific, so neither native-asset convention is a safe default for every token returned by a wallet API.
Use integer or decimal-safe arithmetic for conversion. JavaScript floating-point numbers do not represent every large integer exactly, so converting a raw blockchain amount into a floating-point value too early can lose precision.
A practical application rule is to store the raw value and its verified precision together. Format the human-readable amount at the display boundary, and do not feed a rounded display string back into spending logic.
Also distinguish native balance reads from token balance coverage. An operation that returns native SOL does not, by that fact alone, enumerate the wallet's SPL tokens; an ETH balance read does not establish ERC-20 coverage.
Why multichain API behavior varies
The address families are only part of the difference. Your implementation also depends on the scope of the specific operation:
- Network coverage: Base support establishes a particular EVM network, not universal EVM access.
- Asset coverage: Native currency reads and token inventory reads require different expectations.
- Deployment configuration: Required deployment and RPC setup must be completed for the intended operation.
- Request structure: Separate operations and verified batch operations have different aggregation responsibilities.
- Freshness evidence: Observation times and chain position must come from the actual response or your own recorded request context.
- Failure semantics: The integration needs an explicit rule for unavailable networks, rejected requests, and incomplete results.
Avoid a blanket “multichain compatible” decision. Write acceptance criteria for the exact read your agent needs, then test that operation in its intended environment.
Preserve asset identity across networks
Never merge balances solely because their ticker symbols match. Asset identity needs network context and, for tokens, the relevant contract or mint address.
This matters when a balance report feeds a payment workflow. A displayed amount does not establish that the receiving application accepts that asset on that network; choosing a supported network is a separate requirement from showing a wallet balance.
Keep an explicit mapping between the intended asset and its network-specific identifier. Reject an ambiguous symbol rather than letting an agent select a network from conversational context.
Do not present a combined portfolio value unless you also have a defined valuation source and timing policy. Adding native units from different networks produces neither a meaningful token balance nor a currency valuation.
Separate discovery, deployment, and signing
BuildAWallet NON-HUMAN is best suited to developers evaluating machine-facing Base and Solana balance reads, subject to deployment and availability checks. Its relevant category here is paid machine data access, not a ready-made autonomous transaction signer.
For service discovery, verify the current NON-HUMAN overview and any referenced llms.txt, agent manifest, and OpenAPI specification. An OpenAPI specification describes an API contract; a discovery document points an application toward advertised capabilities. Neither proves that a paid request succeeds.
The supplied documentation context records broader machine documentation than the homepage, including locally signed transaction preparation and broadcast descriptions. It also records inconsistent subscription information in documents checked on October 8, 2026. Verify operation-specific availability rather than treating the broadest description as the deployment contract.
The homepage describes policy-controlled agent signing as unavailable or in development. Local signing means a separate signer controls the key and authorizes a transaction; it does not mean the data provider holds autonomous signing authority.
The guide to crypto wallets for AI agents addresses this wider boundary. For this integration, keep the exposed tool read-only and leave transaction authorization outside its scope.
Can one EVM address also be a Solana address?
Do not treat an EVM address as a Solana address. The standard representations encode different account identifiers and require different validation.
A multichain interface can associate both addresses with one application profile. That association does not prove shared ownership, shared recovery, or a common signing key.
Does one API response mean both balances are equally current?
No: a combined response does not establish synchronized observations. Preserve each read's available freshness evidence and identify cached results explicitly.
If a downstream action requires a current balance, define and enforce an application freshness policy. Do not invent a provider guarantee from the fact that the results arrived together.
Does reading both balances let an agent spend from both wallets?
No: balance access is not signing authority. Public data reads reveal account state without supplying the private-key authorization needed to approve a transaction.
Spending rules also need enforcement outside conversational instructions. A prompt telling an agent to stay within a limit is not an enforced signing policy.
FAQ
Can the same wallet API accept EVM and Solana addresses?
Yes, a wallet API can accept both address families if its supported operations validate and route them separately. Verify the specific networks and read operations rather than assuming universal chain support.
Does Base support mean every EVM network is supported?
No, Base support establishes support for Base only. Require explicit documentation and an operational check for each additional EVM network.
Can I read Base and Solana balances in one API call?
Only a verified combined operation establishes that capability. Otherwise, make separate reads and combine them in your application with explicit per-network status.
Do I need a private key to check a public wallet balance?
No, checking a public balance does not require the wallet's private key. Keep signing keys and recovery secrets out of agent prompts and request logs.
Should a failed balance request return zero?
No, a failed request should return an explicit failure or unavailable status. Zero is a balance result, not a substitute for missing data.
Does BuildAWallet deploy a working wallet when I choose a blueprint?
No, HUMAN is a wallet-blueprint design experience, not a deployed wallet. NON-HUMAN machine data access is a separate offering with deployment and operation-specific availability requirements.
Next step: test the boundary, not just the happy path
Before giving an agent access, deliberately submit an address under the wrong network, simulate an unavailable read, and return an incomplete combined result. Your application should reject the mismatch and preserve the failures without substituting zero.
Start with a read-only adapter and independently verified balances. Add aggregation only after network identity, asset precision, freshness, and partial failures remain visible from input to output.
