ICN is institutional infrastructure with a real codebase behind it.

Your first hour in the repo

Why ICN may be interesting to technical readers

• Kernel/app separation with a strict meaning firewall. The kernel enforces generic constraints without understanding their domain semantics. Apps translate domain meaning into those constraints. The boundary is enforced in the crate graph.
• Trust-native, not trustless. ICN is built around trust as a first-class, measurable, auditable property — not around the assumption that trust can be eliminated.
• Mutual-credit accounting rather than token economics. The economic layer is relational: obligations between named parties, settled institutionally, not a market instrument.
• Actor-based runtime over Tokio, with explicit supervision, shutdown, and message-passing between subsystems.
• Cryptographic identity for members, cooperatives, communities, and federations, with an Age-encrypted keystore and explicit key rotation paths.
• An honest repository. The project is unusually direct about what is real, what is being built, and what is still unfinished.

What kind of system this is, technically

ICN is a daemon (icnd) implemented in Rust, running as a peer in a network of other ICN nodes. It is not a blockchain. There is no global consensus layer, no token, no mining. It is not a client-server application. There is no central service that nodes report to.

Nodes communicate over QUIC/TLS with cryptographic identity bound to the transport layer. Between nodes, the main coordination primitives are topic-based gossip with causal ordering, signed envelopes with replay protection, a mutual-credit ledger of obligations between parties, and policy oracles — app-level components that translate domain decisions (governance, trust, membership) into generic constraints the kernel can enforce without understanding the domain.

Inside a node, the runtime is an actor system: the supervisor spawns long-lived actors for the network, gossip, ledger, and related subsystems, and wires them together through message passing and typed callbacks. State is persisted through sled-backed storage; cryptographic material lives in an Age-encrypted keystore.

Core architectural ideas worth knowing before reading the code

• The meaning firewall. Kernel crates enforce constraints; app crates supply meaning. The kernel is not allowed to understand what a "trust score" or a "cooperative" is. The boundary is enforced in the crate graph itself, not as a design aspiration.
• Policy oracles. An app that implements the PolicyOracle interface is the bridge between domain semantics and kernel enforcement. The trust oracle is the canonical example.
• The governance executor. A kernel-dispatch bridge between accepted governance payloads and the subsystems that carry them into operational effect. Expanding the set of payload types it dispatches is one of the main areas of active work.
• Scopes as first-class institutions. A member, a cooperative, a community, a federation, and a commons are each modeled as a distinct scope. Each has its own crate in the workspace.
• Actors and supervision. The runtime is built around long-lived actors managed by a supervisor, communicating through message passing.
• Trust-gated rate limiting and placement. Trust class affects message rate limits, credit relationships, and task placement. Trust is native, not trustless.
• Signed envelopes and replay guards. All messages between nodes are signed and replay-protected; verification happens in the network actor before messages reach the rest of the system.
• Federation as treaty. The federation crate carries formal agreements, attestations, typed inter-institutional channels, and cross-scope clearing — not just message relay.
• Commons and compute. Shared infrastructure with trust-aware placement, checkpointing, cross-participant clearing, and dispute resolution — participating in the same institutional loop as governance and accounting.

1. 01

   Identity Cryptographic identity held by the member — not a platform account.
   ↓
2. 02

   Standing Provable participation inside a scope. The institution can verify it directly.
   ↓
3. 03

   Authority Derived from scope rules and the decisions members have made under them.
   ↓
4. 04

   Governance Proposals, deliberation, and decisions the institution will honor.
   ↓
5. 05

   Policy Shared rules produced by decisions, shaping what can happen next.
   ↓
6. 06

   Accounting Obligations, treasury, patronage, mutual-credit positions — governed social accounting.
   ↓
7. 07

   Execution Where accepted decisions translate into real operational effect.
   ↓
8. 08

   Receipts & Provenance The chain from authority to outcome — durable, auditable institutional memory.
   ↓
9. 09

   Member Experience Where all of the above becomes something a person can see, use, and live in.

Subsystems that exist but are not yet publicly described

Some parts of the codebase are real but we are not yet willing to carry them on the public narrative pages — either because their public surfaces are thin, or because we are not ready to describe them in a way we can stand behind. Technical readers looking at the workspace will see them, so we name them here honestly:

