SIMD-0558 spells out the order in which its syscall refuses a pointer

Serguey Asael Shinder23 September 2026, 18:002 min read

A commit to the Solana improvement documents repository on 23 September 2026 updated SIMD-0558, the leader-info syscall proposal, to describe pointer validation and revise the compute-unit cost. The change adds 52 lines and removes 13 in proposals/0558-leader-info-syscall.md.

The mechanics are now written out explicitly. result is a virtual address; on success the syscall writes 128 bytes of LeaderInfo to [result, result + 128). Compute units are consumed first — if that exceeds the budget, the virtual machine aborts and no bytes are written.

Otherwise the syscall aborts the VM, without returning to the caller and without writing LeaderInfo, when either of these holds, checked in this order:

1. The program was loaded by a loader that does not enforce aligned accesses — SyscallError::UnalignedPointer, the same guard the sysvar getter syscalls use. LeaderInfo is a #[repr(C)] struct of four pubkeys, so its alignment is 1; where the loader does enforce alignment, an address is not rejected for being unaligned.
2. result >= 0x4_0000_0000 (MM_INPUT_START, the input region) — SyscallError::InvalidPointer, rejecting an input-region destination directly, the same way a sysvar getter does.

The part worth noticing

"Checked in this order" is the sentence that makes this a specification rather than a description. When two failure conditions can both be true, which error a program receives is observable behaviour — and anything observable is something implementations must agree on, or the same transaction produces different errors on different validators. Pinning the order is how you stop that becoming a consensus question later.

Charging compute units before validating is the other deliberate choice. It means a program that passes a bad pointer still pays, which removes any incentive to probe the syscall cheaply for information about the address space. Fee-first is the standard defence against using error codes as an oracle.

The alignment note is a small piece of honesty worth copying: because LeaderInfo is four pubkeys with alignment 1, the unaligned-pointer guard is not protecting the struct — it is inherited from how the sysvar getters behave, and the proposal says so rather than inventing a justification.

📌 This is a proposal under revision, not an activated feature. The relevant question for anyone tracking it is the compute-unit figure, which this commit changed and which is what determines whether the syscall is usable in practice.