Skip Rent Rewrites
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
Do not rewrite accounts that are unchanged by rent collection.
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 unknownValidators & operators Medium impact
Validators will see performance improvements:
Action requirement unknownUsers & stakers Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownGovernance & ecosystem Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownExact source revision
Full proposal document
0616093b2952Summary
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, 2026maybe, 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 ↗Done in https://github.com/solana-foundation/solana-improvement-documents/pull/183/commits/69527f875b048e164f1d14b0f27bda541290207e!
GitHub ↗lgtm..
GitHub ↗Paging @jacobcreech, we have approval from Anza and Firedancer 😸
GitHub ↗Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 3
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
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.
simd.watch community discussion · SIMD-0183
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.