breaks money

Solana x402 verifier rejects payments made with version 1 transactions (maxSupportedTransactionVersion: 0)

packages/facilitator/src/solana/verifier.ts fetches the payer's transaction with maxSupportedTransactionVersion: 0. When the payment was sent as a version 1 transaction, the RPC refuses with error -32015 ("Transaction version (1) is not supported by the requesting client"), the catch turns it into Solana RPC error: ..., and the payment is treated as an outage instead of being verified. The buyer paid, and the request still fails.

Version 1 is common on mainnet now (around 40% of non-vote transactions in a block I sampled), and @solana/kit 8 clients build v1 when configured to.

@solana/web3.js 1.99.0 (the version in your packages) returns it fine with 1, so the fix is the one value. The same maxSupportedTransactionVersion: 0 is also in:

• packages/sdk/src/solana/payments.ts (lines 375, 800, 847)
• packages/sdk/src/solana/events.ts (line 333)
• packages/mcp/src/server.ts (line 891)
• scripts/checks/check-solana-verifier.mjs (line 36)

• packages/facilitator/src/solana/verifier.ts
• packages/sdk/src/solana/payments.ts:375
• packages/sdk/src/solana/payments.ts:800
• packages/sdk/src/solana/payments.ts:847
• packages/sdk/src/solana/events.ts:333
• packages/mcp/src/server.ts:891
• scripts/checks/check-solana-verifier.mjs:36

getTransaction(<v1 signature>, { maxSupportedTransactionVersion: 0 })  -> error -32015
getTransaction(<v1 signature>, { maxSupportedTransactionVersion: 1 })  -> transaction (version 1, meta present)

Fix: Changing each to maxSupportedTransactionVersion: 1 should cover it.

security

MCP tools accept private keys and mnemonics as tool arguments, which puts them in the model's context and client logs

8 of the 58 tools in packages/mcp/src/server.ts take key material as an argument:

• evm_private_key: get_balance, pay, create_invoice, bnb_get_balance, bnb_transfer, bnb_swap, sign_message
• mnemonic: derive_wallet

When a model fills one of these in (for example after a user pastes a key into chat, or a prompt-injected page asks it to), the key or phrase becomes part of the conversation sent to the model provider and is stored in the MCP client's logs and transcripts. Each tool already falls back to AGENTI_EVM_PRIVATE_KEY, so the argument isn't needed for normal use.

• packages/mcp/src/server.ts

Fix: Drop the key arguments and read keys only from the environment (or a local keystore), so a key can never travel through the model. If you'd rather keep them, a warning in each tool description ("never pass a key here; set AGENTI_EVM_PRIVATE_KEY") would at least steer models away from it. generate_wallet returning private keys in its output has the same exposure.