The neighbourhood — and where we sit in it.

In common

Validates the T0/T1 design: rollups that spin up, run, and disappear with a configurable commit cadence. Has converged on hardware attestation (Intel TDX), the same direction as our HATP.

Where it differs

US/global jurisdiction; SVM is untyped; commit-back to Solana; no durable / compliance / eternal tier; no per-entry typed logic; no GDPR-by-construction.

When to pick which

A great choice if you want millisecond gaming or DeFi state on a Solana commit cadence. We are the choice when the same workload also needs a 6-year compliance receipt at the other end.

In common

Validates the “ephemeral data + persistent commitment” pattern at the largest smart-contract chain. KZG commitments outlive blobs the same way Merkle roots outlive Ephernity entries.

Where it differs

Single fixed window; rollup-data niche; no per-entry signature beyond the proposer; no attestation; not tier-parametrised.

When to pick which

Right answer if you operate a rollup. Ours is the right answer if your workload is not a rollup and you need the same data to live for years, not 18 days.

In common

Validates rolling-window retention with custodial archival elsewhere — data is ephemeral by design at the DA layer.

Where it differs

DA for rollups, not a programmable ledger; no per-entry signatures; no attestation; no multi-tier story.

When to pick which

Ideal as a DA layer for rollups. Not a substitute when you need provenance, audit, or compliance retention on the same data.

In common

Retention is a first-class parameter — directly validates our tier knob. FVM smart-storage moving toward perpetual renewal converges with our T4.

Where it differs

Token marketplace economics (MiCA surface); storage, not attested compute; no typed logic; integrity = proofs of storage, not per-entry signatures.

When to pick which

A reasonable cold-storage backend for the T4 tier. Not by itself a tamper-evident ledger for the operational/compliance tiers.

In common

Validates the eternal tier; a credible candidate external permanence backend behind our T4.

Where it differs

“Pay once, store forever” collides head-on with GDPR Article 17 — their own documented weakness. Our crypto-shred solves what their model can't.

When to pick which

Use Arweave when you need permanent public storage of non-personal data. Use us when the same record also needs to be erasure-compliant.

In common

Almost exactly Mile, our reference micro-ledger storage backend: signed Merkle tree, content-verified, sparse P2P replication, Ed25519.

Where it differs

Time-agnostic, no tier model; no hardware attestation; no PQC; no compliance framing; no operator-led trust model.

When to pick which

The reference design we learned from. We add the four things they did not attempt: tiering, attestation, PQC, EU-sovereign operator.

In common

BLAKE3 verified streaming and content-addressing — the same building block Ephernity uses for the wire. Architecturally the closest current peer.

Where it differs

Peer-to-peer rather than operator-attested; no tier knob; no PQC; no offline-verifiable trust chain rooted in a single root public key.

When to pick which

A clean choice for trustless P2P sync. Ours is the choice when the verifier needs to trust one specific root key and the record needs to survive a regulatory inspection.

In common

Single signed append-only history verifiable from a public key. The same primitive at the storage tier.

Where it differs

Social/peer use cases; no tier model; no hardware attestation; no compliance framing.

When to pick which

Excellent for social graphs and decentralised messaging. Not designed to be the durable side of an audit shelf.

In common

World-first post-quantum mainnet transaction (Nov 2025) — using Falcon, the same scheme Ephernity uses for T3 · T4. Strongest external validation of our PQC choice.

Where it differs

Full-stack L1 with native token (ALGO); PQC is on state proofs, not on a tier-parametrised per-entry ledger.

When to pick which

Build on Algorand if you want a permissionless L1 with PQC state proofs. Build on Ephernity if you want PQC durability without an L1.

In common

The closest "EU-hostable + PQC" adjacency; piloted by an EU ministry (May 2025); shows the category has institutional pull.

Where it differs

Token-based public chain (CryptoQNT); permissionless L1 vs. our operator-led ledger; no tier model; no attested signing chain.

When to pick which

A peer rather than a substitute. We watch QAN closely; the procurement they win is procurement we lose, and vice versa.

In common

The EU's own permissioned blockchain validates the category; keeps personal data off-ledger and uses on-chain hashes — exactly our design pattern.

Where it differs

Public-sector, slow, consortium-permissioned; not commercial; no tier knob; no Falcon today.

When to pick which

A potential anchor target rather than a substitute. We make EBSI optional as an anchor backend per ledger policy.