Solana Developers Debate sol_math, a Proposed Syscall for Vector and 128-Bit Math

A developer proposal posted on 26 October 2026 would give Solana SOL$99.83-0.7% programs a single syscall for heavy arithmetic: sol_math, which hands a batch of numbers and a short list of operations to the validator and runs them on the CPU's vector hardware. The proposal, filed as discussion #708, "Infinite Arithmetic", claims speedups of up to 47.6x on its authors' own benchmarks. By 27 October, Dean Little, a curator at Blueshift, had replied that the design solves the problem "at the wrong level of abstraction" and sketched an alternative.

The thread is an early-stage discussion in the Solana Improvement Documents repository. It has no SIMD number, no pull request and no feature gate, and nothing in it sets a timeline.

What the sol_math syscall would do for Solana programs

Solana programs run inside a virtual machine (the sBPF VM), which works through arithmetic one value at a time. The #708 post was opened by GitHub user soundsonacid, whose profile lists him as a generalist at Temporal. It says programs lack native 128-bit math and have "no support for any sort of data-level parallelism": applying one instruction to many numbers at once. That technique is also called SIMD (single instruction, multiple data), a name that collides with Solana's own SIMD acronym for improvement proposals.

The proposed sol_math call takes up to three inputs, either single numbers or vectors of numbers, plus a sequence of up to 10 arithmetic or logical operations. The validator evaluates the whole sequence natively and writes the result back to the program's memory. A spreadsheet is a fair comparison: rather than computing each cell by hand, the program writes one formula and has it applied down a column of 4,096 rows.

The authors also list operations they would like to add, including full-width multiplication, a multiply-then-divide that rounds up (the post notes "amms round against the user"), saturating arithmetic, integer square roots and bit counts. Each new operation would need only a new opcode, a price and an execution path inside the syscall, where today each addition would need its own JIT intrinsic or syscall.

The post credits Philip Taffet for "the initial syscall structure" and developer cavemanloverboy for help with the design and the write-up. Taffet's GitHub profile lists Jump Trading, and the repository's review bot names him among the Firedancer team members who can approve proposals. The credit covers his work on the syscall's structure; the Firedancer team itself has not posted a position in the thread.

Benchmarks and compute-unit pricing for sol_math

Cost is set before any work runs. A call pays a fixed base fee plus a charge per eight-lane chunk, in compute units (CUs), the budget unit that Solana transactions request and pay SOL priority fees against. The proof-of-concept charges 4 CU per vector instruction, and it rejects a call whose stated length exceeds the buffers passed before doing any arithmetic, so a validator cannot be made to grind through a huge slice.

On an AMD EPYC 9275F at 4,096 lanes per call, the authors report wall-clock speedups of 11.7x to 47.6x for 64-bit integers and 10.3x to 45.1x for 128-bit integers. Under their proposed pricing, CU consumption falls 6.1x to 20.0x for 64-bit operations and 11.1x to 60.5x for 128-bit operations. cavemanloverboy restated the same figures on X shortly after the post went up.

The two sets of numbers measure different things. The wall-clock speedup is a measurement on one machine. The CU reduction follows from the price the authors chose, and the post argues it could go further because sol_math's CU-per-nanosecond performance "exceeds that of the sbpf jit" for several operations. No one outside the proposal has published a replication. The benchmark code and a proof-of-concept in an Agave fork are public.

Dean Little argues for a vector memory region instead

Dean Little's GitHub profile describes him as a curator at Blueshift, the team behind SIMD-0645, an open proposal for a sol_multi3 syscall that performs 128-bit multiplication. Discussion #708 praises that work but calls high-performance 128-bit multiplication "but a small subset" of the operations sophisticated protocols need. Little wrote that he agrees with the goal, calling native SIMD for programs "an obvious win" and one of several long-term goals his team has for JIT intrinsics.

His objection is to the shape of the API. In his reply, sol_math amounts to "embedding a second arithmetic VM inside the SVM, complete with its own ISA, parser, execution stack, and dispatch mechanism", which he described as solving a compiler and instruction-set compatibility problem "by inventing another interpreter". Little wrote that he would "much rather" extend the existing compiler and JIT infrastructure before committing to an entirely separate arithmetic instruction architecture inside the runtime.

Little's alternative is a dedicated vector memory region that the compiler and JIT would treat as "virtual wide registers", mapped onto the host machine's real vector registers. Values could then stay in fast registers across a chain of operations rather than being copied in and out at each step. He wrote that this would let cryptography libraries "that have spent the past decade or so tuning their algorithms for AVX instructions" run unchanged, making Solana's VM "the fastest place in the world to do general purpose cryptography on a blockchain". He also called the idea "still exploratory work", without enough benchmarking yet to propose a concrete API. Blueshift builds compiler tooling for Solana programs: its sbpf-linker 0.2.3 release on 9 October moved Solana program builds onto upstream Rust and LLVM.

In a follow-up, Little wrote that a syscall puts "an unnecessary boundary" between the compiler and the hardware: batching amortises the overhead, but the compiler still cannot allocate registers or schedule instructions across the call.

cavemanloverboy's case for benchmarking both designs

cavemanloverboy replied that he likes the memory-region idea and finds it "elegant", but cannot see how it would beat a syscall in practice. Unless the instruction set gains a way to load data straight into that region, a program has to copy values in first. His worked example puts copying 64 bytes at 18 CU with individual loads and stores, or 14 CU through sol_memcpy, and the same again to copy results back out. The syscall reads and writes the program's buffers directly. He also disputed that a batched loop inside the syscall would necessarily spill registers.

His proposed tiebreaker: "i think we should literally just impl the two things and see which one is faster according to clock on linux's wall". As of about 07:40 UTC on 27 October, the thread had three participants, two comments and one reply, and no Anza or Firedancer team position.

What sol_math would need before reaching Solana mainnet

The repository's guidelines say ideas "MUST be thoroughly discussed and vetted" before anyone writes a formal SIMD, which is the stage #708 sits at. A formal proposal would then be reviewed by the validator client teams. On SIMD-0645, the repository's bot requires at least one approval from an Anza team member and one from a Firedancer team member. Anza's Alpenglow consensus upgrade went live on mainnet on 21 October. SIMD-0645, the narrower 128-bit multiply proposal, has been open since 17 September.

Two open questions sit under the design argument. The first is whether the CU discount reflects real validator cost, since CU charges are part of the rules every validator must apply identically. The second is hardware: several of the proposed additions name AVX-512 instruction sets, and the thread has not yet discussed how the syscall would run on validator CPUs without them. Both camps want the same thing, cheaper heavy math for protocols that the #708 post says must now choose "between efficiency & sophistication". The thread's own suggested tiebreaker is the one cavemanloverboy proposed: build both and time them.