1. Context and Motivation

The Nomos mempool currently accepts transactions without checks.

Validation happens later, when a block references them and Chain verifies each one.

This keeps the pool simple but allows invalid or conflicting transactions to occupy memory and bandwidth until block time.

Full validation when transactions enter the pool would reject invalid data immediately and keep only verified items.

Two paths are being evaluated:

  1. Delegated validation — the mempool forwards transactions to Chain for checking.

  2. Local validation — the mempool maintains a read-only ledger view and validates independently.

2. Design Requirements

Requirement Description
Determinism Validation results must match Chain replay for the same fork.
Read-only state access Validation can read ledger data but not modify it.
Bounded cost Validation work must stay predictable under load.
Result reuse Signature and proof checks should be cached for Chain replay.
Atomicity Each transaction is either fully accepted or rejected.

3. Validation Models

Delegated validation

The mempool forwards transactions to Chain.

Chain validates them using its current ledger view and returns a result.

Only transactions that pass validation are stored.

Flow

  1. Transaction received.
  2. Forwarded to Chain for verification.
  3. Chain validates and returns accept or reject.