Skip to main content
Technical proposal SIMD-0183 Activated

Skip Rent Rewrites

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

Decision brief

Why this proposal matters

Do not rewrite accounts that are unchanged by rent collection.

Source-backed reading aid · source language: EN

Proposal at a glance

What changes

  • If rent collection has not changed an account, the account must not be stored/written back in that slot.
  • An important note, rent collection updates an account's rent epoch in addition to its balance. If rent collection does not collect rent (i.e. the account's balance is unchanged), but does change the account's rent epoch, the account must still be stored.
  • Do not rewrite accounts that are unchanged by rent collection.

Stakeholder map

Who is affected

Builders & client teams Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Validators & operators Medium impact

Validators will see performance improvements:

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

Do not rewrite accounts that are unchanged by rent collection.

Motivation

Rent collection checks every account at least once per epoch. This process loads and stores accounts, regardless if the account has actually changed or not. All accounts now must be rent-exempt, and there are zero rent-paying accounts on mainnet-beta. Thus, almost every account stored due to rent collection is unchanged, and storing unchanged accounts is useless work.

Worse, storing accounts incurs all the downstream costs on the accounts database: computing the various accounts hashes on extra accounts unnecessarily, tracking/cleaning/purging the new and old versions of accounts, plus it bloats the incremental snapshots with accounts that haven't meaningfully changed.

Alternatives Considered

We could remove rent collection entirely, and that is already planned (see SIMD-0084). Skipping rewrites is a smaller, less complex change, which can allow rollout and activation sooner.

New Terminology

"Skipping rewrites" means to not store accounts that are unchanged by rent collection.

Detailed Design

If rent collection has not changed an account, the account must not be stored/written back in that slot.

An important note, rent collection updates an account's rent epoch in addition to its balance. If rent collection does not collect rent (i.e. the account's balance is unchanged), but does change the account's rent epoch, the account must still be stored.

To state another consequence explicitly, since these accounts will not be rewritten, they will no longer be part of the accounts delta hash nor the incremental accounts hash.

Impact

Validators will see performance improvements:

  • Fewer accounts will need to be stored per slot.
  • Fewer accounts will need to be hashed for the various accounts hashes.
  • Fewer accounts will need to be included in incremental snapshots.

Security Considerations

Having all accounts rewritten due to rent collection results in all accounts being included in at least one bank hash per epoch. Since the bank hash is part of what is voted on for consensus, this means every account is verified by the network at least once per epoch.

By skipping rewrites, we lose this security property. This is OK because the Epoch Accounts Hash (EAH) was added to directly address this issue. See the EAH proposal for more information.

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 #183 · merged SIMD-0183: Skip Rent Rewrites 4 comments and reviews · Feb 2, 2026
@HaoranYi

maybe, mention that account's delta hash and incremental snapshot hash will change, but full hash won't change? however, since this will be guarded with a feature, it won't break consensus.

GitHub ↗
@brooksprumo

Done in https://github.com/solana-foundation/solana-improvement-documents/pull/183/commits/69527f875b048e164f1d14b0f27bda541290207e!

GitHub ↗
@brooksprumo

Paging @jacobcreech, we have approval from Anza and Firedancer 😸

GitHub ↗

simd.watch community discussion · SIMD-0183

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 lifecycleActivated
CategoryCore protocol

One or more sources are unavailable.

Exact source revision

Sources & integrity

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

One or more sources are unavailable.

One or more sources are unavailable.