Fast finality is not proof of independence. We have not found a generally applicable, independently reproducible basis for treating a low finality number as evidence that a network is operationally independent. Finality describes how quickly a network reaches a decision; it does not, by itself, reveal who can verify that decision, who controls upgrades, where the infrastructure runs, or whether users can leave without permission.
IPI is being built around a harder standard:
Independence must be observable, reproducible, and open to challenge.
IPI is an open protocol stack for verifiable digital commerce and coordination. The goal is to let communities and organizations run their own infrastructure, hold their own keys, verify their own state, and extend the system through open interfaces.
The intended result is not another hosted chain that users must trust from the outside. It is a complete verification path — from node and wallet to product, chip, checkout, payment, and receipt — that others can reproduce and operate without IPI's permission.
The current engineering direction includes:
- native settlement on a Cosmos SDK and CometBFT protocol with EVM and CosmWasm execution;
- IBC interoperability and open RPC, REST, gRPC, and EVM interfaces;
- native account and key paths, including secp256k1 and P-256/R1 use cases;
- verifiable product passports, chip identities, attestations, and checkout;
- independently deployable node, wallet, explorer, faucet, indexer, monitoring, and terminal components; and
- transparent protocol change control through IPI Improvement Proposals.
This is an early-stage project. Public repositories currently contain a mix of IPI code, active migrations, experiments, and attributed upstream forks. They must not be treated as production-ready until a release is explicitly marked, reproducibly built, tested, and documented as such.
IPI evaluates independence across multiple dimensions instead of hiding it behind one performance metric:
| Dimension | The question that must be answerable |
|---|---|
| Verification | Can an independent operator verify state from public data? |
| Control | Who holds keys and can change code, parameters, or access? |
| Operation | Can the system run without a mandatory private coordinator? |
| Reproducibility | Can a release be rebuilt and its provenance checked? |
| Governance | Are decisions, authority, and emergency powers visible? |
| Exit | Can users export, migrate, continue, or fork without permission? |
| Diversity | Are critical operators, implementations, and providers independent? |
The first specification of this model is IPI-0001: Verifiable Independence.
- Understand the target architecture and current maturity.
- Read the roadmap.
- See how to contribute.
- Propose a protocol change through the IPI process.
- Join an architectural or product conversation in GitHub Discussions.
- Find issues marked good first issue or help wanted.
- Report vulnerabilities through the private process in SECURITY.md.
| Area | Repository | Maturity |
|---|---|---|
| Protocol node | independency-daemon | Upstream-based; IPI consolidation in progress |
| Network configuration | chainconfig | Incubating |
| JavaScript wallet core | wallet-core.js | Experimental |
| Mobile wallet | protocolix | Experimental |
| RPC services | ipi-rpc | Experimental |
| Explorer | scan.ipi.io | Incubating |
| Community and governance | .github | Active |
Repository maturity labels are deliberately conservative and will change only with public evidence. The roadmap defines the exit criteria for each major stage.
We verify claims, build in public, preserve upstream attribution, document trust assumptions, and prefer changes that make the system easier to reproduce and operate independently. Architecture and governance changes are discussed before they are standardized.
Website · Discussions · Governance · IPI proposals · Licensing · Trademarks