Documentation / @etherfold/processor-entities / RetentionSetting

Type Alias: RetentionSetting

RetentionSetting = "revert-only" | "unbounded" | { blocks: number; }

Defined in: packages/state-store/dist/retention.d.ts:33

What a deployment writes: a distance in BLOCK NUMBERS, or one of the two ends.

The window is {blocks: N} and not a bare N, because a bare number names no unit and this surface has exactly one. It is also not {seconds}, {days} or {updates}, and those are rejected loudly rather than ignored (see resolveRetention).

Choosing N is not choosing a number of updates. On the real measured stream (the launched stratagems game on Base) event-bearing blocks are median 429 blocks apart, so a window of 64 blocks holds exactly ONE event-bearing block, and reading "64 blocks" as "64 updates of history" is wrong by orders of magnitude on any sparse contract. Size a window against the chain's block rate and the contract's activity, not against how much history it feels like.

Union Members

"revert-only"

Reorg safety and no history, said honestly: superseded versions survive only as long as reorg revert needs them (its floor is the finalityDepth stated beside it, which is also what it prunes to), and no historical read is answered at all. Such a store reports asOf: false, so a caller that needs history learns it at STARTUP rather than from a refused read later.

This is what to write for "no history", rather than approximating it with a small window: a window is a distance in BLOCK NUMBERS (above), so a short one refuses nearly every historical read while looking configured for history.

---

"unbounded"

Keep everything: nothing is ever pruned, and the whole history is readable.

---

Type Literal

{ blocks: number; }

Keep superseded versions for blocks block numbers behind the tip.