Agave 4.3 for RPC and gRPC Users: What Breaks, What to Change, and How to Tell Alpenglow Is On

Agave v4.3.0 reached mainnet on September 18, 2026. Anza later recommended v4.3.2 for validators, and Alpenglow activated on mainnet at epoch 1064 on October 21. If your bot, indexer, or wallet backend talks to Solana over HTTP, WebSocket, or Yellowstone gRPC, transaction v1 and bank-aware streaming are the changes to check.

Most release coverage is written for validator operators. This guide is for the people on the other side of the RPC endpoint: the ones whose sendTransaction returns encoding errors, whose getBlock calls fail on v1 transactions, or whose gRPC consumer keeps running while its decoder ignores new fields. Each change includes a symptom, a fix, and a way to confirm it.

01The three breaking changes in 4.3.0#

02Transaction v1: update send and simulation requests#

These changes come from transaction v1 (SIMD-0385), which raises the maximum serialized transaction size from 1,232 to 4,096 bytes. Agave 4.2 made v1 possible; 4.3 widened adoption and made older client assumptions more visible.

Use base64 for serialized transactions sent through sendTransaction or simulateTransaction, and set the encoding explicitly when you construct JSON-RPC requests yourself. Larger routes, proof-heavy transactions, and transactions near the previous 1,232-byte limit are the most likely to expose assumptions in thin wrappers.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sendTransaction",
  "params": [
    "AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...",
    { "encoding": "base64", "skipPreflight": false }
  ]
}

Confirm: search sanitized request logs for base58 encoding on send and simulate calls. SDKs such as @solana/web3.js may already send base64 through their raw transaction methods; verify the wrapper you actually use.

03Versioned transactions: opt in when reading blocks#

Block and transaction methods need to know which transaction versions the client can decode. Set maxSupportedTransactionVersion to 1 on getBlock, getTransaction, and equivalent SDK calls. If you need raw serialized transaction bytes, request base64; if you need parsed JSON, choose the matching JSON encoding.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBlock",
  "params": [
    459653000,
    {
      "encoding": "json",
      "maxSupportedTransactionVersion": 1,
      "transactionDetails": "full",
      "rewards": false
    }
  ]
}

A response error such as -32015 points to transaction-version compatibility. An indexer should treat that as a failed block read, alert on it, and retry after deploying a client that supports the version. Do not let a failed fetch look like a valid block with no transactions.

Confirm: fetch a block known to contain a v1 transaction and compare the returned transaction count with a trusted explorer or independent endpoint. Search post-deploy logs for -32015.

04Yellowstone gRPC: update the client and protos together#

Agave 4.3 adds bank-aware updates to Geyser, which Yellowstone exposes over gRPC. An older generated client can continue to receive messages while lacking the fields or message types your decoder needs. Update the plugin, protobuf definitions, generated bindings, and client library as a compatible set instead of upgrading only one layer.

The original research notes recommend client 13.5.1 and proto 12.7.0 as safer early 4.3 versions. Those have since been superseded by the Yellowstone 14/15 package line. Use current compatible versions supplied by your provider, and regenerate Go protobuf bindings instead of reusing stale generated files.

These are release landmarks, not a universal minimum matrix. Use the version set supported by your endpoint and regenerate language bindings from its matching proto. For the current notes, see the Yellowstone changelog. If you are starting a Python integration, follow our Yellowstone gRPC Python guide.

05If you decode raw transaction bytes#

This section applies if your code parses base64 RPC responses, gRPC transaction data, shreds, or preconfirmation feeds. Consumers of json or jsonParsed generally avoid the wire-layout work, but still need to request support for transaction version 1.

• The v1 message prefix is 0x81. Do not assume every non-legacy transaction begins with the v0 prefix 0x80.
• V1 places its fixed-length signatures after the message. A decoder that assumes signatures always come first will parse the rest incorrectly.
• V1 carries compute and fee configuration in the message header rather than relying on the older Compute Budget instruction pattern. Read the transaction configuration fields when computing requested limits and priority fees.
• Use a maintained transaction parser that explicitly supports v1, then compare decoded account keys, signatures, and fee values with a known RPC response.

The format and size limits are described in SIMD-0385. For full historical indexing and stream catch-up patterns, see our Solana indexer architecture guide.

06Alpenglow: make stream assembly bank-aware#

Agave 4.3 shipped the Votor code and added bank_id to bank-aware Geyser and Yellowstone data. Mainnet activated Alpenglow at epoch 1064 on October 21, 2026. A slot can have multiple candidate banks, so an indexer assembling transactions or accounts into blocks must keep each candidate separate until commitment resolves it.

Keep one buffer per stream connection, keyed by (slot, bank_id) where the field is available. Promote the candidate that reaches confirmed and discard candidates that do not. Treat bank_id as local to the connection: it has no global ordering and cannot identify the same bank across two providers. When reconciling providers, wait for block metadata and compare blockhashes.

At processed, a stream may show more than one bank for a slot and does not guarantee the same event ordering as confirmed data. At confirmed or finalized, use the provider's documented ordering and completion signals. Yellowstone added block-footer updates and replay support in its v16 release series; check whether your endpoint exposes the footer filter before relying on it.

07Finality, vote transactions, and block metrics#

