A candidate focused on visible failure
Anza published Agave v4.3.0-rc.1 at 14:39 UTC on September 11. The release page identifies it as a pre-release, which places it in a testing stage rather than presenting it as finished software for every Solana validator. Its immutable tagged changelog documents several operational changes that share a useful principle: when a required dependency or piece of ledger state is invalid, the node should make that condition unmistakable instead of continuing in a reduced mode that may be misunderstood.
That principle matters because a blockchain client performs several jobs at once. It participates in consensus, stores ledger data, serves queries and can stream information to external systems. A process may still appear alive when one of those jobs is unavailable. Operators and monitoring systems can then mistake partial operation for healthy service. Agave 4.3 does not eliminate that broad class of risk, but two of its breaking changes move important failures from logs and compatibility behavior into explicit startup or loading errors.
Bigtable failure becomes a stopping condition
Agave can be configured to use Google Cloud Bigtable for historical ledger access or ledger uploads. The v4.3 changelog says that a node started with either Bigtable ledger-storage flag will now terminate with a fatal error if it cannot establish the connection. Previously, the failure was logged while the process continued without a Bigtable connection. That earlier behavior could preserve availability for other node functions, but it also created a gap between the operator’s declared configuration and the service actually running.
Failing at startup is stricter, but it makes the contract clearer. An RPC operator that intentionally enabled historical storage should not have to infer from later missing records that the dependency never connected. A hard failure can be detected by service supervision, surfaced to an on-call engineer and resolved before traffic is directed to an incomplete endpoint. The tradeoff is immediate downtime for that instance until credentials, networking, service availability or configuration are corrected. The release provides no incident count showing how often this condition occurred, and it does not measure whether the new behavior reduces user-facing errors in production.
Invalid snapshot state is no longer discarded
The second hard boundary concerns validator snapshots. A snapshot packages previously computed state so a node can start without replaying the entire ledger from the beginning. That shortens recovery and deployment work, but it also means the node must trust its loader to interpret the saved state consistently. According to the tagged changelog, loading a snapshot containing an invalid vote account now produces a hard error. Earlier versions could silently drop such an account for compatibility with snapshots created before Agave 2.1.0.
Vote accounts participate in Solana’s representation of validator voting and stake-related consensus information. Silently removing an invalid entry may allow loading to continue, but it also changes the state being reconstructed. Refusing the snapshot makes the discrepancy observable and prevents compatibility logic from quietly deciding that the rest of the state is safe to use. This does not prove that every snapshot accepted by the candidate is correct. It defines one narrower invariant: a known-invalid vote account cannot disappear during loading without stopping the operation. Operators testing the candidate still need reliable replacement snapshots and recovery procedures for the new failure case.
Disk limits become more explicit
Storage management receives a related change. Agave is deprecating the older ledger-size flag in favor of a blockstore-size limit with more precise accounting. Blockstore is the local database holding ledger material needed by the client. A limit that more closely tracks the data being retained can make capacity planning less dependent on a rough proxy, especially when unusual cluster activity changes the mixture or density of stored records.
Precision does not mean a smaller disk requirement. Anza warns that the new control may occupy more storage at steady state under current activity. It says the benefit is more stable disk use during abnormal cluster conditions and suggests that operators moving from a nondefault value may begin by doubling the old number. That is migration guidance, not a universal sizing formula. Hardware, role, traffic and retention requirements differ. The candidate contains no comparative benchmark for disk consumption, so the defensible result is a change in accounting and expected stability, not a measured storage saving.
Optional tracing now requires an explicit budget
Banking trace is also disabled by default in the v4.3 line. To enable it, an operator must supply a maximum byte count. Traces can be valuable when engineers need detailed evidence about transaction processing, but diagnostic data is not free. It consumes memory, storage or processing capacity depending on its implementation and collection path. Requiring an explicit limit turns tracing from an ambient default into an operator choice with a stated resource budget.
Another change reduces status-cache content for validators that neither expose the full RPC interface nor generate snapshots. Those nodes no longer retain transaction-signature keys in that cache, while message hashes remain available for duplicate-transaction detection. The distinction preserves the stated duplicate-checking purpose while avoiding data retained for services the node is not configured to provide. Anza supplies no memory benchmark for this change, so it should not be presented as a quantified efficiency gain. Its value is narrower configuration alignment.
Geyser receives more execution context
Agave’s Geyser interface lets plugins receive account, transaction, entry and block information from a validator. External indexers and analytics services depend on those notifications to construct their own views of network activity. The 4.3 candidate adds bank-scoped replacements for several legacy callbacks. A bank represents a particular working state associated with a slot and lineage, so including its identifier helps a plugin distinguish data produced in different execution contexts rather than treating every notification as belonging to one uncontested sequence.
The candidate also adds an optional block-footer notification carrying a complete versioned Alpenglow footer, slot and bank identifier in entry order. Separate parent-update callbacks tell plugins when earlier entry or data-shred notifications should be discarded after an UpdateParent marker. These interfaces do not guarantee that a plugin will store a correct database. They provide better information for downstream software to recognize which observations belong together and when an earlier interpretation has been superseded. Plugin developers must adopt the new methods, test ordering assumptions and prepare for the announced removal of legacy callbacks in a later major release.
Clearer status without a deployment claim
The changelog includes another example of more precise reporting: external schedulers can distinguish a partially cancelled batch from an all-or-nothing batch failure. Accurate categories matter to automation because remediation depends on what actually completed. Retrying an entire batch after partial execution can have different consequences from retrying one that committed nothing. The new status does not establish that every scheduler integration handles the distinction correctly, but it gives integrations a less ambiguous signal.
Agave v4.3.0-rc.1 is best understood as an inspectable testing milestone. Its hard errors can expose broken dependencies earlier, its storage controls describe resource policy more precisely, and its Geyser additions can help data consumers preserve execution context. None of that establishes stable-release quality, validator adoption, a Solana protocol activation or measured network performance. The immediate progress is more modest and operationally useful: important assumptions are being converted into explicit failures, bounded settings and richer interfaces before the release line is treated as finished.