IIPs (INTcoin Improvement Proposals) — what they are, where to find them, how to propose

Development
1

What’s an IIP?

An INTcoin Improvement Proposal (IIP) is the design document that records a change to the INTcoin protocol — consensus rules, P2P wire format, wallet format, RPC behaviour, or any other cross-implementation convention. The format is modelled on Bitcoin’s BIP system, scoped to INTcoin’s post-quantum architecture.

If you’ve read about Bitcoin’s BIPs (BIP-44 for HD wallets, BIP-125 for RBF, BIP-152 for compact blocks): IIPs play the same role for INTcoin.

Where they live

All IIPs live in their own repository:

Each IIP is a standalone Markdown file (iip-NNNN.md) with a YAML preamble declaring its number, title, type, layer, status, and any BIP it’s based on. The repo’s README.md indexes everything currently in flight.

Numbering ranges

  • 0001 / 0002 — Process IIPs (the meta-rules of the IIP system itself)
  • 0100–0199 — Consensus changes (block validation, difficulty, script)
  • 0200–0299 — Network protocol (P2P messages, transport, peer behaviour)
  • 0300–0399 — Wallet (HD derivation, address encoding, key management)
  • 0400–0499 — Application-level standards (PSTs, message signing, payment codes)

The ranges aren’t enforced — they’re a convention for finding things by topic.

Status flow

Every IIP moves through four stages:

  1. Proposed — initial draft submitted; soliciting feedback.
  2. Draft — actively being revised based on review.
  3. Draft Final — locked specification, awaiting implementation.
  4. Final — implemented, deployed, and immutable.

Once an IIP reaches Final, its body is permanently frozen. Any change requires a new IIP that explicitly supersedes the old one. The only allowed in-place edit on a Final IIP is adding a superseded-by: field pointing to its replacement. This is a hard rule — there’s no “just one small tweak” path.

Active IIPs (selected)

A few of the more visible ones — full list is in the repo README:

  • IIP-0102 — Replace-By-Fee (RBF) signalling, modelled on BIP-125
  • IIP-0117 — LWMA symmetric solvetime clamp (Final, lands in v1.0.6)
  • IIP-0118 — LWMA window 60 → 144 (Final, v1.0.6)
  • IIP-0119 — Per-retarget damping clamp ±30% (Final, v1.0.6)
  • IIP-0120 — Emergency min-difficulty fallback (Final, v1.0.6)
  • IIP-0201 — Compact block relay (modelled on BIP-152)
  • IIP-0203 — Block filter index for light clients (modelled on BIP-158)
  • IIP-0204 — Erlay transaction reconciliation
  • IIP-0301 — HD wallet derivation (SHA3-based)
  • IIP-0402 — Self-contained message signing
  • IIP-0403 — Transaction labels
  • IIP-0405 — Payment codes / stealth addresses

How to propose a new IIP

  1. Search first. Read the existing IIPs to make sure you’re not duplicating a proposal already in flight. The superseded-by: chain often surfaces history that informs new work.
  2. Open a discussion. Post in this category (Development), the #iip Discord channel, or open a draft issue on the IIP repo. Get rough consensus on whether the change is needed and how it should be scoped before writing the document. A well-discussed IIP gets through review faster than one written in isolation.
  3. Write the document. Use one of the existing IIPs as a template — the YAML preamble fields are the same across all of them. The body should cover:
    • Abstract — one paragraph summary
    • Motivation — why is this change needed?
    • Specification — exactly what changes? (Code, message format, RPC behaviour, etc.)
    • Rationale — why this design over alternatives?
    • Backwards Compatibility — does it break existing nodes? How is activation handled?
    • Reference Implementation — link to the patch or describe the pseudo-code
    • Test Vectors — concrete inputs/outputs that all implementations must agree on
  4. Submit a merge request to the IIP repo. The IIP starts in Proposed status. Reviewers will request changes; the IIP moves through Draft → Draft Final as it gets refined.
  5. Implement. The IIP becomes Final only after a working implementation lands in INTcoin Core’s main branch and is deployed in a release.

Why this matters

Consensus-changing decisions for a cryptocurrency are once-and-for-all. Getting them documented up front, with explicit motivation and rationale, means anyone reviewing a future PR or wondering “why is this rule like that?” has the answer in one place. The IIP system is the project’s institutional memory.

IIPs in flight: see the repo. Discussion: #iip Discord or this category.