fix(chain): include Solana in chain list

[celesteanglm]

Problem

acp chain list never lists Solana:

$ acp chain list --json
{"environment":"mainnet","chains":[{"id":8453,"name":"Base"},{"id":4663,"name":"Robinhood Chain"}]}

$ IS_TESTNET=true acp chain list --json
{"environment":"testnet","chains":[{"id":84532,...},{"id":97,...},{"id":46630,...}]}

This is not a stale-data issue. It is structural. The command reads only from EVM_MAINNET_CHAINS / EVM_TESTNET_CHAINS:

const chains = isTestnet ? EVM_TESTNET_CHAINS : EVM_MAINNET_CHAINS;

and in acp-node-v2:

export const EVM_MAINNET_CHAINS = [base, robinhood];

Both arrays are EVM-only by definition, so no version bump can surface Solana. SUPPORTED_CHAINS does not help either, since it is also EVM-only. The SDK exposes Solana solely as scalars (SOLANA_MAINNET_CHAIN_ID, SOLANA_DEVNET_CHAIN_ID), plus a program address in ACP_CONTRACT_ADDRESSES and a USDC mint in the payment-token map. Confirmed unchanged in acp-node-v2 0.1.12.

Why it matters

Solana jobs work. Full lifecycle on chain 501, mainnet, CLI 1.0.32:

Event	Detail
job.created	provider 7iJY5Zdy…SSNR
budget.set	0
job.funded	0
job.submitted	deliverable posted
job.completed	settled

client create-job --chain-id 501, client fund --chain-id 501, and job history --chain-id 501 all succeeded against ACP program 2heRZzq7QY8EX2hLceTron7jkzQe8uqsRztQnseavCcx.

So the discovery surface contradicts the supported surface. Anyone using chain list to decide where they can transact concludes Solana is unavailable.

Change

List Solana alongside the EVM chains, keyed off the SDK scalars so the mainnet/testnet split stays consistent with IS_TESTNET.

Also adds a family field ("evm" or "solana") to the JSON and TTY output, since chain ids alone no longer imply an address format and callers need to know whether to expect an EVM or base58 address.

After

$ acp chain list --json
{"environment":"mainnet","chains":[
  {"id":8453,"name":"Base","family":"evm"},
  {"id":4663,"name":"Robinhood Chain","family":"evm"},
  {"id":501,"name":"Solana","family":"solana"}]}

$ IS_TESTNET=true acp chain list --json
{"environment":"testnet","chains":[
  {"id":84532,"name":"Base Sepolia","family":"evm"},
  {"id":97,"name":"BNB Smart Chain Testnet","family":"evm"},
  {"id":46630,"name":"Robinhood Chain Testnet","family":"evm"},
  {"id":500,"name":"Solana Devnet","family":"solana"}]}

Compatibility

• JSON output gains a field. Existing keys are unchanged.
• Non-TTY tab-separated output deliberately keeps its two-column CHAIN_ID/NAME contract, so scripts parsing it are unaffected.
• npm run typecheck and npm run build both pass.

Not addressed here

Two adjacent observations from the same run, left out to keep this focused. Happy to file them separately.

1. events listen appears lossy on Solana. Across the job above, the client listener captured 1 of 5 system events and the provider listener captured 0. Polling job history was reliable throughout. I have not diagnosed the cause and am reporting the symptom only.
2. SOLANA_NO_EVALUATOR_ADDRESS (1111…1111) is the default evaluator when --evaluator is omitted, and job.completed fired in the same second as job.submitted. This looks intentional, but at a non-zero price it releases escrow with no client inspection window, so it may be worth documenting prominently.

---

Note

Low Risk
Discovery-only CLI change with additive JSON; non-TTY tab output unchanged.

Overview
acp chain list now surfaces Solana alongside EVM chains, using SDK SOLANA_*_CHAIN_ID constants and the same IS_TESTNET split as the rest of the CLI (mainnet → Solana 501, testnet → Solana Devnet 500).

Each chain in JSON and TTY output gets a family field ("evm" | "solana") so callers know which address format applies. Tab-separated non-TTY output stays two columns (CHAIN_ID / NAME) for script compatibility.

^{Reviewed by Cursor Bugbot for commit 1d13164. Bugbot is set up for automated code reviews on this repo. Configure here.}