Helius Rust SDK

In version 3.0, get_stake_accounts was updated to filter by the Authorized::staker (offset 12) instead of the Authorized::withdrawer (offset 44).

This change ensures the method returns the correct set of accounts controlled by the staker. If you previously implemented client-side workarounds to filter results, those should now be removed.

The Helius client embeds a standard Solana client.

• For synchronous operations, access it via helius.connection().request_name() where request_name() is a standard Solana RPC method.
• For asynchronous operations (requires new_async() or .with_async_solana()), access it via helius.async_connection()?.some_async_method().await?.

The HeliusFactory allows for centralized configuration and thread-safe creation of multiple Helius clients. This is useful for managing work across multiple clusters simultaneously while ensuring consistent configuration.

Key methods:

• new(): Creates a new HeliusFactory.
• with_client(reqwest::Client): Provides the factory with its own reqwest client.
• create(...): Creates multiple Helius clients in a thread-safe manner.

Version 3.0 introduces several changes to how transaction confirmations are handled:

• Real Deadlines: The timeout parameter in send_and_confirm_transaction and Sender paths is now a strict deadline. Previously, each poll had its own 15-second budget; now, the total time honored is the specified timeout. Ensure your timeout values reflect your actual desired wait time.
• Error Propagation: If a transaction fails to send, the method now returns the underlying send error instead of a generic confirmation timeout error.
• Exponential Backoff: Polling now uses an exponential backoff strategy (starting at 400ms, doubling up to a 5s ceiling) instead of spinning, which reduces network overhead.

The SDK provides several ways to instantiate a Helius client depending on your requirements:

In version 3.0, CreateSmartTransactionConfig and CreateSmartTransactionSeedConfig introduced a new field: loaded_accounts_data_size_limit. This field sets the account-data budget for Transaction v1 messages.

To prevent breaking changes when new fields are added in the future, use the ..Default::default() syntax when constructing these structs instead of enumerating every field manually.

// After 3.0 upgrade
let config = CreateSmartTransactionConfig {
    instructions,
    signers,
    version: TransactionVersion::V1,
    ..Default::default()
};

In version 3.0, transport failures for the Sender and Jito tip-floor feed are no longer classified as HeliusError::InvalidInput. They are now classified as HeliusError::Network.

Instead of matching on error message substrings, use the provided error accessors or specific variants to handle network faults, rate limits, and authorization issues.

// After 3.0 upgrade
match helius.send_smart_transaction_with_sender(config, options).await {
    Err(e) if e.is_connect() || e.is_timeout() => retry(),
    Err(HeliusError::RateLimitExceeded { path }) => back_off(&path),
    Err(HeliusError::Unauthorized { .. }) => refresh_credentials(),
    ...
}

In version 3.0, the auto-derived tip from determine_tip_lamports is now capped at DEFAULT_MAX_TIP_LAMPORTS (0.01 SOL).

If your application requires tipping higher than this limit during periods of high congestion, you must explicitly set a ceiling using one of the following methods:

• SenderSendOptions::with_max_tip_lamports
• determine_tip_lamports_with_cap

Note that setting a ceiling below the tier's minimum tip will result in an error rather than silently paying a lower amount.