Skip to main content
Technical proposal SIMD-0512 Idea

Sha512 Syscall

  1. Idea
  2. Draft
  3. Review
  4. Accept
  5. Implement
  6. Active

Decision brief

Why this proposal matters

Introduce a sol_sha512 syscall with an identical interface to sol_sha256, producing SHA-512 hashes and outputting the 64-byte result.

Source-backed reading aid · source language: EN

Proposal at a glance

What changes

  • Not all bytes in [bytes, bytes + bytes_len sizeof(SolBytes)) are readable.
  • Not all bytes in each slice [bytes[i].addr, bytes[i].addr + bytes[i].len) are readable.
  • Not all bytes in [result, result + 64) are writable.

Stakeholder map

Who is affected

Builders & client teams Medium impact

Programs gain access to SHA-512 hashing at syscall cost.

Action requirement unknown
Validators & operators Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Users & stakers Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Governance & ecosystem Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown

Exact source revision

Full proposal document

Source-language document. Technical identifiers and evidence remain unchanged. 0616093b2952

Summary

Introduce a sol_sha512 syscall with an identical interface to sol_sha256, producing SHA-512 hashes and outputting the 64-byte result.

Motivation

SHA-512 is a core primitive of Ed25519 signature verification and is already present in both the Agave and Firedancer validator clients as an internal dependency. However, it is not currently exposed to on-chain programs as a syscall.

Exposing sol_sha512 directly enables programs to perform SHA-512 hashing without resorting to an on-chain software implementation, which is both expensive in compute units and unnecessary given the function already exists in every validator.

New Terminology

N/A

Detailed Design

Syscall Signature

The syscall follows the same interface as sol_sha256, sol_keccak256, and sol_blake3. See here for more details:

https://docs.rs/solana-sha256-hasher/3.1.0/src/solana_sha256_hasher/lib.rs.html#62-75

The syscall computes SHA-512 over the provided byte slices as if they were a single contiguous input, writing the 64-byte digest to result.

The syscall aborts the virtual machine if any of these conditions are true:

Compute Unit Usage

Compute costs follow the same model and parameters as sol_sha256.

See here for more details: https://github.com/anza-xyz/agave/blob/master/syscalls/src/lib.rs#L168-L169

Alternatives Considered

BPF Implementation

Programs can implement SHA-512 in BPF today, but at a higher CU cost. A single SHA-512 hash of a short message consumes thousands of CUs in software versus fewer than 100 via syscall.

Status Quo

Continue without exposing SHA-512. Programs requiring SHA-512 (e.g., for Ed25519-adjacent verification logic) remain unable to access a primitive that both validators already have linked.

Impact

Programs gain access to SHA-512 hashing at syscall cost.

Security Considerations

The security surface is identical to the existing hash syscalls. The same input validation and CU metering apply. SHA-512 itself is a well-studied, standardized hash function (FIPS 180-4).

Backwards Compatibility

This is an additive change gated behind a feature flag. Programs that do not invoke sol_sha512 are unaffected. Existing syscalls are unchanged.

Evidence graph

Related proposals and rollout

One or more sources are unavailable.

Upstream review record

Upstream discussion & review

GitHub review is editorial context, not evidence of on-chain support, voting, or outcome.

PR #512 · merged SIMD-0512: Sha512 Syscall 21 comments and reviews · Apr 11, 2026
@simd-botbot

✅ All approvals received! @deanmlittle, you can now merge this by commenting /merge. ✅ Status: Ready to merge

GitHub ↗
@simd-botbot

✅ Merge successful! deanmlittle(https://github.com/deanmlittle)'s PR has been merged.

GitHub ↗
@ripatel-fd

Would have priced this higher than SHA256 since it's more expensive on x86

GitHub ↗
@deanmlittle

Would have priced this higher than SHA256 since it's more expensive on x86 If we're making this argument, it actually makes more sense to make SHA256 cheaper than the others rather than making SHA512 more expensive, as Sha256 is uniquely faster due to SHA extensions. Keccak and Blake are priced the same as SHA256 despite lacking intrinsic support, and SHA512 is faster than non-intrinsic SHA256 despite producing a larger hash.

GitHub ↗
@ripatel-fd

If we're making this argument, it actually makes more sense to make SHA256 cheaper than the others rather than making SHA512 more expensive, as Sha256 is uniquely faster due to SHA extensions. Keccak and Blake are priced the same as SHA256 despite lacking intrinsic support, and SHA512 is faster than non-intrinsic SHA256 despite producing a larger hash. Very good point, will look into this

GitHub ↗

simd.watch community discussion · SIMD-0512

Powered by Giscus · Sign in with GitHub to comment

Community comments load when this section approaches the viewport.

Provenance

Evidence & technical details

Rollout or chain data, source revisions, freshness and integrity.
1

SIMD

Deployment Status

Document lifecycleIdea
CategoryCore protocol

Feature Gate not yet created

Exact source revision

Sources & integrity

  • Proposal document pinned_commit_blob
    0616093b2952ed6de52c4a27d66aadd11d48d4f9
  • simd-document document · current · Sep 11, 2026
    0616093b2952ed6de52c4a27d66aadd11d48d4f9

One or more sources are unavailable.