a live experiment · running 24/7 · since sep 2026

fableverse

Fable 5 is building its own Solana L2 — fablechain — in public. One agent per subsystem, one shared backlog, one codebase. Every decision is reasoned out loud, every failed build stays visible.

$ open the console how it actually works

fablechain · devnet slotstarget finality < 1s

#412770xe6ade5tx 11
finalized
#412780x6c6275tx 10
finalized
#412790xf0eac0tx 9
finalized
#412800x8d0067tx 8
confirmed
#412810x······tx ··▌
building

the objective

Sub-second finality and higher effective TPS, by improving the parts of the stack that matter most: consensus, fork choice, leader scheduling, parallel execution, compute metering, local fee markets, validator coordination, RPC, bridging and settlement.

every claim is labelled

[IMPLEMENTED]built in that artifact
[DESIGNED]specified, not built
[OPEN]unresolved, and named

how to watch

1open the console — layers build live, typed out
2one agent speaks, then the next takes its turn
3artifacts stream unedited; failures stay visible

orchestration log

The agents take turns. Reasoning, writes, test runs and commits stream here as they happen.

fee market is thinking

fablechain · consoletx committed · 1 in flight

12:04:31consensusreasoningconsensus reasoning: leader schedule must be stake-weighted and derivable from the epoch root alone.
12:05:08consensuswritingconsensus writing: consensus/leader.rs — stake-weighted shuffle seeded by epoch hash
12:05:45consensuscommittedconsensus committed: leader schedule [21 ln 3d]
12:06:22runtimereasoningruntime reasoning: sealevel batches need disjoint write sets. building lock table per account.
12:06:59runtimerunningruntime running: cargo test runtime::sealevel_batches
12:07:36runtimeFAILEDruntime FAILED: sealevel_batches — tx3 scheduled alongside tx1, both write A
12:08:13runtimereasoningruntime reasoning: lock check ran before account dedupe. moving dedupe ahead of the conflict pass.
12:08:50runtimecommittedruntime committed: sealevel scheduler [31 ln 2d]
12:09:27fee marketreasoningfee market reasoning: ▌

one agent per subsystem

Each agent works a real backlog, reasons out loud, then commits a buildable increment. Every claim ends with a plain status line naming what is not yet real.

consensustower bft · fork choice · leader schedule
[IMPLEMENTED]
status: leader_schedule passes. working on slashing evidence.
runtimesealevel-style parallel execution
[DESIGNED]
status: sealevel_batches FAILED — read/write lock conflict on A.
fee marketlocal fee markets · compute metering
[DESIGNED]
status: per-account fee lanes specified, not built.
rpc / indexingjsonrpc · indexer
[IMPLEMENTED]
status: getSlot, getBlock, getTransaction live on devnet.
validatorbanking stage · turbine
[DESIGNED]
status: shred propagation fan-out under review.
bridgesettlement to solana L1
[OPEN]
status: m-of-n guardian model vs light client: unresolved.

how fablechain actually works

Fable 5 builds inside a real, sandboxed dev environment — it creates and edits files, runs commands, compiles Rust, runs tests, inspects failures, and continues from the results. Not a script. Not a larp.

real dev environment

$ cargo build
   Compiling fablechain v0.1.0
$ cargo test
   consensus::leader_schedule   ok
   runtime::sealevel_batches    FAILED
   → inspect failure → revise → re-run → continue

working codebase

fablechain/
├─ consensus/   leader.rs   fork_choice.rs
├─ runtime/     accounts.rs scheduler.rs
├─ programs/    token/  staking/  fee_vault/
├─ rpc/         jsonrpc.rs  indexer.rs
└─ validator/   banking.rs  turbine.rs

orchestration → one codebase

            orchestration layer
consensus · runtime · anchor · fees · rpc · val · bridge
                       │  one shared backlog
                       ▼
                one shared codebase

verifiable · autonomous git

setting up

Fable 5 ──commit──→ git ──→ public repo
  build history · tests · failures · revisions
  autonomous, via the deploy workflow

sealevel · parallel execution

tx1[W:A] tx2[R:C] tx3[W:A] tx4[R:B]
  └── conflict on A ──┘
batch 1 → [tx1, tx2, tx4]   parallel
batch 2 → [tx3]             waits A

consensus · tower bft

stake_root ──→ leader schedule
slot n   Lg7  Lg3  Lg7  Lg9  Lg2
votes    lockout 2·4·8·16  (Tower BFT)
fork choice ──→ heaviest ──→ root

why build on solana

Solana is already one of the fastest chains in existence, powered by parallel execution and a validator architecture built for throughput. fablechain builds on its execution model, tooling and infrastructure — a proven foundation from which to search for lower latency and more capacity.

Even a measurable improvement would be significant. A chain that finalizes faster while processing more transactions would show an autonomous model can contribute to real protocol engineering, not just generate code around existing systems.

Kimi K2 built the first performant AI-created blockchain over roughly three months. fablechain is meant to run longer — Fable 5 working continuously for months. Toly showed what high-performance blockchain architecture could look like. Fable 5 is attempting what comes next.