• icn-privacy — privacy primitives as a dedicated crate. Real code, no polished public framing yet.
• icn-zkp — zero-knowledge proof components. Real code, limited public narrative.
• icn-steward — a steward network for trust distribution and integrity. Real implementation, deliberately absent from public pages until we can describe it without overclaim.

If you are evaluating ICN as a system and any of these matter to your work, read the crates directly rather than waiting for the public story to catch up.

Where the current implementation is strongest

ICN's strongest technical through-line today is the part of the system that connects governance to durable, auditable records. The primitives for cryptographic identity, signed messages, provenance, and receipts are mature and load-bearing. The paths from decision to recorded outcome are where the most implementation work has gone.

Core kernel subsystems — the actor runtime, network transport, gossip, identity primitives, storage, and the meaning-firewall boundary between kernel and apps — are in place and integrated. The trust policy oracle is a working example of the kernel/app pattern and is the reference implementation to read first if you want to understand how the separation is meant to work.

Where active work is happening

• Execution coverage. Expanding the range of decisions that translate cleanly into concrete operational effect.
• Policy mechanisms. The breadth of governance patterns an app can express, and the fidelity with which policy oracles can translate them into kernel-enforceable constraints.
• Federation. The federation crate and the coordination protocols between scopes are real, but integrations across adjacent subsystems are still being completed.
• Commons and compute. The distributed compute layer with trust-gated task placement exists and is serious, but the surfaces that would let external readers evaluate it are underdeveloped.
• The gateway and member-facing APIs. The REST and WebSocket surfaces that would let ordinary members interact with a scope are the part of the system most visibly trailing the substrate underneath.

How to explore the codebase and docs

The main monorepo is at InterCooperative-Network/icn. The Rust workspace lives under icn/ inside the repo, with crates in icn/crates/, apps in icn/apps/, and binaries in icn/bins/.

A reasonable reading order for someone new:

1. Start with the architecture reference for the structural model.
2. Read the trust policy oracle as the canonical example of how an app translates domain semantics into generic constraints.
3. Read the supervisor and runtime (icn-core) to see how actors are spawned, wired, and shut down.
4. Read the network actor (icn-net) and the gossip actor (icn-gossip) to see how inter-node communication works.
5. Read the ledger (icn-ledger) to see how mutual-credit accounting is carried as a replicated journal.
6. Read the governance app to see how proposals, decisions, and the transition from governance to policy are handled today.

If you want to contribute now

The shortest path to a truthful first contribution is: orient on the public framing, build the workspace locally, choose one scoped issue, and verify only the checks that match the area you touched.

• Start with the contributor entry docs. Read Getting Started, then README.md, then CONTRIBUTING.md.
• Use the onboarding curriculum when you want a deeper path. The full developer ladder is in docs/onboarding/README.md.
• Choose a first area deliberately. Start with good first issues or with one documentation gap you can close cleanly.
• Run from the right directory. Cargo commands belong in icn/, not the repo root. That one detail prevents a surprising amount of confusion.
• Use the public contribution map if you are deciding how to help. Get Involved is the route map for code, docs, design, institutional input, and financial support.

How to contribute without misunderstanding the project

• ICN is institutional infrastructure, not a protocol in search of a use case. Contributions that treat it as a generic substrate for arbitrary coordination tend to miss the point.
• The kernel/app separation is load-bearing. Contributions that erode the meaning firewall will be reverted.
• Trust is native, not trustless. Designs that assume trust can be eliminated will not fit.
• Honesty about maturity is a project value. Contributions that overclaim — PRs whose descriptions suggest a feature is complete when it is only partially wired — will not land.
• Scope discipline matters. Small, focused contributions against a clearly scoped issue are the path of least resistance.

What ICN is not, technically

• Not a blockchain. No global consensus, no token, no mining.
• Not a DAO framework. Governance is one part of a larger substrate, not voting over a treasury.
• Not a federated social platform. Federation is about institutional coordination, not content distribution.
• Not a general-purpose smart contract platform. CCL is domain-scoped, deterministic, fuel-metered, and not Turing-complete.
• Not finished. ICN is real and active, but not mature. See What's Real Now.