Project state

What's real now.

ICN's subsystems are at very different stages. This page states which ones are load-bearing, which are still moving, and — just as importantly — what kind of evidence sits behind each claim. Every other page on this site should be readable against this one without contradiction.

Subsystem data verified Generated from docs/status.toml at build time.
Narrative last reviewed The written framing on this page, re-read against the data above.

How to read this page

Every claim carries two labels, because "how far along is it" and "how do we know" are different questions. Collapsing them is how a merged pull request quietly becomes a promise.

Maturity — how far along it is

Strong today

Implemented, integrated, and load-bearing. Capabilities we are prepared to stand behind in public.

Advancing now

Actively under development with visible progress. Real, not yet reliable enough to lean on.

Real but maturing

Serious implementation exists. Surfaces, integrations, or verification are still being finished.

Not yet

Scaffolding exists; the capability does not. We would rather say that than imply a schedule.

Evidence — how we know

A capability can be well-built and thinly evidenced at the same time. This axis says which it is.

  • Test-backed Exercised by the automated test suite in this repository.
  • Fixture-backed Demonstrated against deterministic fixture data, not live institutional use.
  • Reviewed Established by reading the implementation, not by an automated check.
What none of these mean

None of the evidence classes above means a capability has been run by an institution in ordinary use. ICN has no production deployment claim, and activity in the repository is not a readiness signal.

Subsystems

Generated from the repository's own state file. The gap column is the project's own record of what is missing — it is published rather than summarised because a maturity claim without its gaps is marketing.

