TL;DR

  • Agave 4.3 is coming to mainnet, and three client-side changes take effect with it
  • If you send or simulate transactions over HTTP/RPC, switch from base58 to base64 encoding; base58 is deprecated and can't carry full-size v1 transactions
  • If you call getBlock or getTransaction, set maxSupportedTransactionVersion to 1 or higher and request base64, or v1 transactions won't be returned to you
  • If you use Yellowstone gRPC, upgrade your client to at least 13.2.0 and your protos to at least 12.4.0, or you won't see the full fields of v1 transactions in your messages
  • Alpenglow does not activate with 4.3; the feature gate is expected around the 4.4 release

→ View the docs

Following our guide to the Agave 4.2 breaking changes, the network is already moving to the next release. Agave 4.3 is rolling out across mainnet.

None of this is Alpenglow. The consensus change everyone is watching ships inert in 4.3, with the feature gate expected around 4.4. 

The changes below are now live, so here's what to update.

Sending transactions: switch to base64

If you send or simulate transactions over HTTP/RPC, you now need to encode them in base64 rather than base58.

The reason is size. Transaction v1 supports transactions of up to 4096 bytes, 5464 characters when encoded to a base64 string, but the capacity for decoding base58 transactions is fixed at 1683 characters and won't be increased. Base58 is significantly slower than Base64 as the input grows, so Base58 encoding is deprecated for sending and simulating v1 transactions that grow above 1683 in characters, 1232 in bytes size.

Most Solana SDKs make this a one-line change: set the encoding to base64 wherever you build your sendTransaction and simulateTransaction calls. If you're constructing requests by hand, base64-encode the serialised transaction and pass "encoding": "base64" in the request parameters.

Fetching transactions and blocks: opt in to v1

If you call getBlock or getTransaction, you need two things for v1 transactions to be returned to you:

  • Set maxSupportedTransactionVersion to 1 or higher in your request parameters
  • Request base64 encoding here as well

Without the version parameter, v1 transactions won't come back in your results. Requesting base58 together with maxSupportedTransactionVersion >= 1 already returned incorrect answers before 4.3, because a v1 transaction can't be represented in the base58 response shape. Agave 4.3 replaces that silently wrong answer with an explicit error indicating that base58 isn't supported in v1. 

If you start seeing that error, the fix is the same as above: request base64.

Yellowstone gRPC: upgrade your client

If you consume our Dragon's Mouth gRPC streams through yellowstone-grpc, your existing subscriptions keep working through the upgrade. You don't need to change your filters or your subscription setup, and your feed won't stop.

What you will miss without an upgrade is data. 

Older client versions don't know about the new fields introduced in Transaction v1, so those fields won't appear in your messages. This affects block, transaction, and deshred subscriptions.

The version requirements:

Library

Minimum

Recommended

yellowstone-grpc-client

13.2.0

13.5.1

yellowstone-grpc-proto

12.4.0

12.7.0

💡
We strongly encourage upgrading to the recommended versions now rather than waiting until you notice missing fields in production. v1 transactions are already flowing on mainnet, so the gap is real from day one.

No action, just an FYI: getInflationReward

Agave 4.3 caps getInflationReward at 32 addresses per call; requests with more now fail with a -32602 error rather than being served.

This doesn't affect you as a Triton customer. Superbank doesn't serve getInflationReward from Agave, and the Superbank cap is 100 addresses per call, unchanged. We're noting it here only because you may see it discussed elsewhere in the ecosystem, or hit it on non-Triton endpoints.

What about Alpenglow?

Not yet. Alpenglow does not activate with 4.3.0. The feature gate is expected to activate around the 4.4 release, and we'll cover what that means for you well in advance.

The important distinction: everything above takes effect with 4.3, now, as the network upgrades. Don't file these changes under "later" because they arrived in the same release cycle as the Alpenglow code.

Your checklist

  • Switch transaction sending and simulation to base64 encoding
  • Add maxSupportedTransactionVersion: 1 (or higher) and base64 encoding to your getBlock and getTransaction calls
  • Upgrade yellowstone-grpc-client to 13.5.1 and yellowstone-grpc-proto to 12.7.0

If you run into anything unexpected after updating, we're here to help.

→ View the docs