SIMD-0670 proposes a leaner CPI syscall, cutting setup cost by up to 55%
Serguey Asael Shinder2 min readA new Solana Improvement Document, SIMD-0670, proposes a second version of the syscall that programs use to call other programs. It was opened on 25 September by febo of Anza, the developer behind the Pinocchio program library, and is in review. According to the pull request, it follows a discussion in which consensus was reached to identify accounts by their index in the instruction.
The problem is how much work a cross-program invocation (CPI) makes a program do before the call happens. Today, programs using the current ABI pass two slices of account data - AccountMeta and AccountInfo - and must convert account information they received as input into another layout, which the runtime then converts again. The proposal puts that at 90 bytes per account per CPI: 34 for the meta and 56 for the info. With up to 255 accounts allowed in a CPI and a stack limit of 4,096 bytes, programs often have to allocate on the heap.
The new sol_invoke_signed_v2 takes a CpiInstruction with one slice of CpiAccount entries, each just an account index plus writable and signer flags: 4 bytes instead of 90. The runtime already has the account information and looks it up by index. The proposal states that the runtime's CPI logic is otherwise unchanged and that only the virtual machine gains a new syscall. Its benchmark, from a Pinocchio program calling a minimal target, shows setup cost falling from 1,376 to 1,174 compute units with eight accounts, a 15% saving, and from 2,813 to 1,267 with 64 accounts, 55%. Because indices can be fixed at compile time when a program's account list is known, the account list can be built statically.
What it means
Compute units are what Solana programs pay for, and CPIs are everywhere: tokens, swaps and lending protocols all call other programs. A saving that grows with the number of accounts matters most for the complex transactions that already push against limits.
It is a proposal in review, not a scheduled change. It would need acceptance, a feature gate and activation, and program frameworks would need to adopt the new call. The old syscall stays, so nothing breaks for programs that do not switch.