Revolutionary Technology

Discover the cutting-edge consensus mechanism, unparalleled performance, and future-proof security that powers Silica Protocol.

Consensus Architecture

Release design — the target architecture for release, not a snapshot of current implementation. Silica uses a named layered architecture: Tephra ingress batches and disseminates payloads, Tephra orders them through gossip-about-gossip consensus, Crystallite applies the ordered result, Lithification packages proofs and checkpoints, and Cali judges the result — monitoring every layer and enforcing punishment.

Architecture Note

This page reflects the release design source of truth. The names on this page are intentional release layer names. Implementation details and performance metrics evolve as we optimize the network. For technical implementation details, see the GitHub repository.

Canonical shorthand: Tephra ingress = data plane, Tephra = ordering/consensus, Crystallite = execution/apply, Lithification = proofs/checkpoints, Cali = monitoring/enforcement (the judge).

LAYER 1 • DATA PLANE

Tephra ingress

Batching and dissemination front end for transaction intake into Tephra consensus.

  • • Batches proposal payloads for efficient network fanout
  • • Disseminates payloads and references into the ordering layer
  • • Keeps batching and network dissemination distinct from consensus ordering
  • • Batching and dissemination influence belongs here, not on ordering
\n
LAYER 2 • ORDERING

Tephra

Gossip-about-gossip consensus layer that turns the shared event DAG into deterministic proposal order.

  • • Virtual voting is computed locally from gossip history
  • • Same event DAG yields the same order on all honest nodes
  • • No extra ordering authority exists beyond Tephra order
  • • Ordering truth for the entire protocol
LAYER 3 • EXECUTION / APPLY

Crystallite

Parallel execution framework that applies Tephra order across deterministic state lanes.

  • • Schedules ordered transactions for parallelism
  • • Each execution lane is a single deterministic execution context
  • • Determinism preserved across replicas
  • • Maximizes throughput without re-ordering
LAYER 4 • PROOFS / CHECKPOINTS

Lithification

Once ordered proposals are applied locally, state transitions are final; anchors and proofs package the result for audit, replay, and fast sync.

  • • Finality achieved at commit + local apply (no reorgs)
  • • Emits anchors, certificates, and checkpoints as proofs
  • • Checkpoints simplify audit, sync, and recovery
  • • Evidence feeds Cali judgement and enforcement
LAYER 5 • MONITOR / ENFORCE

Cali — the Judge

Cali sees every layer: committee votes, execution evidence, and finalized proofs. It monitors health, judges misbehaviour, and enforces punishment — including slashing.

  • • Monitors every layer: votes, execution, proofs, liveness
  • • Judges equivocation, invalid proposals, and liveness attacks
  • • Enforces slashing and jailing via staking and bank
  • • Triggers recovery and restarts on stalls

Layer Stack

1. Tephra ingress
batching / dissemination
2. Tephra
virtual voting
3. Crystallite
execution / apply
4. Lithification
proofs / checkpoints
5. Cali
judge: monitor + enforce
Lineation
regular checkpoint anchor
Lineament
major epoch anchor
Anchors

Lineation & Lineament

Silica produces periodic anchor blocks that commit the network’s full activity into compact, verifiable checkpoints. Anchors don’t change ordering or finality; they make the chain auditable, recoverable, and easy to synchronize at scale.

Lineation (regular checkpoint)
Frequent anchor: commits aggregated roots + receipts for fast sync and replay windows.
Lineament (major epoch anchor)
Less frequent, stronger anchor: ties multiple Lineations into an epoch boundary and long-term audit point.
Typical inputs
  • •Per-lane execution/state roots (from execution + monitoring)
  • •Shard/global aggregation roots (Merkle roots over receipts & state)
  • •GPoD outputs (digests of performance, integrity, and anomaly evidence)
  • •PoUW receipts (work proofs summarized into a compact root)

Performance Benchmarks

Architecture design targets. Measured benchmarks will be published with methodology when available.

Design Targets

The numbers below are design targets for the Silica architecture. Third-party TPS numbers are approximate and sourced from public documentation. Silica benchmarks will be published with full methodology when available.

Transaction Throughput (TPS)

Silica
Target
Solana
65,000
Ethereum
15
Bitcoin
7

Finality Time

Silica
Target
Solana
~2.5s
Ethereum
~6 min
Bitcoin
~60 min
High
Throughput Target
Fast
Finality Target
64–96
Validator Set (target)
PQ
Post-Quantum Secure

Post-Quantum Security

Silica is built with quantum-resistant cryptography from day one, ensuring your assets remain secure even as quantum computing advances.

NIST-Approved Algorithms

Release design: ML-DSA-44/65/87 (FIPS 204) for native accounts, validator authentication, and finality. Chain-wide PQ gaps (transport, randomness, DKS) are tracked in the PQ gap register and DP024 — see the roadmap.

Hybrid Approach

Classical and post-quantum crypto for smooth transition

Future-Proof Design

Upgradeable cryptography without hard forks

Learn More About Security

Quantum-Resistant Now

While others rush to upgrade, Silica users are already protected against future quantum attacks with proven, standardized cryptographic algorithms.

Ready to Explore the Technology?

Dive deeper into Silica's advanced architecture and technical specifications.