Reduce lamports_per_byte to 3480
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
Reduce lamports_per_byte by 50% to 3480, which is equivalent to reducing the rent-exempt minimum balance by half for all new and existing accounts. Requires SIMD-0392: Relaxation of post-execution min_balance check, to allow for subsequent rent increases if necessary.
Proposal at a glance
What changes
- Reduce lamports_per_byte by 50% to 3480, which is equivalent to reducing the rent-exempt minimum balance by half for all new and existing accounts. Requires SIMD-0392: Relaxation of post-execution min_balance check, to allow for subsequent rent increases if necessary.
Stakeholder map
Who is affected
Builders & client teams Medium impact
Lower rent for app developers. Existing accounts and programs using the higher rent value will be unaffected, besides being allowed to reduce the balance to the new minimum.
Action requirement unknownValidators & operators Medium impact
Validators: a potential increase in state growth. In the unlikely case of excessive state growth, rent can be increased back to the legacy value (0392 allows this without significant disruption to existing accounts.)
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
f1f6c8b05dc2Summary
Reduce lamports_per_byte by 50% to 3480, which is equivalent
to reducing the rent-exempt minimum balance by half for all
new and existing accounts.
Requires SIMD-0392: Relaxation of post-execution min_balance check, to allow for subsequent rent increases if necessary.
Motivation
Minimum account balance depends on an arbitrary constant set years ago that has since increased significantly in real terms due to increases in the SOL price. This has made state allocation cost more expensive on mainnet beta than on competitors, with no compelling justification provided by real resource costs.
New Terminology
N/A
Detailed Design
On feature activation, set the effective lamports_per_byte
to 3480 in the bank and rent sysvar
(SysvarRent111111111111111111111111111111111), followed by
updating DEFAULT_LAMPORTS_PER_BYTE in all relevant SDKs
post-activation.
ACCOUNT_STORAGE_OVERHEAD = 128
lamports_per_byte = 3480 // reduced from 6960 by this proposal
effective_size = ACCOUNT_STORAGE_OVERHEAD + data_size_bytes
min_balance = effective_size * lamports_per_byte
= effective_size * 3480
Alternatives Considered
This proposal is the first step towards further rent reduction and doesn't prevent adoption of alternative solutions like a supervisory controller (SIMD-0389). A 2x reduction is picking the low hanging fruit by modestly reducing the extremely inflated rent cost on mainnet beta today.
Impact
- Lower rent for app developers. Existing accounts and programs using the higher rent value will be unaffected, besides being allowed to reduce the balance to the new minimum.
- Validators: a potential increase in state growth. In the unlikely case of excessive state growth, rent can be increased back to the legacy value (0392 allows this without significant disruption to existing accounts.)
Security Considerations
N/A
Backwards Compatibility
Rent reduction is strictly a relaxation of existing constraints so all existing program logic will continue to work as before.
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 #436 · merged SIMD-0436: Reduce lamportsperbyte from 6960 to 3480 22 comments and reviews · Apr 6, 2026Right, the bank is treated as the source-of-truth but there's no automatic per-slot call to updaterent so we need to explicitly make the call when this feature is activated. I think we're basically saying the same thing though. I added the change you requested + also mentioned the sysvar to avoid any potential ambiguity. Good point on the SDKs and thanks for the feedback!
GitHub ↗Thanks, bw-solana(https://github.com/bw-solana)! ⚠️ Status: Cannot merge yet - Missing approval from: Firedancer (ptaffet-jump(https://github.com/ptaffet-jump), topointon-jump(https://github.com/topointon-jump), 0x0ece(https://github.com/0x0ece), lidatong(https://github.com/lidatong), or ripatel-fd(https://github.com/ripatel-fd))
GitHub ↗✅ All approvals received! @igor56D, you can now merge this by commenting /merge. ✅ Status: Ready to merge
GitHub ↗✅ All approvals received! @igor56D, you can now merge this by commenting /merge. ✅ Status: Ready to merge
GitHub ↗/merge
GitHub ↗✅ Merge successful! igor56D(https://github.com/igor56D)'s PR has been merged.
GitHub ↗hey guys, is this live now?
GitHub ↗hey guys, is this live now? @mmarzullotv https://github.com/anza-xyz/agave/wiki/Feature-Gate-Tracker-Schedule
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
Feature Gate not yet created
Exact source revision
Sources & integrity
- Proposal document pinned_commit_blob
f1f6c8b05dc205552d3c290a854a438392701107 - simd-document document · stale · Oct 16, 2026
f1f6c8b05dc205552d3c290a854a438392701107
One or more sources are unavailable.
simd.watch community discussion · SIMD-0436
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.