Anchoring & Cascading Tiers

EDH proves the integrity of health data with Merkle-tree anchoring: a single 32-byte root cryptographically commits to millions of records, and that root is written to one or more chains for independent, tamper-evident verification. Confidentiality is separate — it's handled by client-side NaCl encryption; the backend never sees plaintext.

A record's leaf hash is HMAC-salted, batched into a Merkle tree, and the root is salted per chain before submission so the same batch can't be correlated across chains. Individual patient addresses are never put on-chain — only the opaque root.

The cascade: a ladder of assurance

Instead of picking a single chain, EDH anchors up a tiered ladder. Anchoring "up to tier N" writes the root to every target in tiers 0..N — an inclusive cascade where each rung adds a distinct security property:

Tier	Target(s)	What it adds	Cost
0 — Consortium	Besu (free-gas)	Always-on base; you run the validators	$0/tx
1 — Public L2	Polygon	Public-chain timestamp, external verifiability	~$0.01/tx
2 — Permanent	Arweave	Permanent, immutable root record	~$0.005 one-time
3 — Maximum	Ethereum + Bitcoin	Maximum neutrality + PoW censorship-resistance	~$1–10 / free (OTS)

Higher tiers include all lower tiers: a tier-2 anchor lands on Besu and Polygon and Arweave.

Why cascade rather than one chain

• Cost-tiered. The high-volume base (tier 0) is a free-gas consortium chain — the hospitals that already run EDH's IPFS nodes also run its validators, so routine anchoring costs nothing. You only pay public-chain fees for the records or tiers that warrant stronger proof.
• Trust-tiered. A hospital-run consortium can't self-certify neutrality. Cascading up to a public chain gives independent, exportable tamper-evidence — the standard antidote to the governance-cartel risk of a consortium validator set. The data stays on the cheap chain; the proof escalates.
• Distinct properties only. Each rung is a genuinely different security model (free-gas sovereignty → public timestamp → permanence → PoW neutrality), never redundant chains that settle to the same place. Per-chain root salting keeps the wider footprint uncorrelatable.

Subscription tiers map to a maximum cascade tier (e.g. free → 0, plus → 1, pro → 2, sovereign → 3), so paid plans get broader, more durable anchoring — while account registration itself always stays free and ungated.

API

POST /v1/anchoring/anchor
{ "leaves": ["<hmac-salted-leaf>", "..."], "cascadeTier": 2 }     # explicit tier
{ "leaves": ["..."], "subscriptionTier": "pro" }                  # mapped → tier 2

GET  /v1/anchoring/tiers        # inspect the ladder + subscription mapping

The response groups anchors by tier and returns each anchor's epochSalt — store these (per tier/chain) to verify the root on-chain later. When anchoring is disabled (ANCHOR_ENABLED=false), the endpoint returns the Merkle root and the planned cascade (status: dry_run) without submitting anything.

Verification

A user (or any auditor) can verify a record end-to-end without trusting the server: replay the Merkle proof to the root, derive the per-chain root with the stored epochSalt, then check AccessLogAnchor.verifyRoot(chainRoot) on any tier the batch was anchored to. The chain's block timestamp is the proof.

Configuration

Operators control the ladder per deployment:

Variable	Purpose
ANCHOR_CASCADE_TIERS	JSON array overriding the tier ladder entirely
ANCHOR_TIER_MAP	free:0,plus:1,pro:2,sovereign:3 — subscription → max tier
ANCHOR_BESU_RPC_URL / ANCHOR_BESU_CHAIN_ID	consortium chain (tier 0)
ANCHOR_ENABLED	master switch; false = dry-run (compute, don't submit)

Self-hosted deployments can collapse the ladder to a single tier, or point tier 0 at hardhat/ipfs if they don't run a Besu consortium. See the full anchoring architecture (docs/ANCHORING.md) in the repository for the security model, threat table, and post-quantum considerations.