> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sudont.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# State Freshness Model

> How Sudont distinguishes freshness from cache warmth, and the four freshness states.

Sudont distinguishes freshness from cache warmth.

<Note>
  The freshness states described below reference Flashblocks/Base, which is
  **EVM-side roadmap material**. The current SVM hot-path runs against
  LiteSVM-replayed mainnet state; the Flashblocks-aware enforcement rules apply
  to the planned EVM engine.
</Note>

## Freshness states

* `FLASHBLOCKS_PENDING`
  Use only when the local node view is backed by Flashblocks-aware pending data.
* `PENDING_UNCONFIRMED`
  Local pending state exists, but there is no Flashblocks confidence attached.
* `SEALED_LATEST`
  Simulation ran against the latest sealed block.
* `DEGRADED`
  Simulation required fallback behavior or could not establish the intended state view cleanly.

## Confidence states

* `HIGH`
  Prehydration succeeded against the intended node-backed view with useful access discovery.
* `MEDIUM`
  Prehydration succeeded, but coverage is narrower than ideal.
* `LOW`
  Fallback behavior was required or access discovery was weak.
* `UNKNOWN`
  Sudont cannot describe the reliability of the state view.

## Enforcement rules

* Send mode is pending-first.
* If policy requires pending state, `SEALED_LATEST` and `DEGRADED` must be denied.
* If policy requires Flashblocks, anything other than `FLASHBLOCKS_PENDING` must be denied.
* If policy is fail-closed, `LOW` or `UNKNOWN` confidence must be denied.
* Diagnose mode may continue on `SEALED_LATEST` or `DEGRADED`, but the freshness and confidence labels must be exposed in diagnostics.

## Current implementation notes

* The runtime now classifies stale local heads as `DEGRADED` when the sealed head timestamp exceeds the configured lag budget.
* The runtime can emit `FLASHBLOCKS_PENDING` only when Flashblocks mode is enabled and a live `newFlashblocks` verifier feed is recent enough to match the local pending view.
* If Flashblocks mode is enabled but the verifier feed is missing, stale, or mismatched against local pending state, Sudont falls back to `PENDING_UNCONFIRMED`.
* Access-list generation is a helper, not the source of truth. Node-backed account, code, and storage reads still hydrate the final in-memory DB.
* Hydration is request-scoped in the current sidecar. A new block does not mutate
  an already-running simulation; the next RPC request hydrates against the
  current pending/latest view and logs the account and storage-slot working set.