Skip to main content

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.

Sudont distinguishes freshness from cache warmth.
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.

​
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.