A zero‑leader, zero‑round, phone‑grade ledger that grows naturally out of encrypted “group‑chat storms.”
This design fuses three things that have never been glued together:
1. E2E‑encrypted group chat as the only transport.
2. Chaotic address hopping so every message’s destination set is unpredictable — yet verifiable after the fact.
3. Ledger = transcript consensus: instead of agreeing on blocks, nodes agree on an exact chat transcript they all witnessed.
If the transcript lines up, the state lines up. No transcript, no state.
—
1 How it breathes
phones group‑IDs live ≤ 15 min
┌──────┐ hop ─┐
│ Bob │◀───────┼────────────────┐
└──────┘ hop ─┘ ▼
┌────────┐
│ G‑7A42 │ (Telegram/Matrix/Signal…)
┌──────┐ hop ─┐ └────────┘
│ Alice│◀───────┤
└──────┘ ▼
┌────────┐
│ G‑F91C │
└────────┘
Every phone maintains 64 short‑lived group chats (across ≥ 3 different public messaging platforms).
Every 30 seconds it hashes local entropy + last chat root ⇒ next 64 group IDs (pseudo‑random, deterministic, uninfluenceable).
It secretly creates or joins those groups; each contains ≈ 15 devices, ≈ 50 % overlap with every other phone’s set.
These rapidly rotating groups are our “chaotic rooms.”
No single adversary can predict which rooms honest nodes will share in the next minute.
—
2 Submitting a transaction
1. Wallet signs a tx.
2. Phone posts that tx verbatim to all its current rooms.
3. Each room is an ordered chat log; the platform’s own server stamps a monotonic timestamp & message index.
That’s it—no rounds, no leaders, no votes.
—
3 When is a tx final?
> Rule of 2 + ε –
A tx is final when you can present two distinct room‑logs whose platform‑assigned indices prove the same tx appears earlier than any conflicting tx in both rooms.
Why it’s safe (sketch):
If ≤ ⅓ of the rooms you share can be censored or forked, the remaining ≥ ⅔ honest logs lock the relative order.
Two honest, non‑forgeable server indices → can’t both be rolled back without colluding chat servers.
Because rooms hop so fast, an attacker can’t know which two honest logs a victim will rely on.
—
4 Byzantine tolerance & threat model
Requires: at least two honest, independent chat infrastructures (e.g., Matrix + Signal federation).
If N platforms exist, system tolerates N‑2 fully malicious ones.
—
5 Resource footprint
CPU – verify two server signatures per tx, negligible (< 200 µs).
Data – your own tx posted 64×; but each room is tiny → ∼ 15 kB uplink per tx.
Storage – keep last 24 h of room logs (compressed JSON) ≈ 100 MB, then prune.
Battery – chat idle polling already optimised by apps; additional load ≈ +3 %/h during heavy use.
Everything a modern budget phone can stomach.
—
6 Why this is new
All existing ledgers bolt consensus directly to the p2p layer.
CC‑Ledger instead outsources ordering to multiple untrusted chat servers and derives safety from their disagreement.
No blocks, no committees, no DAGs—just a stitched transcript of chaotic chat rooms.
I’ve found no academic or industrial system that:
Rotates multicast groups every few seconds across different public chat backbones.
Uses the product of independent server indices as a BFT ordering oracle.
Achieves finality with just 2 verified chat logs (constant work, constant size).
—
7 Next steps if the spark feels right
1. Spike a prototype: 300 lines of Python using Matrix + Telegram bots; publish/collect logs, run the Rule‑of‑2 validator.
2. Chaos metrics: measure overlap probability and log‑agreement latency on 30 phones.
3. Cryptographic hardening: require servers to supply batch VK proofs of log order (simple when indices already signed).
4. Wrap it as a Kotlin library so Aqua‑lite or any dApp can ask: is_final(tx_id)?.
If this chat‑born ledger still isn’t strange enough, shout—and we’ll poke a deeper corner of chaos until something truly alien pops out.