Storage Tiers

DRS uses a six-tier storage model. The canonical reference lives in docs/storage-tiers.md; this page summarizes it and highlights what is actually implemented today.

Tier reference

TierNameBackendEnv varsStatus
0SessionIn-memory(none)Implemented
1EphemeralLocal filesystemSTORE_DIRImplemented
2DurableS3-compatible object storeroadmapNot implemented
3CompliantFilesystem + RFC 3161 timestampingSTORE_DIR + TSA_URLPartially implemented
4TimestampedTier 3 deployment posture with timestamp retrieval/reportingSTORE_DIR + TSA_URLPartially implemented
5On-chainTier 3 + Ethereum anchorroadmapNot implemented

What is actually implemented today

Tier 0: default when STORE_DIR is unset. Receipts are lost on restart.

Tier 1: receipts are written to the local filesystem and survive restart.

Tier 2: documented target only. There is no S3-compatible store in the current codebase.

Tier 3: when TSA_URL is set, drs-verify stores the receipt and attempts RFC 3161 timestamping. This is best-effort:

  • the receipt is still stored if the TSA is unavailable
  • the timestamp is stored alongside the receipt when available
  • WORM semantics are not enforced by the current filesystem backend

Tier 4: same backend as Tier 3. Today this is a reporting / operator posture rather than a separate storage engine.

Tier 5: Ethereum anchoring is a roadmap item, not a delivered feature.

Configuration

# Tier 0 — session / in-memory
LISTEN_ADDR=:8080 ./drs-verify

# Tier 1 — filesystem
LISTEN_ADDR=:8080 \
  STORE_DIR=/data/drs \
  ./drs-verify

# Tier 3 / Tier 4 — filesystem + RFC 3161 timestamping
LISTEN_ADDR=:8080 \
  STORE_DIR=/data/drs \
  TSA_URL=https://freetsa.org/tsr \
  ./drs-verify

For the full canonical model, caveats, and tier semantics, see Canonical Storage Tiers.