Constitutional Genesis

This document defines the immutable substrate of the Intercooperative Network: what cannot be changed by governance, what can, and how the system bootstraps from nothing into a governed cooperative.

Foundation: The Constraint Engine

ICN is a constraint engine. Applications translate meaning into constraints; the kernel enforces constraints without understanding meaning. This separation is the architectural foundation of everything that follows.

The kernel sees ConstraintSet values: rate limits, topic caps, message size bounds, and opaque custom fields. It never sees trust scores, membership tiers, or governance roles. That boundary — the meaning firewall — is itself an immutable invariant.

Hard Invariants

Hard invariants are substrate mechanics. Governance cannot remove them. They define what ICN is rather than how it is configured.

Frozen-Core Invariants

The kernel recognizes 10 frozen-core invariants, organized into three domains. These are defined in icn-kernel-api/src/invariants.rs as InvariantId. The kernel verifies attestation presence, format, and hash linkage for these invariants — it never evaluates the predicates themselves. Predicate evaluation lives in the governance app layer (InvariantGate).

Sovereignty Core (Consent and Exit)

Anti-Capture Core (Power and Governance)

Economic Core

Enforcement Mechanisms (Hard Invariants)

Beyond the frozen-core governance invariants, the substrate enforces these structural mechanics. Governance can change the values fed into these mechanisms but cannot remove the mechanisms themselves.

The Critical Distinction

If governance could remove enforcement mechanisms, there would be no stable substrate.

Meta-Invariants

Meta-invariants are constraint values that governance can change through the PolicyOracle pattern. Apps translate domain semantics into ConstraintSet fields; the kernel enforces those fields blindly.

The Meaning Firewall Boundary

Each PolicyOracle converts domain-specific knowledge into generic constraints:

TrustPolicyOracle:
  trust_score(0.85) → ConstraintSet { rate_limit: 200/s, custom: { credit_multiplier: 0.85 } }

GovernancePolicyOracle:
  protocol_params → ConstraintSet { rate_limit: N, custom: { resource_quota: M } }

LedgerPolicyOracle:
  account_state → ConstraintSet { custom: { credit_ceiling: K } }

The kernel receives ConstraintSet. It enforces rate limits, topic caps, and opaque custom fields. It never knows these values came from trust scores or governance parameters.

Bootstrap Sequence

A new ICN node starts from nothing and transitions through three phases before reaching normal operation.

Phase 1: Genesis

The daemon loads configuration, unlocks the keystore, and enters the Genesis bootstrap phase.

What happens:

1. Configuration loaded from icn.toml
2. Identity bundle loaded or generated from age-encrypted keystore
3. AllowAllOracle is active — all operations are permitted
4. Genesis capabilities can be issued (time-limited, phase-guarded)
5. Trust service initializes with empty trust graph
6. Ledger initializes with empty state
7. Governance service initializes with default protocol parameters

What this means: During Genesis, the node has no trust relationships, no credit history, and no governance structure. The AllowAllOracle permits bootstrap operations that would otherwise be denied.

Phase 2: CoreApps

First-party applications load and register their PolicyOracles.

What happens:

1. Trust oracle registers with the PolicyOracle registry
2. Governance oracle registers
3. Ledger oracle registers
4. Genesis capabilities remain valid but will expire
5. Missing oracles still default to allow (bootstrap flexibility)

What this means: The system is transitioning from permissive to enforced. Apps are loading their domain-specific authorization logic.

Phase 3: Running

Normal operation begins. The system transitions to deny-by-default for unknown domains.

What happens:

1. Genesis capabilities expire
2. AllowAllOracle is replaced by registered domain oracles
3. Unknown domains receive PolicyDecision::Deny (not allow)
4. All frozen-core invariants are actively enforced
5. Gossip synchronization begins
6. Network actors accept peer connections

What this means: The cooperative is live. Every operation is authorized by a PolicyOracle or denied. The substrate enforces constraints without understanding their semantic origin.

Genesis Identity

The first identity is created during node initialization:

1. icnctl id init generates an Ed25519 keypair
2. DID is derived: did:icn:<base58-pubkey>
3. Private key is stored in age-encrypted keystore at ~/.icn/keystore.age
4. X25519 key is derived for TLS binding
5. The identity can be exported at any time via icnctl id export

Genesis Trust

Initial trust is seeded explicitly. There is no implicit trust:

1. First node starts with an empty trust graph
2. Trust edges are added via explicit peer connections
3. Trust scores are computed transitively from direct edges
4. The genesis trust configuration is auditable and replaceable

Genesis Treasury

The initial credit pool is created through the ledger:

1. Ledger starts with no accounts and no balances
2. Genesis credit issuance follows double-entry rules (credit creates matching debit)
3. The zero-sum invariant holds from the first transaction
4. Treasury policy is a meta-invariant — governance can change distribution rules

Exit and Fork Rights

ICN guarantees data sovereignty. Members can always leave and take their data.

What Members Can Export

What Cannot Be Taken

• Trust edges received from others (those belong to the issuer)
• Governance votes cast by other members
• Credit balances owed by others (the obligation is bilateral)

Fork Rights

Because identity is self-sovereign (DID derived from public key, private key in member's keystore), a member can:

1. Export their identity
2. Export their authored ledger entries
3. Start a new node with the same identity
4. Establish new trust relationships independently

There is no administrator who can revoke a DID or freeze an account. The Sovereign Signature Requirement (invariant #9) guarantees that funds move only via owner signature or pre-consented dispute hooks.

Invariant Enforcement Table

Governance Decision Flow

When governance changes a meta-invariant:

1. Proposal created — governance app receives a proposal to change parameter values
2. Invariant check — an InvariantReport is generated, attesting that all 10 frozen-core invariants are preserved by the proposed change
3. Voting — members vote according to the current voting method (itself a meta-invariant)
4. Execution — the governance decision flows through the effect dispatcher to the ProtocolParameterStore
5. Observable change — PolicyOracles re-evaluate with new parameter values; constraint values change dynamically

The kernel participates in steps 2 (verifying attestation format and hash linkage) and 5 (enforcing the new constraint values). It never evaluates the predicates themselves.

Summary

ICN's constitutional foundation rests on a clear separation:

• Hard invariants define what the substrate is. They cannot be removed by governance. They are enforced by code, validated by tests, and observed by metrics.
• Meta-invariants define how the substrate is configured. They are set by PolicyOracles, changed by governance decisions, and enforced blindly by the kernel.
• The meaning firewall separates the two. Domain semantics stay in apps. The kernel sees only constraints.

A cooperative built on ICN inherits these guarantees: members can always exit, credit always balances, power changes are always visible, and the substrate cannot be captured by changing its configuration.