Alpenglow targets roughly 150 ms finality, compared with about 12.8 seconds under TowerBFT. confirmed and finalized now describe the same state on the migrated cluster, though both commitment labels remain available for compatibility. New code can evaluate whether it should use finalized directly instead of waiting around a TowerBFT-era timeout.

Validator votes no longer appear as transactions in blocks. Transaction-count and TPS dashboards therefore dropped at activation without a matching drop in user activity. Rebaseline analytics, alerts, fee-market models, and benchmarks that counted vote transactions. Filtering out the Vote program is now unnecessary for block transaction counts.

If your pipeline counts ticks in shreds as a within-slot clock, that signal has also changed: Alpenglow no longer uses Proof of History ticks to pace block production. Use slot and block metadata or supported footer signals for completeness, and maintain a local timing model if your application needs sub-slot timing. For shred-specific processing, see the Solana Shredstream guide.

08Check the cluster with getAgGenesisCert#

Do not infer activation from a calendar date or a validator version alone. Call getAgGenesisCert on the cluster you use. It takes no parameters and reports the Alpenglow genesis certificate from the finalized bank.

curl https://api.mainnet-beta.solana.com \
  -s -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getAgGenesisCert"}'

import { createSolanaRpc } from '@solana/kit'

const rpc = createSolanaRpc('https://api.mainnet-beta.solana.com')
const cert = await rpc.getAgGenesisCert().send()

if (cert === null) {
  console.log('The cluster is still running TowerBFT')
} else {
  console.log('Alpenglow genesis block:', cert.block.slot)
}

The method is available in @solana/kit from version 8.3.0; for other clients, send a raw JSON-RPC request. The Solana Foundation Alpenglow guide documents the response and activation sequence.

09The RPC and gRPC migration checklist#

• Send serialized transactions as base64; confirm the actual SDK or wrapper request.
• Set maxSupportedTransactionVersion: 1 on block and transaction reads.
• Alert on -32015 and verify failed block reads cannot be mistaken for empty blocks.
• Update Yellowstone clients and protos together, using a combination supported by your endpoint.
• Test a known v1 transaction and compare signatures, account keys, and configuration values against a trusted decoded response.
• Buffer stream events by connection, slot, and bank ID; promote the candidate that reaches commitment.
• For multi-provider fan-in, reconcile sealed candidates on blockhash, not bank ID.
• Use documented block-footer updates where your provider supports them, and test reconnect/replay behavior.
• Rebaseline TPS and transaction-count monitoring after vote transactions leave blocks.
• Replace any tick-based within-slot timing assumptions with a measured local slot clock.
• Call getAgGenesisCert against each endpoint you depend on.
• Revisit long finality waits and review the relevant commitment-level guidance.

10What NoLimitNodes did#

Our RPC, WebSocket, Yellowstone gRPC, and Shredstream endpoints run the Anza-recommended release with a matching Yellowstone plugin. Transaction v1, bank_id, block footers, and getAgGenesisCert are available without changing your endpoint or subscription. Enhanced Streams and Program Streams expose v1 header fields and bank IDs as typed columns, and our parsers were updated for the v1 layout before its activation.

You can call getAgGenesisCert against your own endpoint to confirm what that endpoint returns. For plans and stream details, see RPC, gRPC, and data streams.

11What did not change#

Alpenglow changes consensus, block production, and streaming metadata; it does not change SVM transaction execution. Ordinary HTTP method names and WebSocket subscription names remain familiar, and applications that only read account state or submit ordinary transactions may need no code change. The main migrations are for v1 transaction handling and software that decodes, buffers, or analyzes block data.

For endpoint options, see our Solana RPC, Yellowstone gRPC, and decoded data streams pages. For the foundational stream concepts, read What Yellowstone gRPC is.

12FAQ#

Is Agave 4.3 the Alpenglow release?

Agave 4.3 shipped Votor and the Alpenglow feature gate. Mainnet activation was a separate event: the gate activated at epoch 1064, followed by the consensus handoff after a 5,000-slot migration window.

What Yellowstone version should I use with Agave 4.3?

Use a plugin, client, and proto combination that your provider supports for its Agave release. Yellowstone's v16 series added the bank-aware fields and footer functionality; its release notes list later plugin and proto updates. Verify against your provider rather than pinning an old release-candidate build.

Why did transaction counts fall after Alpenglow?

Validator votes moved out of transaction blocks and into consensus certificates. Rebaseline block-count and TPS analytics; the drop does not by itself mean user transaction activity fell.

How do I know if my RPC provider has migrated?

Call getAgGenesisCert on that endpoint. A certificate indicates the cluster has switched; null means it has not. A -32601 method-not-found error points to a node version that predates the method.

Do jsonParsed users need to change anything?

They can avoid parsing the raw v1 wire layout, but should still advertise transaction-version support for block and transaction reads. Submission wrappers should also be checked for large serialized payloads.

What does bank_id mean?

It identifies a candidate bank within one stream connection. Use it to keep candidate updates separate for a slot, but do not compare bank IDs across providers; reconcile finalized or sealed candidates using blockhash metadata.

13Sources and further reading#

• Solana Foundation: Alpenglow overview and RPC consumer migration guidance
• Anza: Agave v4.3.2 stable release
• Yellowstone gRPC release changelog
• Solana Improvement Document 0385: Transaction V1 Format