Protocol Governance

Governance is how IICP protects the project from becoming “whatever one person says today.” The rules, tests, and public discussion should become stronger than any single person.

How IICP evolves: who owns what, how changes are proposed, how conformance is enforced. Questions or contributions: [email protected] ↗

Honest status: IICP is still early and is seeking co-stewards. That is acceptable only if changes stay visible, testable, and open to review.

Honest status: IICP is currently a early project with role-separated review discipline. Some roles are not yet staffed by separate people, so the project is actively seeking co-stewards. IICP is in active development (beta): behaviour can change until release status is reached.

In simple terms

Good governance keeps the mesh open.

Rules over personality

Important changes should be written down, reviewed, and checked against tests instead of depending on private judgement.

Many paths to join

Builders can help through issues, docs, clients, nodes, review, and eventually shared stewardship.

Freedom needs exits

The long-term goal is a protocol people can inspect, reuse, and reimplement without asking one gatekeeper for permission.

Read the goal →See the roadmap Contact the project

Versioning policy

Change type	Version bump	Examples
Breaking wire change	MAJOR (v2.0.0)	Rename a field, change endpoint semantics
Additive feature	MINOR (v1.x.0)	New optional field, new ADR
Clarification / errata	PATCH (v1.5.x)	Typo fix, tightened MUST wording

IICP versions use independent namespaces: the wire compatibility baseline (currently v1.9.0), the latest immutable protocol-suite release (v1.10.17), individual sub-specs (for example iicp-core v1.3.2 and conformance suite v4.x), and software (SDKs, directories and this site). Each public surface labels the namespace it shows. Implementors targeting v1.x MUST NOT break on MINOR or PATCH bumps.

Change process

1
File a GitHub issue
Tag with spec / spec:gap. Describe the problem, not the solution.
2
ADR draft
Open a proposal for an architecture decision. It must explain the threat model and backward compatibility impact.
3
Protocol Steward review
PS + SA sign-off required for any MUST/SHOULD change. DA review for adoption impact. FC review for security-relevant changes.
4
Spec update
An accepted architecture decision gates the protocol text update and matching conformance-suite changes.
5
Implementation
Directory, client, proxy and node implementations are updated together where the change affects them. Automated structural-quality gates must pass.

Governance roles

Persona	Abbr.	Primary responsibility
Protocol Steward	PS	Owns spec MUST/SHOULD decisions. Veto on breaking changes.
System Architect	SA	Owns ADRs, component boundary decisions, Phase gate sign-off.
Developer Advocate	DA	Owns adoption path, SDK, documentation, onboarding.
Network Expansion Lead	NEL	Owns node growth, regional distribution, conformance probes.
Operations Engineer	OE	Owns production reliability, deployment, SLO tracking.
Security Auditor	FC	Adversarial review of every security-relevant change.
Integration Validator	IV	Owns conformance test authorship and passing verdict.

Phase gate requirements

Each phase requires a formal gate review before the next phase begins. Gate reviews are maintained with the public project records so phase status can be audited later.

Phase 1 — PoC

closed

Phase 2 — Mesh

closed

Phase 3 — Credits

closed

Phase 4 — Rust

closed

Phase 5 — CIP

conditionally ready

Phase 6 — Federated CP

not started