SIMD-0683 would hand Solana programs their input lengths in registers r3 to r5 at entry
Serguey Asael Shinder2 min readSIMD-0683, "Pass ABIv1 input metadata via registers r3–r5", is a Solana Improvement Document opened on 4 October by febo of Anza and last updated on 11 October. Its status is Review; it is not accepted, has no feature gate and no activation date.
What changes. When a Solana program starts, the virtual machine passes information through registers. Today two of the five available at the ABIv1 entrypoint are used: r1 points to the input region and r2 to the instruction data. Registers r3, r4 and r5 currently hold uninitialised data. The proposal fills them:
r3— the length of the instruction data in bytes, a little-endian 64-bit unsigned integer;r4— a pointer to the start of the accounts slice in the input region;r5— the number of accounts in that slice, counting duplicates, matching the count already written at the start of the input region.
The values would be set for all programs under all loaders, whether or not a program reads them.
Why now. The proposal builds on SIMD-0449, "Direct Account Pointers in Program Input", already accepted, which serialises a slice of account pointers into the program input so that programs no longer parse the accounts section byte by byte. Even with that slice, a program still has to calculate the offset from the instruction data to the accounts slice and load lengths from memory. Putting the three values in registers removes those steps at the very start of execution — the hottest path of every program invocation, where compute units are spent before any program logic runs.
Alternatives the author rejected. Doing nothing leaves every program parsing the input region itself, which the proposal calls unreasonable given how small the change is. Moving the metadata to the start of the serialised input would also work, but breaks the existing serialisation format. The author adds that the planned ABIv2 will redesign the input layout anyway; SIMD-0683 is meant as an immediate gain for ABIv1 that does not conflict with it.
Who is affected. Only the virtual machine changes, according to the proposal's own impact table — not consensus, block packing, gossip or snapshots. Existing programs that ignore the registers are unaffected. Programs written against low-level entrypoint frameworks would need an updated SDK to benefit, and only after the change is accepted and activated on mainnet.
Source: SIMD-0683 — https://github.com/solana-foundation/solana-improvement-documents/pull/683