Challenge
Building a blockchain platform from the ground up means understanding many building blocks at once and being honest about their maturity: network layer, consensus, cryptography, storage, observability, operations. At every one of these layers, it is easy to have “green” test runs and still be far from a production-ready state.
For Quantix, the actual challenge was therefore not standing up a new chain quickly, but dealing honestly with what actually works. Until the internal audit of 29 August 2026, the repository contained more than three hundred reports with titles like “Production Ready” or “95/100” — statements that an independent look at the code did not confirm. The task was therefore to move all of those reports into an archive, condense the real state into a single status section and name the open stop-issues clearly.
Approach
Five principles:
- Real libraries over stubs — libp2p for the P2P network and Cloudflare CIRCL for Dilithium, not homegrown replacements.
- One single valid status section — all older “done” reports move into an archive (
docs/archive/2026-02/); only the current status section describes the state of the system. - Verifiable claims — every statement in the status section comes with a command (
go build ./... && go vet ./... && go test ./...) or a module reference readers can check themselves. - Open stop-issues — reasons against production use are named explicitly rather than hidden behind milestone language.
- Separate trust contexts — security decisions (JWT, emission, signature verification) are written out in the repository so the next changes cannot silently weaken them.
What we built
Blockchain node in Go (apps/backend/quantix-blockchain/, cmd/, internal/)
A Go node with mempool, block production and sync loop (init_sync.go, sync_loop.go). The root module github.com/quantix/core builds and vets without errors; tests of the root module are green in nine packages (apps/backend, .../quantix-datacenter-integration, .../quantix-payment-gateway, .../quantix-security-access, internal/security, src/apps/backend/api-gateway, tests/integration, tests/load, tests/mempool). Current test count per audit: 156 of 171 passing.
Real P2P network (p2p_*.go)
Not a mock: github.com/libp2p/go-libp2p v0.43.0 plus go-libp2p-kad-dht v0.35.1 and go-libp2p-pubsub v0.15.0 form the network layer. Kad-DHT provides peer discovery, PubSub gossips blocks and transactions.
Post-quantum signatures (shared/security/post-quantum/, internal/security/)
CRYSTALS-Dilithium in modes 2, 3 and 5 through github.com/cloudflare/circl (sign/dilithium/mode2|3|5). Used in pqc_manager_dilithium.go and internal/security/manager.go. Kyber and SPHINCS+ live in the same directory but are currently stubs — openly marked as such in the status section.
Backend services (services/, apps/, microservices/)
Several Go services behind a common API gateway (src/apps/backend/api-gateway/): datacenter integration, payment gateway, security access. Each service has its own tests and its own deployment recipe.
Data layer and operations (postgres-*, migrations/, patroni/, pgbouncer/)
PostgreSQL as the core database with migration and backup tooling (postgres-backup-encrypted/, postgres-backup-verification/). Patroni and PgBouncer cover the HA path. prometheus/, monitoring/ and nginx/ provide observability and reverse-proxy.
Web console and desktop packaging (frontend-explorer/, packages/, apps/)
Web console and block explorer in React/TypeScript. Desktop delivery uses a Tauri packaging path (see DESKTOP_CLIENT_INTEGRATION_PLAN.md).
Tidied documentation
All historical “Production Ready” reports were moved into docs/archive/2026-02/. The current status section in the README is the only valid source. docs/SECURITY-ROTATION.md describes the order in which the exposed secrets need to be rotated.
Architecture
Quantix follows a classic split: chain and environment. The chain itself consists of a Go node with mempool, block production, state storage and network layer. Around it sits an environment of backend services, web console and operations tooling that does not change chain logic but controls access to it.
The network layer is based on libp2p: Kad-DHT provides peer discovery, PubSub distributes blocks and transactions. Choosing real, maintained libraries was one of the audit’s deliberate decisions — no home-grown, no mock on the production path.
Cryptography relies on CRYSTALS-Dilithium (via Cloudflare CIRCL) for post-quantum-capable signatures. Further post-quantum schemes (Kyber, SPHINCS+) are scaffolded but openly marked as stubs in the current status section.
The API gateway (src/apps/backend/api-gateway/) bundles requests to several backend services. Observability runs through Prometheus and Grafana; PostgreSQL forms the core database, complemented by Patroni and PgBouncer.
The status section in the README is the most important architectural component of this case study. It names seven open stop-issues explicitly — including missing authorisation on the node’s HTTP API, unrestricted emission through a special account, incomplete consensus mechanisms (PBFT fails all 8 tests; PoS and DPoS do not collect votes), a single JWT secret spanning two trust contexts, and secrets remaining in git history whose rotation is described in docs/SECURITY-ROTATION.md.
Numbers & facts
| Metric | Value |
|---|---|
| Chain language | Go 1.24 (root module github.com/quantix/core) |
| P2P network | libp2p v0.43.0 · Kad-DHT v0.35.1 · PubSub v0.15.0 |
| Signatures | CRYSTALS-Dilithium (modes 2/3/5) via Cloudflare CIRCL |
| Data layer | PostgreSQL · Patroni · PgBouncer · Redis · NATS |
| Observability | Prometheus · Grafana · nginx |
| Web / desktop | React + TypeScript · Tauri packaging |
| Tests | 156 of 171 passing per audit of 29 Aug 2026 |
| Maturity | Experimental — seven open stop-issues named in the README |
What we learned
Honest status statements break momentum but earn trust. One single valid status section is more valuable than three hundred “done” reports. New contributors and external reviewers immediately know what they can rely on — and what not.
Stubs in security code are a time bomb. Kyber and SPHINCS+ as stubs in the same directory as a real Dilithium manager are dangerous unless clearly marked. The status section names both, so nobody accidentally promotes them into a production path.
Secret rotation has its own choreography. Values that once sat in a git history are there forever in every clone. docs/SECURITY-ROTATION.md describes the necessary steps: two separate JWT secrets for the auth service and the node, rotation of all compromised values, history rewrite by the owners.
Consensus is its own project. PBFT tests failing across the board and PoS/DPoS without any vote collection show it: consensus does not belong as a side effect of a “blockchain framework”. It needs its own iterations with its own test pyramid.
Next steps
- Tackle consensus mechanisms (PBFT, PoS, DPoS) as an independent iteration, starting from a reproducible test setup.
- Put the node’s HTTP API behind authorisation and split the shared
JWT_SECRETintoAUTH_JWT_SECRETandNODE_JWT_SECRET. - Remove unrestricted emission through the special account; make signature verification bypass-proof (no substring matching).
- Either replace Kyber and SPHINCS+ with real implementations or remove them and mark the directory accordingly.
Related
- Context: About Alpine Ascent — Quantix reflects our openness to experimental platforms with honest status documentation.