Skip to main content
Technical proposal SIMD-0049 Withdrawn

Syscall for remaining compute units

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

Decision brief

Why this proposal matters

Add a new syscall to access the number of compute units that are left to use in a transaction.

Source-backed reading aid · source language: EN

Proposal at a glance

What changes

  • The syscall must cost no more than the syscall base cost of 100 CU.
  • Add a new syscall to access the number of compute units that are left to use in a transaction.

Stakeholder map

Who is affected

Builders & client teams Medium impact

Dapp developers get new capabilities

Action requirement unknown
Validators & operators Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Users & stakers Medium impact

Add a new syscall to access the number of compute units that are left to use in a transaction.

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

Add a new syscall to access the number of compute units that are left to use in a transaction.

Motivation

Some instructions can use a variable amount of compute. Examples include:

  • Event processing instructions that can process as many events as are available.
  • Orderbook matching instructions, which want to match a large taker order as deeply into the orderbook as is necessary to fully fill it.
  • Routing instructions, that may want to pick routes depending on remaining compute.

Currently these types of instructions often require the user to pass in a limit (like the maximum number of events to process, for the first example). That means the user needs to request the right compute budget for the transaction and guess the best possible limits for their instructions.

This often leads to users over-provisioning compute budget for a transaction. If the instruction could access the remaining budget, it could decide on its own whether another round of processing would fit or not, leading to better utilization of requested compute.

Example:

fn process_events() {
  while (true) {
    let event = peek_event();
    match event.type {
      CheapEvent => {
        if sol_remaining_compute_units() < 10_000 {
          break;
        }
        process_cheap(event);
      },
      ExpensiveEvent => {
        if sol_remaining_compute_units() < 40_000 {
          break;
        }
        process_expensive(event);
      }
    }
    pop_event();
  }
}

The example is inspired by an actual potential usecase in the Mango program. It shows how it would be preferable to "process events for all the 150k CU that remain" (so up to 15 cheap ones) instead of the current "process at most three events" (because 4 expensive ones would not fit).

Alternatives Considered

Instead of knowing the transaction-wide remaining budget, instructions could be allowed to access the amount of compute they have already used.

Then instructions could be written in a way where users can pass in compute targets and the instruction aims to stay below the target.

New Terminology

None

Detailed Design

Add a syscall sol_remaining_compute_units() -> u64 that returns the remaining compute budget for the current transaction.

The syscall must cost no more than the syscall base cost of 100 CU.

The PR is at https://github.com/solana-labs/solana/pull/31640.

Impact

  • New syscall, needs a feature flag
  • Dapp developers get new capabilities

Security Considerations

Programs having access to the remaining compute budget would allow them to:

  • Check if they are the first instruction, but they can already do that via introspection.
  • Guess the effect of a CPI call by observing how much compute it used. But since program and data bytes are public, that shouldn't create new capabilities.

Backwards Compatibility

Not applicable.

Evidence graph

Related proposals and rollout

One or more sources are unavailable.

Upstream review record

Upstream discussion & review

One or more sources are unavailable.

simd.watch community discussion · SIMD-0049

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.
3

SIMD

Deployment Status

Document lifecycleWithdrawn
CategoryCore protocol
Devnetinactive
Testnetinactive
Mainnet-Betainactive
5TuppMutoyzhUSfuYdhgzD47F92GL1g89KpCZQKqedxP

Exact source revision

Sources & integrity

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

One or more sources are unavailable.

One or more sources are unavailable.