Extending Storage Expiry (2026)

[topocount]

Title: Extending Storage Expiry (2026)
Type: Implementation FIP
Authors: @topocount

Abstract

Extend the validity of every storage unit rented before this proposal's activation date by one
additional year. Units rented on or after the activation date retain the standard one-year validity
introduced by the Storage Redenomination. There are no changes to unit sizes, message limits,
rate limits, or pricing — this proposal only moves expiry dates further out.

Problem

Under the Storage Redenomination (#229,
effective 2025-07-16), newly rented storage units are valid for one year. The first cohort of these
units therefore begins to expire around 2026-07-16.

When a unit expires, the renting account's storage becomes inactive: new messages from that account
are no longer admitted, and the account's existing messages become eligible for pruning. Forcing a
large cohort of users to re-rent storage on a hard deadline — or lose data and the ability to post —
drives churn and degrades the network experience. This is the same problem FIP-17 addressed in 2024,
and the same one-year deferral the Redenomination applied to the units that predated it.

Rather than require action from every affected user, we extend the expiry of the already-rented
cohort by one more year, giving the community and clients a longer runway while preserving the
one-year steady state for all future rentals.

Specification

Let T be the activation timestamp of this proposal (see Release).

Storage validity is computed from each unit's rental (block) timestamp. A unit's validity period
is extended by one additional year (31,536,000 seconds) if and only if it was rented before
T. Concretely, validity by rental cohort becomes:

Cohort	Rented during	Validity before	Validity after (rented before T)
Legacy	before 2024-08-29	3 years (94,608,000s)	4 years (126,144,000s)
2024	2024-08-29 → 2025-07-16	2 years (63,072,000s)	3 years (94,608,000s)
2025	2025-07-16 → T	1 year (31,536,000s)	2 years (63,072,000s)
New	on/after T	1 year (31,536,000s)	1 year (31,536,000s) — unchanged

A unit's expiry is rental_timestamp + validity. Because expiry is derived from the rental timestamp
rather than stored, the extension applies retroactively and automatically to all existing units of
each cohort the moment the change activates; no re-rental, migration, or event reprocessing is
required.

The boundary between the "2025" cohort (extended) and "New" units (not extended) is T itself, so
units rented at or after activation are unaffected and continue to expire one year after rental.

No other parameters change. Unit sizes, per-store message limits, daily rate limits, and storage
pricing are identical before and after T.

Determinism / activation. Storage expiry feeds the active/inactive check that gates message
admission during block production, so the change is consensus-affecting and must take effect at the
same instant for every node. It is gated behind a new Snapchain engine version (V18): nodes apply the
extended validity to blocks at or after T and the prior validity to earlier blocks, keyed off the
block timestamp (not wall-clock time). The Snapchain protocol version is incremented so that nodes
still running the prior rules become gossip-incompatible at activation.

Impact to users

No action required. Storage that would have expired keeps its current limits and simply stays valid
for one additional year. Expiry dates shown in clients extend automatically once the change
activates. Users who rent new storage on or after T receive the standard one-year validity, as
today.

Impact to developers

APIs that report storage limits and usage are unchanged in shape; any expiry/validity they surface
will reflect the extended dates automatically after activation, with no client changes needed.

Clients or indexers that compute storage expiry locally from on-chain rent events (rather than
reading it from a node) must apply the updated per-cohort validity above and gate the change at T
to stay consistent with the network. Note the on-chain rent event's own expiry field is not
authoritative for protocol validity and should not be used for this purpose.

Impact to hub / node runners

Operators must upgrade to the Snapchain release containing engine version V18 before the
activation timestamp for their network (testnet first, then mainnet — see Release). Nodes that have
not upgraded by T will compute different expiry than the network and, due to the protocol-version
bump, will be gossip-incompatible until upgraded. No database migration or re-sync is required; the
extension is purely computational.

Rationale

• Cutoff-based extension matches precedent. FIP-17 and the Redenomination both extended the
  existing cohort by one year while keeping newer units at one year via a timestamp cutoff. Reusing
  that mechanism keeps the model consistent and easy to reason about.
• No redenomination needed. The 2025 unit sizing and pricing are unchanged; only expiry is at
  issue, so we deliberately avoid introducing a new unit type or altering limits.
• Retroactive and zero-touch. Because validity is a function of the rental timestamp, extending
  the multipliers reaches every already-rented unit automatically, with no user action and no data
  migration.
• Steady state preserved. Keeping post-T rentals at one year avoids permanently changing
  storage economics; this is a one-time deferral for the current cohort, repeatable in future years
  if desired.

Release

Network	Activation T (UTC)	Unix
Testnet	2026-06-12 17:00	1781283600
Mainnet	2026-06-22 17:00	1782147600

The Snapchain release containing engine version V18 must be deployed to each network before its
activation timestamp, and comfortably before the first 2025-cohort units begin expiring (~2026-07-16
on mainnet).