Agave 4.3 Hits Mainnet: Three Breaking Changes for RPC Providers and dApp Developers

Anza released Agave v4.3.0 on September 18, the stable mainnet build that completed two months of testnet and upgrade-candidate phases beginning with a beta on August 21. Three changes in the release require action from RPC clients, block-data consumers, and Yellowstone gRPC users. Triton One published a migration checklist alongside the release.

Why base58 Encoding Breaks with Transaction V1

Transaction V1, which activated on mainnet at epoch 1035, allows messages up to 4,096 bytes. Base64-encoded, that reaches 5,464 characters. Base58 encoding caps at 1,683 characters, making it structurally unable to carry a full v1 transaction.

Agave 4.3 makes the failure explicit. Prior versions returned a silently incorrect result when a caller sent or requested a v1 transaction with base58 encoding; 4.3 replaces that with an explicit error. Any HTTP RPC client still sending transactions or simulation requests in base58 must switch to base64 before validators complete the upgrade.

What Changes in getBlock and getTransaction Calls

Two parameters are now required when calling getBlock or getTransaction to include v1 transactions in results:

• Set maxSupportedTransactionVersion to 1 or higher
• Set encoding to "base64"

Without both, v1 transactions remain absent from the response. As with transaction submission, the prior silent behavior on base58 requests is now an explicit error in 4.3. Indexers, explorers, and analytics pipelines reading block data need to add maxSupportedTransactionVersion: 1 before validators running 4.3 become the majority. The Agave 4.2 migration checklist covered earlier preparation steps; teams that completed that work need only confirm the version parameter is set.

Yellowstone gRPC Minimum Versions for Agave 4.3

Consumers of the Yellowstone gRPC streaming interface must meet new library minimums:

• yellowstone-grpc-client: minimum 13.2.0, recommended 13.5.1
• yellowstone-grpc-proto: minimum 12.4.0, recommended 12.7.0

Clients below the minimum thresholds will encounter missing fields in streamed transaction data once validators running 4.3 hold a supermajority.

Alpenglow Arrives in 4.3 Without Activating

Alpenglow, the consensus protocol intended to replace TowerBFT, ships code-complete in Agave 4.3 but with its feature gate closed. The Triton One guide places the expected activation "around the 4.4 release." No validator action is required for Alpenglow in 4.3.

The 250ms slot time that went live at epoch 1037 under SIMD-0525 proceeded separately through Agave 4.2 feature activations and is unaffected by the 4.3 rollout.