Triton One Announces Account Sync, an SDK That Serves Solana Account Reads From a Local Cache

Triton One announced Account Sync on 5 October 2026, a software development kit (SDK) that answers a Solana SOL$119.92-1.7% application's account reads from a copy held in the app's own memory instead of sending each one to an RPC node. The RPC provider says the change takes the per-request charge out of repeated polling and leaves customers paying for bandwidth, which it prices at $0.08 per gigabyte.

The announcement came in a post from Triton One's official X account and an accompanying Triton blog post. The code was public before the announcement: npm's registry entry for the JavaScript package lists version 0.1.0 with a publish date of 16 September 2026.

How Account Sync replaces getAccountInfo polling with a streamed cache

Account Sync keeps a local copy of the accounts an app cares about and updates that copy from a live stream, so a repeat read never leaves the machine. On Solana, an account is where data such as a wallet's token balance or a trading pool's reserves is stored, and an RPC node is the server an app asks for that data.

Polling means asking the node for the same account again and again to see whether anything changed. Triton's blog post describes the cost of that pattern: "you're billed for both the request and the bandwidth on every call, because the RPC node has to look up the account, serialise the entire payload, and send the complete JSON back, even if nothing has changed."

According to the blog post, the Triton SDK fetches an account once over JSON-RPC on the first read, subscribes to its updates over gRPC or WebSocket, and applies those updates to a local store. Later reads are served from the app's memory. The closest everyday comparison is following the edits on a shared document instead of downloading the whole file every few seconds to check for changes.

The cache covers getAccountInfo, getMultipleAccountsInfo and their parsed and context variants, the blog post says, while every other JSON-RPC method goes to an RPC node as before. Triton ships the SDK as the @triton-one/triton-sdk package for JavaScript, which stands in for @solana/web3.js, and as the triton-sdk crate for Rust, which stands in for solana-client. The company describes the migration as "swap one import, add one accountSync config block, and you're done."

Bandwidth-only RPC pricing: $0.08/GB with no per-request charge

Triton's blog post lists standard RPC polling at "$10/M + $0.08/GB", a per-request charge plus a bandwidth charge, and Account Sync at "$0.08/GB" alone. The same table prices direct gRPC streaming at $0.08/GB. Triton says Account Sync "lets you pay for just one RPC request plus the bandwidth cost of updates, and never for data that hasn't changed."

On that model, an Account Sync bill follows how often the watched accounts change, while a polling bill follows how often the app asks.

getMultipleAccountsInfo latency benchmark and the SDK's stated limits

Triton's Account Sync documentation reports a JavaScript getMultipleAccountsInfo benchmark in which median latency fell from 12.01 ms on standard RPC to 1.65 ms with Account Sync, an 86.3% reduction, and 90th-percentile latency fell from 14.94 ms to 1.98 ms, an 86.8% reduction.

The latency figures are Triton's own. Triton's documentation page does not describe the test setup, and Solana Compass found no independent benchmark or third-party coverage of Account Sync on 5 October 2026.

Triton names the cases where Account Sync is the wrong tool. Its documentation says standard RPC calls "may be more appropriate" for an application that reads account data infrequently, and the blog post says "latency-critical trading (HFT, MEV, liquidation engines)" should use direct gRPC streaming, which it calls "still the fastest path." The documentation's support table shows that browser apps can use only the WebSocket transport, and that the Rust crate supports only gRPC, on the Tokio runtime.

Where the SDK sits alongside Cloudbreak and SuperBank

Account Sync is documented under Triton's Project Yellowstone section, and it puts a data stream behind the read calls most Solana apps already make. Solana Compass covered two earlier Triton One products aimed at reading Solana data in June 2026: Cloudbreak, a Postgres-indexed store for getProgramAccounts queries, and SuperBank, a ClickHouse-based layer for historical ledger data.

Triton's blog post aims Account Sync at wallets, DEXs, explorers and portfolio dashboards that poll continuously. For those teams the saving depends on their own workloads, and the blog post names no customers already using it.