Components

Patterns for composing content elements across the docs.

Section Headings

Every H2 gets a shape prefix. The shape is an inline <img> at 14px, vertically centered.

Feature Cards

Grid of cards with shape accent, title, and description. Used for overviews and principle lists.

Fast Finality

Sub-second block finality via Simplex BFT. No waiting for confirmations.

Cryptographic Auth

Every message is self-authenticating with Ed25519 signatures and BLAKE3 hashes.

Parallel Execution

Projects execute in parallel within each block via rayon thread pool.

Stat Blocks

Horizontal row of key metrics. Shape serves as a bullet marker.

~200ms

Block time

~300ms

Finality

10k+

Messages/sec

32 bytes

Content-addressed IDs

Status Row

Inline shapes as status indicators.

Code Blocks

Fenced code blocks use the #111111 background with monospace font.

// Content-addressed project ID
let project_id = blake3::hash(&message_bytes);

cargo run --bin node -- --port 50051 --p2p-port 50052

Global State Root
├── Project A Root (BLAKE3 of sorted key-value diffs)
├── Project B Root
└── ...

Tables

Standard markdown tables for structured data. Borders and backgrounds come from theme tokens.

Lists with Shapes

Use shapes as custom bullet markers for feature lists.

Permissionless — anyone can create projects and push code without gatekeepers

Content-addressed — project IDs are BLAKE3 hashes of creation messages

CRDT semantics — deterministic conflict resolution with LWW, remove-wins, and CAS

Merkle-authenticated — every state entry is provable via per-project roots

Callout Boxes

Bordered containers for important information, keyed by shape.

Note

The consensus layer stores only message metadata (~100-500 bytes). File content lives in a separate DA layer.

Important

REF_UPDATE uses compare-and-swap. If the ref has moved since your read, the update is rejected.

Tip

Use cargo test test_name to run a single test by name for fast iteration.

Architecture Diagrams

ASCII diagrams in fenced code blocks, referenced by surrounding shapes.

┌─────────────────────────┐
│  Clients                │  grpc-web / gRPC
│  (Browser, CLI, SDK)    │
└───────────┬─────────────┘
            │
┌───────────▼─────────────┐
│  Validator Node          │
│  ┌────────┐ ┌─────────┐ │
│  │ gRPC   │→│ Mempool │ │
│  └────────┘ └────┬────┘ │
│              ┌───▼────┐  │
│              │Simplex  │  │
│              │BFT      │  │
│              └───┬────┘  │
│              ┌───▼────┐  │
│              │ State   │  │
│              └────────┘  │
└──────────────────────────┘

Shape Pairing Guide

When writing docs pages, assign shapes to H2s consistently within a page. The recommended cycle:

Position	Shape	Color	Typical meaning
1st H2	square	#00EEBE	Primary / main concept
2nd H2	circle	#7A3BF7	Secondary / supporting
3rd H2	triangle	#FA7CFA	Technical detail
4th H2	star	#FAD030	Configuration / options
5th H2	heart	#FE0302	Community / coda

For pages with more than 5 sections, pull from the extended shape set: diamond, hexagon, bolt, shield, sparkle, leaf, flame, etc.