Sets rent_epoch to a constant in the VM
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
Set the value of rent_epoch—as serialized into the VM for transaction processing—to a constant.
Proposal at a glance
What changes
- Set the value of rent_epoch—as serialized into the VM for transaction processing—to a constant.
Stakeholder map
Who is affected
Builders & client teams Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownValidators & operators Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownUsers & stakers Medium impact
Set the value of rent_epoch—as serialized into the VM for transaction processing—to a constant.
Action requirement unknownGovernance & ecosystem Impact unknown
No proposal-specific evidence was found for this group.
Action requirement unknownExact source revision
Full proposal document
0616093b2952Summary
Set the value of rent_epoch—as serialized into the VM for transaction
processing—to a constant.
Motivation
The rent_epoch field on an account is no longer meaningful. This is because
all accounts must be rent exempt, and rent fees collection has been disabled
(see SIMD-84). With this in mind, it would be beneficial to remove
rent_epoch from the computation of a single account's hash.
However, before we can remove the rent_epoch from the account hash
computation, we must set the value of rent_epoch—as serialized into the VM
for transaction processing—to a constant. If we did not do this, different
validators could have different values for rent_epoch passed into the VM,
which could result in different transaction results and thus cluster
divergence.
New Terminology
None.
Detailed Design
The value of the rent_epoch field serialized into the VM per account shall be
set to the constant used to denote a rent-exempt account. This value is
u64::MAX, aka 0xFFFF_FFFF_FFFF_FFFF.
Alternatives Considered
None.
Impact
The rent_epoch field in an account can be deprecated. This allows reclaiming
and reusing these bytes for other purposes in the future.
In certain rare cases the serialized rent_epoch of an account may previously
have been 0 and will now be u64::MAX.
Security Considerations
None.
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 #267 · merged SIMD-0267: Sets rentepoch to a constant in the VM 21 comments and reviews · Jan 19, 2026I think after SIMD-0215, SIMD-0223 and SIMD-0220 have been activated we will no longer have a merkle hash, so we can effectively close SIMD-0224. Correct me if I'm wrong :) Yes, let's close SIMD 224.
GitHub ↗I still think that discussions related to how the rentepoch field is used in hashing is unrelated to this SIMD though. I'd prefer if we moved them elsewhere.
GitHub ↗Blocking due to concerns voiced in a chatroom. We should document behavior changes for non-existent and recently-created accounts. Added in https://github.com/solana-foundation/solana-improvement-documents/pull/267/commits/1b28deff8f5ad66226721f851067c8ee425bf502.
GitHub ↗Approving on behalf of Firedancer
GitHub ↗I'm marking this conversation as "resolved". Please reopen if/as new questions/comments arise.
GitHub ↗I'm marking this conversation as "resolved". Please reopen if/as new questions/comments arise.
GitHub ↗I'm doing a long-running test to see if any mnb programs would be impacted by this change. We'll wait to merge until that test concludes.
GitHub ↗I'm doing a long-running test to see if any mnb programs would be impacted by this change. We'll wait to merge until that test concludes. My node that has been running with the rent epoch set to u64::MAX in the VM hasn't crashed all week long (182 hours total), so I think it's safe to merge!
GitHub ↗Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 2
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
RENtePQcDLrAbxAsP3k8dwVcnNYQ466hi2uKvALjnXxExact source revision
Sources & integrity
- Proposal document pinned_commit_blob
0616093b2952ed6de52c4a27d66aadd11d48d4f9 - simd-document document · stale · Sep 10, 2026
0616093b2952ed6de52c4a27d66aadd11d48d4f9
One or more sources are unavailable.
simd.watch community discussion · SIMD-0267
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.