How Leani works

Leani is an application-specific Ethereum indexing node. It does not synchronize Ethereum’s execution state and then ask what your application needs. It declares the processor’s material requirements first, obtains only sources capable of satisfying them, and retains only the products selected by lifecycle policy.

1. 01 acquirehistory and live head, one exact handoff
2. 02 validatecommitments, canonicality, provenance
3. 03 reducedeterministic processors, ordered state
4. 04 deliverquery, stream, acknowledge, prune

Acquire by capability

A planner chooses a retained, archive, RPC, or P2P source only when it declares all material required for that request.

Validate before publish

Hashes, commitments, ancestry, canonicality, and finality provenance are checked at the appropriate trust boundary.

Reduce deterministically

Block-local work can run concurrently. Stateful deltas reduce in canonical order with undo and checkpoint behavior defined by the processor.

Retain by policy

State, output, artifacts, delivery, checkpoints, undo, and raw history have separate policies and budgets.

The intended storage shape is:

disk = application products
     + processor state and checkpoints
     + a bounded recent/reorg window
     + one bounded transient input chunk
     + optional indexes explicitly enabled by the operator

State-minimized, not stateless

A token balance, latest pool price, or running aggregate is application state and can be durable. Leani avoids retaining the EVM state trie and unrelated chain history; it does not pretend useful indexes require no state.

Continue with coverage and finality and storage lifecycles.