TypeSOL cuts stake deposit compute by 75% in Solana stress test
A test with 20,000 validators compared TypeSOL’s stake pool port with the program running on Solana mainnet. The result shows where developers could gain room in a transaction.
TypeSOL reported on Nov. 10 that its TypeScript port of Solana’s SPL Stake Pool program used about 75% fewer compute units for a stake deposit in a test with 20,000 validators. The team ran the same test against the executable currently deployed on Solana mainnet. Both versions produced the same result, but the port used 153,300 compute units for the deposit, down from 611,313.
SPL Stake Pool's own test suite includes a pool of 20,000 validators.
— TypeSOL (@Type_SOL) November 10, 2026
The SPL Stake Pool program lets operators spread stake across validators and issue pool tokens representing a share of the stake. In the same large-pool test, withdrawing stake fell from 783,846 compute units to 310,716, while updating the pool balance fell from 547,385 to 321,997. The test used a simulated pool and a 1.4 million compute unit budget. It did not measure transactions sent to mainnet.
What the test means for developers
TypeSOL’s case study describes loading both executables into separate instances of the LiteSVM testing environment under the same program address and with the same clock and stake history. The team compared transaction outcomes, logs and account data. Its tests caught a withdrawal that exceeded the default compute budget at 3,550 validators after the port changed how it searched the validator list. The team restored the original search behavior and added a regression test.
Lower compute use leaves more room for other instructions in the same transaction. It can also let an app request a smaller compute budget if simulations show that the lower limit is safe. Under Solana’s fee rules, the priority fee depends on the limit the transaction requests, so using fewer units does not cut the fee if that limit stays the same. The benchmark gives developers a result they can test against their own transaction flows; it does not show a change in fees for users of the deployed program.