INVALID_ARGUMENT — bad subscribe filter

Root causes

Ranked by frequency. First cause is the one to check first.

1. 01Account addresses passed as raw bytes instead of base58 strings (or vice versa — check the proto definition).
2. 02Commitment spelled as `CONFIRMED` when the proto enum expects lowercase `confirmed`.
3. 03Empty `accounts` map and empty `transactions` map — an empty SubscribeRequest is rejected as invalid.
4. 04Owner filter with more than the per-provider cap (Subglow: 25, Triton: 50, Chainstack: 100).
5. 05Mismatched proto versions between client and server — provider bumped the SubscribeRequest schema and your client is on an old proto.

Fix steps

1. 1

   Regenerate client from the latest proto

   `git pull` the yellowstone-grpc-proto repo and regenerate your language bindings. Old clients that don't know about newer optional fields can pass invalid defaults.

2. 2

   Pass base58, not raw bytes

   In Solana tooling the convention is base58 strings for on-chain addresses. The Geyser proto accepts string fields, not bytes — your library wrapper is doing the base58 decode internally.

3. 3

   Validate the filter locally

   Print the generated SubscribeRequest as JSON before sending. Any `undefined` or empty-string field where the proto expects a valid address will yield INVALID_ARGUMENT.

Code example

const subscribeRequest = {
  accounts: {},
  slots: {},
  transactions: {
    pumpfun: {
      vote: false,
      failed: false,
      signature: undefined,
      accountInclude: [],
      accountExclude: [],
      accountRequired: ["6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P"],
    },
  },
  transactionsStatus: {},
  blocks: {},
  blocksMeta: {},
  entry: {},
  accountsDataSlice: [],
  commitment: CommitmentLevel.PROCESSED, // not "PROCESSED" as a string
};

Related errors

• DEADLINE_EXCEEDED on Yellowstone subscribe
  `Status { code: DeadlineExceeded }` means the RPC didn't produce a response within the deadline you (or the default) set. On a streaming subscribe this usually means the initial handshake took too long, or the client's deadline was accidentally set on the whole stream instead of the initial call.
• RESOURCE_EXHAUSTED — rate limit on gRPC
  `Status { code: ResourceExhausted }` means the server refused to serve your call because you hit a limit — concurrent streams, messages-per-second, or filter complexity. Unlike HTTP 429, this is a hard rejection: the stream is closed and must be reconnected, not retried on the same channel.
• Yellowstone proto version mismatch
  Your client throws parsing errors on SubscribeUpdate messages even though the stream opened successfully. The provider server returns a proto your client doesn't understand — a new optional field, or a message type added after your client was generated.