Per-subsystem maturity and evidence, generated from docs/status.toml. Each row lists the subsystem, its maturity band, what kind of evidence backs the claim, the date it was last verified, and the gaps the project records against it.
Subsystem Maturity Evidence Verified Recorded gaps
Economics (Mutual Credit Ledger) icn-ledger, apps/ledger strong today Test-backed — Exercised by the automated test suite in this repository.
  • Commons credit formula hardcoded in Rust, not in CCL (#1308) — icn-ledger/src/commons_credits.rs:77,224
  • Terminology rename (#1303) has LANDED on the enforced public surface (gateway /position, /settle, positions/unit wire fields); icn-ledger internals, FX CurrencyPair and labor_shares BondPayment are deliberately out of scope per docs/dev/language-guide.md:200-204. Note the compliance linter checks a narrow named-pattern list, so zero violations is weaker than rename complete
  • A cooperative carries two mutually inconsistent treasury identifiers (lifecycle.rs:22 vs actor.rs:489), neither keypair-backed
Entity Model icn-entity, icn-coop, icn-community strong today Test-backed — Exercised by the automated test suite in this repository.
  • Two evidence capabilities are carried by crates outside the declared list (bounded alias resolution -> icn-kernel-api)
  • icn-entity does not itself derive or validate treasury identifiers; treasury_account is caller-supplied (entity.rs:462,628)
Governance icn-governance, apps/governance strong today Fixture-backed — Demonstrated against deterministic fixture data, not live institutional use.
  • Proposal authorship diverges by deployment mode: manager.rs:3480 accepts a proposer DID but the actor-backed branch (:3486-3497) never passes it, and actor.rs:1926 stamps the NODE DID as proposer; the in-process fallback (:3512) uses the caller
  • Stored and replicated votes are not independently verifiable: Vote carries no signature field (vote.rs:23-41), so a third party cannot check authorship from the record alone — this is the hole verify.rs:24 disclaims. NOTE the REST boundary IS authenticated: CastVoteRequest has no voter field (models.rs:365-368) and the handler derives the voter solely from claims.sub (http/handlers.rs:1818-1822); the unconstrained voter parameter is on the internal actor command, not reachable with an arbitrary DID over REST
  • Voting-model coverage is unquantified — no VotingModel/TallyMethod enum exists, so the prior 3-of-7 framing had no source referent
  • Charter starter templates exist as docs (docs/reference/ccl-charter-templates.md) but are not shipped as loadable in-repo coop/community defaults
Identity & Cryptography icn-identity, icn-crypto-pq, icn-steward, icn-zkp strong today Test-backed — Exercised by the automated test suite in this repository.
  • HSM/PKCS#11 custody is non-functional scaffolding — every operation bails (keystore_pkcs11.rs:3,133)
  • TPM backend seals at rest but signs in SOFTWARE after unseal (keystore_tpm.rs:4-5,868) — not hardware-held signing
  • Per-device capability model is declared but unenforced: DidDocument::can_sign (multi_device.rs:308) has zero production callers and Capability::Sign is read nowhere outside icn-identity
Network & Transport icn-net, icn-gossip strong today Fixture-backed — Demonstrated against deterministic fixture data, not live institutional use.
  • NAT traversal completeness NOT ESTABLISHED under real-world NAT: STUN/TURN/relay are built and wired (stun.rs, turn.rs, nat.rs, relay_proxy.rs; session.rs:250,:311) and a direct public-address dial path described in-source as NAT hole punch is raced via Happy Eyeballs with relay fallback (icn-core/src/supervisor/nat_dial.rs:7,:162-239, fed by init_notifications.rs:444-492) — what is missing is validation of that flow against symmetric/port-restricted NATs, not the capability itself
  • docs/design/nat-traversal-design.md is stale — still marked Design Phase with shipped STUN/TURN work unchecked
Security & Privacy icn-net, icn-crypto, icn-security, icn-privacy strong today Test-backed — Exercised by the automated test suite in this repository.
  • Onion routing inbound/relay path is wired, but NO production code originates onion traffic — send_onion_message (icn-net/src/actor/mod.rs:982) has zero callers; anonymity threat model still NEEDS SME REVIEW (not audited for traffic analysis)
  • Traffic obfuscation / cover traffic is BUILT at crate level (icn-privacy/src/traffic_obfuscation.rs, 385 lines) but NOT integrated into icn-net — only tests consume it
Contract Execution (CCL) icn-ccl advancing now Test-backed — Exercised by the automated test suite in this repository.
  • No pre-built contract library for common cooperative patterns
  • No prose-charter-to-CCL-rules translation pipeline (charter_rules.rs/charter_validator.rs DO evaluate charter rules as CCL AST; the authoring step is what is missing)
  • Commons credit formula not extracted to CCL (#1308)
  • CCL requires programming expertise (non-programmer interface missing)
Federation icn-federation real but maturing Reviewed — Established by reading the implementation, not by an automated check.
  • Three-epoch checkpoint system NOT BUILT (no checkpoint/epoch types in crate)
  • Partition healing NOT BUILT IN icn-federation (eventual via gossip only; icn-core has partition_healing_multistate_integration.rs)
  • Byzantine fault tolerance NOT IMPLEMENTED IN icn-federation (icn-core has byzantine_integration.rs)
  • Cross-federation async proof exchange NOT SPECIFIED
  • Multilateral netting is fully built INCLUDING the apply step: NettingEngine (netting.rs:44) computes cycles via perform_multilateral_netting (clearing_manager.rs:414-420, informational, :412), and apply_multilateral_netting (clearing_manager.rs:472-535) updates and persists positions; both are exposed as gateway endpoints (api/federation.rs:1140,:1177-1190, registered server.rs:2534-2535). The prior 'NOT BUILT' gap was wrong and the interim 'does not settle' wording was also wrong
  • Federation attestation signing is not installed in production (see evidence) — announcements and issued attestations are unsigned
  • Inter-org dispute-resolution engine NOT BUILT (agreements carry only an Option<String> method label)
Storage (DAG) icn-store, icn-snapshot real but maturing Reviewed — Established by reading the implementation, not by an automated check.
  • Three-tier storage (Hot/Warm/Cold) not implemented
  • Archive cooperative compensation not built
  • Node class differentiation not implemented
Distributed Compute icn-compute not yet Reviewed — Established by reading the implementation, not by an automated check.
  • WASM fuel metering NOT enforced and WASM host imports are non-deterministic (wall clock) — wasm_executor.rs:58-59,:163,:211,:248
  • E3 advisory-cannot-mutate IS enforced on the CCL mutation path (interpreter.rs:608-618 rejects via context.can_mutate_state(), with determinism_class mapped in at executor.rs:124-140); what remains unverified is enforcement on the WASM path, which is unmetered and non-deterministic
  • Job marketplace with bidding NOT BUILT (no Bid/auction type; scheduler.rs:983 only anticipates it in a doc comment)
  • Cell operator boundary DEFINED in kernel API (E5) but runtime enforcement NOT VERIFIED — can_join_cell defaults to permissive when a cell has no operator mode set

10 subsystems, generated from docs/status.toml. Some parts of ICN — membership, receipts and provenance, the member-facing shell, and the rehearsal appliance — do not have a row in that file and so do not appear above. They are covered in the narrative below, and that difference is itself worth knowing: the machine-readable record does not yet cover everything the project talks about.

What the table does not say

The bounded thing that actually runs

The current bounded wedge is the Rehearsal Node: a self-contained, non-production appliance that runs one governed loop end to end. An organizer reviews, edits, assigns, previews, and digest-bound-confirms a piece of proposed work; a member completes it. Both decision points are recorded as durable process receipts, and the run exports a secret-free evidence summary.

That loop has been witnessed on an assembled image. It is deliberately bounded — unsigned, non-production — and the human gates are still open: a real organizer walkthrough and a human assistive-technology pass have not happened. Rehearsal before belief. No organizer approval and no pilot commitment is claimed.

Where the implementation is ahead of the interface

The strongest part of ICN is the chain that carries an outcome back through the rule that shaped it, the decision that authorized it, and the standing that made action legitimate. The weakest part is the surface an ordinary member would use to see any of that. The gap between those two is the single most honest thing to know about the project right now.

Federation is the other place worth naming directly. It is a serious subsystem with real implementation behind it, and no two cooperatives are federating over ICN in ordinary use. Peer connectivity is not federation, and a local fixture is not a federation either.

What has no row in the table at all

Privacy, zero-knowledge proofs, steward networks, and post-quantum cryptography exist as dedicated subsystems or source-level primitives. Their runtime integration and member-facing role are not verified, so they get no public capability claim here.

There is design direction for governed services, service identities, tool manifests, and institution-owned tool state. Design direction is not implemented service hosting, and this page will not let the two blur.

What this page commits to

Every capability claim elsewhere on this site belongs in one of the maturity bands above and carries one of the evidence classes. If something reads as more finished on another page than it does here, this page is right and the other page is a defect worth reporting.

Recent state changes

Meaningful changes that landed and were reviewed — not a commit feed. An entry here means something changed and someone reviewed it. It does not mean a capability became usable; that question is answered by the table above.

  1. Capability Bind a fresh Subject inception to a governance-domain context #2797 ↗

Newest entry 2026-09-15. Selected from the last 400 commits: only reviewed, merged changes whose type corresponds to a change in what the project does — new behaviour, corrections, hardening, recorded decisions, and re-verifications of this page's own source data.

Check any of this directly