From a7f393a747ed1085cc7845b46f31c1604007e33e Mon Sep 17 00:00:00 2001 From: meles Date: Mon, 24 Aug 2026 18:39:07 +0200 Subject: [PATCH 1/4] docs: present public engineering evidence --- ARCHITECTURE.md | 199 ++++++++++++++++------------ README.md | 1 + REPOSITORY_AUDIT.md | 140 ++++++++++++++++++++ profile/README.md | 258 ++++++++++++++++++++++--------------- scripts/check_community.py | 2 + 5 files changed, 418 insertions(+), 182 deletions(-) create mode 100644 REPOSITORY_AUDIT.md diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index 35a9880..aa8fd52 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -1,105 +1,141 @@ # IPI Architecture -This document describes the target IPI system and the boundaries contributors -must preserve. It is not a claim that every component is complete or public. -Current maturity is recorded separately from the target architecture. +IPI is designed as a multi-layer protocol infrastructure ecosystem. This +document separates the intended system architecture from the evidence currently +available in public repositories. ## System intent -IPI connects protocol settlement to independently verifiable digital and -physical commerce. A user should be able to hold a key, sign through a wallet -or terminal, verify the network through a node they choose, and verify product -or receipt claims without trusting one project-operated web service. +IPI connects protocol settlement, user-controlled signing, open query +interfaces, independent operation, and verifiable digital or physical commerce. +No hosted explorer, wallet, API, issuer, terminal, or project account should +silently become the only source of truth. -## Target layers +## Layered system map -~~~text +```text People and independent operators - | - | sign, query, verify, operate - v -Wallets · Terminal · Explorer · Node CLI · External applications - | - | RPC · REST · gRPC · EVM JSON-RPC · events - v -Protocol and application state -Accounts · Settlement · EVM · CosmWasm · Products · Chips · Checkout - | - | deterministic state transitions - v -Cosmos SDK · CometBFT consensus · storage · peer-to-peer network - | - +---------------- IBC and explicitly modeled external verification - -Optional services: indexer · faucet · monitoring · attestation verifier - anchoring · notification and routing adapters -~~~ - -Optional services must not silently become the only verification path. Their -outputs should be derivable from, authenticated by, or explicitly separated -from protocol state. + │ sign · query · verify · deploy · recover + ▼ +Wallet · Terminal · Explorer · Node CLI · External applications + │ RPC · REST · gRPC · EVM JSON-RPC · events + ▼ +Accounts · Settlement · EVM compatibility · CosmWasm contracts + │ deterministic state and explicit trust boundaries + ▼ +Cosmos SDK · CometBFT · peer-to-peer network · storage + │ + ├── IBC and separately specified external verification + └── optional services: indexer · faucet · monitoring · routing + +Product identity · chip attestation · checkout · payment · receipt + connect through specified application interfaces; + they are not implemented consensus claims merely because they appear here. +``` + +The intended end-to-end path can be summarized as: + +```text +Protocol / Node → RPC/API → Wallet / Explorer +→ Product Identity / Secure Element → Checkout / Payment → Verification +``` + +## Current public implementation map + +| Layer | Public source evidence | Current classification | +| --- | --- | --- | +| Protocol/node | [`independency-daemon`](https://github.com/ipicoin/independency-daemon) | `wasmd` tracking foundation; no IPI consensus/application changes | +| Network metadata | [`chainconfig`](https://github.com/ipicoin/chainconfig) | Tested legacy wallet configuration; not canonical current network identity | +| RPC/API clients | [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) | Upstream-derived gRPC-Web/gRPC-Gateway comparison and generated TypeScript clients | +| Explorer | [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) | Implemented native Cosmos and EVM query interface; public CI passes | +| Wallet model layer | [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) | Models and Bech32 validation tested; signing and transfer operations incomplete | +| Mobile client | [`protocolix`](https://github.com/ipicoin/protocolix) | Capacitor Android/iOS scaffold; wallet behavior absent | +| Governance/security | [`.github`](https://github.com/ipicoin/.github) | Public process, policies, architecture, roadmap, and automated validation | +| Independent deployment | [`hq-spacecraft`](https://github.com/ipicoin/hq-spacecraft) | Research scaffold; most Compose definitions are placeholders | +| Product/chip identity | Architecture and upstream secure-hardware reference forks | Research direction; no IPI-specific public implementation | +| Checkout/payment/receipt | Roadmap and upstream terminal concept forks | Concept stage; no executable public IPI integration | + +This table is limited to public evidence. Private, local, or hosted behavior is +not promoted to an implementation claim here. ## Component boundaries -### Protocol node +### Protocol node and validator operation + +The node validates deterministic state transitions and participates in +consensus. The public research foundation is CosmWasm `wasmd`, which supplies +Cosmos SDK, CometBFT, IBC, and CosmWasm capabilities upstream. An IPI node +release still needs explicit IPI modules and parameters, canonical genesis +binding, upgrade and recovery procedures, validator/sentry topology, versioned +artifacts, and compatibility tests. + +### RPC, APIs, explorer, and indexers -The node is responsible for deterministic validation and state transitions. -The engineering baseline combines Cosmos SDK and CometBFT with EVM and -CosmWasm execution. Consensus-critical dependencies, activation, genesis, and -upgrades require versioned specifications and compatibility tests. +RPC, REST, gRPC, EVM JSON-RPC, events, and indexers expose protocol data; they do +not define canonical state. Responses should include enough network identity, +height, and provenance for a caller to repeat important queries through another +provider or a local node. + +The public explorer implements direct CometBFT/Cosmos and EVM query paths. The +RPC research client compares two generated Cosmos transports. Neither is a +substitute for authenticated state verification by a node. ### Accounts, keys, and wallets -Users control signing authority. Wallets must verify network identity, show the -action being authorized, and avoid depending on a single project RPC. Native -secp256k1 and P-256/R1 paths must have explicit compatibility and hardware -threat models. +Users control signing authority. Wallets must verify network identity, display +the exact action being authorized, protect recovery material, and support +provider replacement. The public JavaScript wallet repository currently proves +only its model/configuration tests and Bech32 validation; transaction signing, +fees, endpoint verification, recovery, and release security remain unfinished. + +P-256/R1, WebAuthn, NFC, and secure-element paths require separate compatibility +and hardware threat models. Reference forks are research inputs, not IPI +implementations or security attestations. ### Products, chips, and attestations -Public state can record identifiers, issuers, bindings, lifecycle, and -revocation. Symmetric chip secrets and private business or personal data must -not be published on-chain. Secure-chip verification belongs behind a specified -attestation boundary with replay protection, issuer rotation, and failure -handling. +The intended application layer may record product identifiers, issuers, +bindings, lifecycle events, and revocation. Symmetric chip secrets and private +business or personal data must remain off-chain. Secure-chip verification +belongs behind a specified attestation boundary with replay protection, issuer +rotation, privacy analysis, and failure handling. -### Checkout and receipts +No IPI-specific product or secure-element implementation is currently public. -Checkout is a deterministic application flow, not a second source of monetary -truth. Cart, pricing, authorization, settlement, and receipt state transitions -must be separately testable. Terminals must continue to provide a safe, -explainable result when the network or an optional service is unavailable. +### Checkout, payment, and receipts -### Explorers, indexers, and public APIs +Checkout should be a deterministic application flow around explicit cart, +pricing, authorization, settlement, and receipt states. A terminal must provide +safe, explainable degraded behavior when a network or optional service is +unavailable. -These components make authenticated protocol data usable; they do not define -canonical state. Responses should expose network identity, height, provenance, -and enough information to repeat important queries against another provider or -local node. +Current public terminal/payment forks are concept or hardware scaffolds and do +not implement this IPI flow. -### Interoperability and anchoring +### Interoperability and external systems -IBC, anchoring, bridges, wrapped assets, routing, custody, and external oracles -introduce different trust boundaries. Each integration needs its own IPI, -threat model, accounting invariants, key-holder disclosure, independent -verification method, and shutdown or migration path. +IBC, anchoring, bridges, wrapped assets, routing, custody, AMMs, external +storage, and oracles introduce independent trust boundaries. Each integration +requires a versioned specification, threat model, accounting invariants, +key-holder disclosure, verification method, and shutdown or migration path. +An upstream reference fork does not establish an IPI integration. -## Current maturity +## Upstream foundation and IPI-specific work -| Capability | Current evidence | Public milestone | -| --- | --- | --- | -| Cosmos SDK / CometBFT node | Active integration baseline has built and produced blocks | Consolidated source and reproducible public build | -| EVM execution | Native value transfer and a demonstration contract have been exercised | Published compatibility tests and release artifacts | -| CosmWasm execution | A demonstration contract has been uploaded and executed | Published compatibility matrix and deterministic test suite | -| Wallet, explorer, faucet, status | Testnet-facing implementations exist | Versioned source, threat models, and independent deployment | -| Terminal and ordinary NFC checkout | Local application flow and physical tag tests exist | Public source, reproducible build, and end-to-end protocol integration | -| Product and secure-chip identity | Separate experimental work exists | Reviewed specifications, test vectors, and integrated module | -| IBC interoperability | Part of the protocol direction | Public end-to-end compatibility evidence | -| Bitcoin anchoring, wrapping, and routing | Planned research | Separate accepted IPIs before production implementation | - -Evidence from a private or local integration is useful engineering input but not -a public release. The [roadmap](ROADMAP.md) defines the gates for changing these -labels. +Using Cosmos SDK, CometBFT, CosmWasm, Ethereum tooling, and other established +open-source components provides interoperable foundations and reviewable +history. IPI preserves their licenses and does not claim their code as original. + +The public organization audit found: + +- 26 public forks with zero commits ahead of upstream; +- one tracking fork, `independency-daemon`, with two IPI commits limited to + provenance and CI hardening; and +- original IPI work concentrated in the explorer, wallet model/tests, + governance and architecture, website, configuration, and integration + research repositories. + +See [`REPOSITORY_AUDIT.md`](REPOSITORY_AUDIT.md) for the per-repository evidence. ## Design rules @@ -113,13 +149,16 @@ labels. secrets or unnecessary personal and commercial data. 5. **Treat interoperability as a new trust model.** A connection does not inherit the security or independence of either side automatically. -6. **Prefer replaceable services.** Hosted convenience must have an independent +6. **Prefer replaceable services.** Hosted convenience needs an independent provider or local-operation path. -7. **Design the exit before the launch.** Recovery, migration, shutdown, and +7. **Design the exit before launch.** Recovery, migration, shutdown, and continuity are protocol requirements. +8. **Label evidence precisely.** Implemented, inherited, generated, configured, + tested, hosted, and planned are different claims. ## Change control Material changes to these boundaries require an -[IPI Improvement Proposal](ipi/README.md). An implementation pull request must -link the proposal and cannot silently redefine its normative behavior. +[IPI Improvement Proposal](ipi/README.md). Implementation work may precede an +accepted proposal, but it must not silently redefine normative behavior or +claim maturity unsupported by public evidence. diff --git a/README.md b/README.md index 15feee6..78a0bd2 100644 --- a/README.md +++ b/README.md @@ -15,6 +15,7 @@ Repository-specific instructions always take precedence. | --- | --- | | [Organization profile](profile/README.md) | Public mission, project map, and entry points | | [Architecture](ARCHITECTURE.md) | Target layers, trust boundaries, and current maturity | +| [Public repository audit](REPOSITORY_AUDIT.md) | Per-repository source, provenance, functionality, and evidence assessment | | [Contributing](CONTRIBUTING.md) | How to discuss, build, test, and submit changes | | [Code of Conduct](CODE_OF_CONDUCT.md) | Expected community behavior | | [Security](SECURITY.md) | Private vulnerability reporting | diff --git a/REPOSITORY_AUDIT.md b/REPOSITORY_AUDIT.md new file mode 100644 index 0000000..36b7949 --- /dev/null +++ b/REPOSITORY_AUDIT.md @@ -0,0 +1,140 @@ +# Public Repository Audit + +Assessment date: **2026-08-24** + +This audit covers all **41 public repositories** in the `ipicoin` GitHub +organization. It distinguishes source that is IPI-specific from inherited +upstream code and records what the default branch actually demonstrates. + +## Method + +- Enumerated every public repository through the GitHub API. +- Inspected source trees, manifests, tests, workflows, licenses, and opening + documentation for every original repository. +- Compared every GitHub fork against its declared upstream default branch. +- Ran available checks on the strongest original repositories using Node 24 or + their documented local validators. +- Treated generated clients, configuration files, scaffolds, hosted endpoints, + and target architecture as distinct kinds of evidence. + +This is a presentation and source audit, not a security audit or certification. + +## Original and imported source repositories + +| Repository | What is in the source | IPI-specific evidence | Functional/maturity result | +| --- | --- | --- | --- | +| [`.github`](https://github.com/ipicoin/.github) | Governance, security, contribution policy, architecture, roadmap, IPI proposal process, validation script | Original public standards and evidence model | Active bootstrap process; community validation passes | +| [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) | Browser explorer, local API proxy, native Cosmos/CometBFT queries, EVM JSON-RPC diagnostics | Explorer routing, rendering, search, account, validator, block, transaction, and EVM inspection | Active development; syntax checks and public explorer CI pass | +| [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) | JavaScript models, controllers, wallet-operation scaffolds, seven test files | Wallet/address/request/transaction/contract models and configurable Bech32 validation | 11 tests pass; key import/generation and transfer paths are incomplete or broken and untested; dependency audit blocks CI | +| [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) | Astro landing page, small Starlight documentation tree, OpenSpec change record | IPI website and launch/documentation presentation | Static build passes on Node 24; dependency audit currently blocks public CI | +| [`chainconfig`](https://github.com/ipicoin/chainconfig) | One Cosmos wallet configuration export and one coherence test | Historical IPI chain metadata and Bech32/denomination fields | Test passes; values identify legacy `ipi-mainnet-2`, not a canonical current release | +| [`protocolix`](https://github.com/ipicoin/protocolix) | Capacitor Android/iOS projects and the default camera/demo web shell | IPI package/bundle identifiers and native project scaffold | Web scaffold builds and native project trees are checked in; no wallet, signing, NFC, or secure-key implementation and no application tests; dependency audit blocks CI | +| [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) | Protobuf tree, two generated TypeScript client trees, Next.js comparison pages | Repository packaging and research framing | Upstream-derived integration sandbox; no IPI endpoints or RPC server implementation | +| [`Iswap`](https://github.com/ipicoin/Iswap) | Hyperweb swap example with Cosmos Kit and Osmosis query dependencies | Status, provenance, and IPI research framing only | Imported sandbox; no IPI configuration, tests, or public CI | +| [`Ivote`](https://github.com/ipicoin/Ivote) | Hyperweb governance proposal/vote example | Status, provenance, and IPI research framing only | Imported sandbox; no IPI configuration, tests, or public application CI | +| [`ipi-nft`](https://github.com/ipicoin/ipi-nft) | Hyperweb/Stargaze NFT example with mint, sale, transfer, and burn hooks | Status, provenance, and IPI research framing only | Imported sandbox; no IPI configuration, tests, or public application CI | +| [`ipicoin.github.io`](https://github.com/ipicoin/ipicoin.github.io) | Default Vue/Vite demo, placeholder counter store, one default Playwright test | Repository naming and legacy presentation only | Build passes; no IPI product behavior and no unit tests; canonical source is `www.ipi.io` | +| [`hq-spacecraft`](https://github.com/ipicoin/hq-spacecraft) | Compose include skeleton, one Pi-hole definition, empty service files, placeholder Python/Task commands | Self-hosting research organization and documentation | Prototype skeleton; not a deployable collaboration stack | +| [`universal-independency-declaration`](https://github.com/ipicoin/universal-independency-declaration) | Empty JavaScript entry, hello-world Python/Rust, language manifests | Link to IPI-0001 research direction | Concept skeleton; no shared API, fixtures, or executable independence checks | +| [`standard_repo_template`](https://github.com/ipicoin/standard_repo_template) | Repository readiness README, Apache license, empty source/test placeholders | IPI publication and evidence checklist | Documentation template, not an implementation | + +## Public forks and upstream delta + +The table reports commits **ahead of the current upstream default branch** at +the assessment date. Zero means the fork contains no IPI-specific source change. + +| Repository | Declared upstream | Ahead / behind | Role and finding | +| --- | --- | ---: | --- | +| [`independency-daemon`](https://github.com/ipicoin/independency-daemon) | `CosmWasm/wasmd` | 2 / 11 | Node research foundation; two IPI commits add provenance and fork-safe CI only, with no consensus/application changes | +| [`chain-registry`](https://github.com/ipicoin/chain-registry) | `cosmos/chain-registry` | 0 / 49 | Cosmos metadata reference; no IPI entry or modification in this fork | +| [`CosmWasm___cosmwasm`](https://github.com/ipicoin/CosmWasm___cosmwasm) | `CosmWasm/cosmwasm` | 0 / 1 | CosmWasm framework reference | +| [`CosmWasm___wasmvm`](https://github.com/ipicoin/CosmWasm___wasmvm) | `CosmWasm/wasmvm` | 0 / 0 | CosmWasm VM binding reference | +| [`CosmWasm___cosmwasm-contracts`](https://github.com/ipicoin/CosmWasm___cosmwasm-contracts) | `CosmWasm/cosmwasm-contracts` | 0 / 0 | Upstream contract test examples | +| [`cw-template`](https://github.com/ipicoin/cw-template) | `CosmWasm/cw-template` | 0 / 0 | Contract project template reference | +| [`hyperweb-io___starship`](https://github.com/ipicoin/hyperweb-io___starship) | `hyperweb-io/starship` | 0 / 0 | Interchain test-infrastructure reference | +| [`Agoric___agoric-sdk`](https://github.com/ipicoin/Agoric___agoric-sdk) | `Agoric/agoric-sdk` | 0 / 148 | JavaScript smart-contract platform reference | +| [`foundry-rs___foundry`](https://github.com/ipicoin/foundry-rs___foundry) | `foundry-rs/foundry` | 0 / 568 | EVM development tooling reference | +| [`argotorg___solidity`](https://github.com/ipicoin/argotorg___solidity) | `argotorg/solidity` | 0 / 144 | Solidity compiler reference | +| [`Uniswap___v4-core`](https://github.com/ipicoin/Uniswap___v4-core) | `Uniswap/v4-core` | 0 / 0 | AMM architecture reference; not an IPI liquidity implementation | +| [`foundry-rs___starknet-foundry`](https://github.com/ipicoin/foundry-rs___starknet-foundry) | `foundry-rs/starknet-foundry` | 0 / 49 | Starknet tooling reference; not part of a demonstrated IPI path | +| [`nikeee___node-ntag424`](https://github.com/ipicoin/nikeee___node-ntag424) | `nikeee/node-ntag424` | 0 / 18 | Working upstream NTAG 424 library reference; no IPI integration | +| [`Yubico___yubico-piv-tool`](https://github.com/ipicoin/Yubico___yubico-piv-tool) | `Yubico/yubico-piv-tool` | 0 / 0 | Hardware-key command-line reference | +| [`agco___yubikey-piv-node`](https://github.com/ipicoin/agco___yubikey-piv-node) | `agco/yubikey-piv-node` | 0 / 0 | Legacy Node.js YubiKey PIV reference | +| [`micronucleus___micronucleus`](https://github.com/ipicoin/micronucleus___micronucleus) | `micronucleus/micronucleus` | 0 / 0 | Embedded bootloader reference | +| [`cheer-gear`](https://github.com/ipicoin/cheer-gear) | `Sarverott/cheer-gear` | 0 / 0 | Arduino/ESP32 concept scaffold; setup/loop and application source are effectively empty | +| [`cheers-protocol`](https://github.com/ipicoin/cheers-protocol) | `The-Apokryf/cheers-protocol` | 0 / 0 | Documentation-only concept fork with no protocol implementation | +| [`w3c___webauthn`](https://github.com/ipicoin/w3c___webauthn) | `w3c/webauthn` | 0 / 54 | Authentication standard reference | +| [`ipfs___helia`](https://github.com/ipicoin/ipfs___helia) | `ipfs/helia` | 0 / 76 | IPFS client reference | +| [`ArweaveTeam___arweave-js`](https://github.com/ipicoin/ArweaveTeam___arweave-js) | `ArweaveTeam/arweave-js` | 0 / 0 | Durable-storage client reference | +| [`withastro___astro`](https://github.com/ipicoin/withastro___astro) | `withastro/astro` | 0 / 586 | Website framework reference | +| [`vllm-project___vllm`](https://github.com/ipicoin/vllm-project___vllm) | `vllm-project/vllm` | 0 / 1725 | AI serving reference; unrelated to current public protocol implementation | +| [`camel-ai___oasis`](https://github.com/ipicoin/camel-ai___oasis) | `camel-ai/oasis` | 0 / 15 | Multi-agent simulation reference | +| [`anthropics___skills`](https://github.com/ipicoin/anthropics___skills) | `anthropics/skills` | 0 / 9 | Agent-workflow reference | +| [`muan___unicode-emoji-json`](https://github.com/ipicoin/muan___unicode-emoji-json) | `muan/unicode-emoji-json` | 0 / 0 | UI data reference | +| [`mit-license`](https://github.com/ipicoin/mit-license) | `remy/mit-license` | 0 / 0 | Licensing-site reference | + +## Strongest public engineering evidence + +1. `scan.ipi.io`: concrete multi-protocol explorer behavior, compact source, + explicit limitations, and passing verification CI. +2. `.github`: coherent architecture, security/governance boundaries, IPI + proposal process, and automated document validation. +3. `wallet-core.js`: a real tested model/validation layer, provided its + incomplete operation modules are not presented as working signing flows. +4. `ipi-rpc`: substantial generated Cosmos protocol/client surface and two + transport paths, provided its upstream origin and lack of IPI integration + remain explicit. +5. `www.ipi.io` and `chainconfig`: buildable public presentation and tested + metadata, with the configuration correctly labeled legacy. + +## Public evidence gaps + +- No consolidated public IPI-specific node source, canonical genesis binding, + release artifact, or reproducible node deployment. +- No public validator/sentry/monitoring implementation tied to a versioned IPI + network release. +- Wallet signing, transaction construction, fee handling, recovery, and mobile + security flows are incomplete or absent in the public wallet repositories. +- No public IPI-specific product identity, secure-element attestation, + checkout, payment, terminal, or receipt implementation. +- No public end-to-end EVM or CosmWasm compatibility suite tied to an IPI node + revision; the explorer demonstrates query integration only. +- Several active-development JavaScript repositories have dependency audit + failures, and some scaffolds advertise test commands without application + tests. +- No public release artifacts exist across the original repositories except one + historical wallet-core release record; independent reproducibility remains + unproven. + +## Presentation risk review + +Without a curated profile, a neutral AI could mistake the organization for a +collection of renamed forks because the repository list is dominated by large +upstream mirrors. It could also overestimate prototypes from repository names +or underestimate real work because the working explorer and governance system +were not prioritized. + +The corrective hierarchy is: + +1. lead with original, executable, tested IPI evidence; +2. show the multi-layer architecture and explicit interfaces; +3. label partial integrations precisely; +4. describe upstream foundations as attributed engineering inputs; and +5. keep missing public implementations visible in one development-status + section rather than repeating generic disclaimers above every capability. + +## Recommended organization pins + +GitHub does not expose organization-profile pin management through the API used +for this audit. The recommended manual order is: + +1. [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) +2. [`.github`](https://github.com/ipicoin/.github) +3. [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) +4. [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) +5. [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) +6. [`independency-daemon`](https://github.com/ipicoin/independency-daemon) + +This order puts original, runnable or tested IPI work first and leaves the +attributed upstream node foundation visible only after its current status is +clear. diff --git a/profile/README.md b/profile/README.md index 191ce94..7e5468d 100644 --- a/profile/README.md +++ b/profile/README.md @@ -1,105 +1,159 @@ # IPI — Independent Protocol Infrastructure -### Infrastructure for systems that can be independently operated, verified, and extended. - -**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.** - -## What IPI is building - -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. - -## The independence standard - -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](/ipicoin/.github/blob/main/ipi/IPI-0001.md). - -## Start here - -- Understand the [target architecture and current maturity](/ipicoin/.github/blob/main/ARCHITECTURE.md). -- Read the [roadmap](/ipicoin/.github/blob/main/ROADMAP.md). -- See [how to contribute](/ipicoin/.github/blob/main/CONTRIBUTING.md). -- Propose a protocol change through the - [IPI process](/ipicoin/.github/tree/main/ipi). -- Join an architectural or product conversation in - [GitHub Discussions](https://github.com/ipicoin/.github/discussions). -- Find issues marked - [good first issue](https://github.com/search?q=org%3Aipicoin+label%3A%22good+first+issue%22+is%3Aopen&type=issues) - or [help wanted](https://github.com/search?q=org%3Aipicoin+label%3A%22help+wanted%22+is%3Aopen&type=issues). -- Report vulnerabilities through the private process in - [SECURITY.md](/ipicoin/.github/blob/main/SECURITY.md). - -## Project map - -| Area | Repository | Maturity | +**A multi-layer protocol infrastructure program connecting network state, open +APIs, self-custody clients, independent verification, and physical/digital +commerce research.** + +IPI is not organized as a token-only repository or a single web application. +Its architecture and public work are organized across blockchain and network +foundations, wallet and key infrastructure, a block explorer, RPC client +research, node and validator integration, EVM and CosmWasm integration +directions, governance and security processes, product-identity and +secure-element research, checkout/payment concepts, and independently operable +infrastructure. + +The public repositories contain different levels of evidence across those +layers. The strongest implemented components are linked first below; integration +and research work is labeled separately. + +## What Exists Today + +- **A zero-dependency Cosmos/EVM testnet explorer.** + [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) implements block, + transaction, account, validator, native Cosmos, and EVM JSON-RPC inspection in + browser JavaScript, with same-origin API routing and passing public CI. +- **A tested JavaScript wallet model layer.** + [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) contains wallet, + address, request, transaction, and contract models plus Bech32 validation. + Eleven model/configuration tests pass; signing and transfer operations remain + incomplete. +- **Cosmos RPC transport and client-generation research.** + [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) contains protobuf inputs, + generated TypeScript clients, and comparison pages for gRPC-Web and + gRPC-Gateway. It is an upstream-derived integration sandbox, not an RPC server. +- **A public protocol-change and governance process.** + [`.github`](https://github.com/ipicoin/.github) contains the architecture, + security policy, governance rules, contribution standards, roadmap, and the + IPI Improvement Proposal process. IPI-0000 defines the process; IPI-0001 is a + draft evidence model for verifiable independence. +- **A public node foundation with explicit provenance.** + [`independency-daemon`](https://github.com/ipicoin/independency-daemon) tracks + CosmWasm `wasmd`, built on Cosmos SDK and CometBFT. Current IPI changes are + provenance documentation and CI hardening; an IPI node release is not yet + implemented in that fork. +- **Public product and documentation surfaces.** + [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) is the Astro source for + the website and documentation, while + [`chainconfig`](https://github.com/ipicoin/chainconfig) preserves a tested but + legacy Cosmos wallet configuration that is explicitly non-canonical. +- **Application integration sandboxes.** + [`Iswap`](https://github.com/ipicoin/Iswap), + [`Ivote`](https://github.com/ipicoin/Ivote), and + [`ipi-nft`](https://github.com/ipicoin/ipi-nft) preserve attributed Hyperweb + examples for swap, governance, and NFT workflow evaluation. They do not yet + contain IPI network integration. + +## Architecture + +The intended verification path is broader than any one repository: + +```text +Cosmos SDK / CometBFT / CosmWasm foundation + ↓ +IPI node integration · validator/network operation + ↓ +RPC · REST · gRPC · EVM JSON-RPC · events + ↓ +Explorer · wallet core · mobile approval · external clients + ↓ +Product identity / secure element → checkout / payment → receipt + ↓ +Independent operation, governance, and verification evidence +``` + +Today, the public explorer and governance/evidence layers are concrete; wallet +models and RPC clients are partial; the public node is still an upstream +foundation; and product identity, secure-element, checkout, and payment are +research directions without a public IPI implementation. See the +[architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md) and +[complete repository audit](https://github.com/ipicoin/.github/blob/main/REPOSITORY_AUDIT.md). + +## Engineering Evidence + +| Area | Public evidence | Status | | --- | --- | --- | -| Protocol node | [independency-daemon](https://github.com/ipicoin/independency-daemon) | Upstream-based; IPI consolidation in progress | -| Network configuration | [chainconfig](https://github.com/ipicoin/chainconfig) | Incubating | -| JavaScript wallet core | [wallet-core.js](https://github.com/ipicoin/wallet-core.js) | Experimental | -| Mobile wallet | [protocolix](https://github.com/ipicoin/protocolix) | Experimental | -| RPC services | [ipi-rpc](https://github.com/ipicoin/ipi-rpc) | Experimental | -| Explorer | [scan.ipi.io](https://github.com/ipicoin/scan.ipi.io) | Incubating | -| Community and governance | [.github](https://github.com/ipicoin/.github) | Active | - -Repository maturity labels are deliberately conservative and will change only -with public evidence. The [roadmap](/ipicoin/.github/blob/main/ROADMAP.md) -defines the exit criteria for each major stage. - -## How we work - -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](https://ipi.io) · -[Discussions](https://github.com/ipicoin/.github/discussions) · -[Governance](/ipicoin/.github/blob/main/GOVERNANCE.md) · -[IPI proposals](/ipicoin/.github/tree/main/ipi) · -[Licensing](/ipicoin/.github/blob/main/LICENSING.md) · -[Trademarks](/ipicoin/.github/blob/main/TRADEMARKS.md) +| Explorer and verification UI | [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) | Active development; native Cosmos and EVM query paths implemented | +| Wallet and account models | [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) | Active development; model tests pass, signing/transfer incomplete | +| RPC/API clients | [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) | Integration research; upstream-derived generated-client comparison | +| Protocol/network foundation | [`independency-daemon`](https://github.com/ipicoin/independency-daemon) | Upstream foundation with IPI integration in progress | +| Mobile client | [`protocolix`](https://github.com/ipicoin/protocolix) | Capacitor Android/iOS scaffold; wallet logic not implemented | +| Network metadata | [`chainconfig`](https://github.com/ipicoin/chainconfig) | Tested legacy configuration; not canonical current identity | +| Governance and security | [`.github`](https://github.com/ipicoin/.github) | Active bootstrap process with automated document validation | +| Website and documentation | [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) | Active development; Astro static build | +| Independent infrastructure | [`hq-spacecraft`](https://github.com/ipicoin/hq-spacecraft) | Prototype scaffold; most service compositions are placeholders | +| Product identity / secure element | [architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md), [`node-ntag424` reference fork](https://github.com/ipicoin/nikeee___node-ntag424) | Research direction; no IPI-specific implementation | +| Checkout / payment / receipt | [roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md), [`cheer-gear` reference fork](https://github.com/ipicoin/cheer-gear) | Concept and hardware scaffold; no executable IPI integration | + +## Why IPI Is Different + +IPI's engineering thesis is that infrastructure should be inspectable and +replaceable at every layer: + +- **Independence:** a hosted endpoint or organization account must not silently + become the only way to operate or verify the system. +- **Self-custody:** keys and signing intent belong at the user-controlled edge; + wallets must make network identity and authorized actions explicit. +- **Independent operation:** nodes, clients, explorers, and optional services + should have documented deployment, recovery, and exit paths. +- **Reproducibility:** protocol claims should resolve to source revisions, + dependency locks, build procedures, tests, and observable evidence. +- **Open interfaces:** RPC, REST, gRPC, EVM JSON-RPC, events, and portable data + formats are boundaries that independent implementations can reproduce. +- **Transparent governance:** protocol and trust changes belong in public, + versioned proposals with security, compatibility, and operational analysis. +- **Hardware-backed identity direction:** P-256/R1, NFC, and secure-element work + is treated as a separate attestation and privacy problem, not as a marketing + shortcut or a reason to put secret data on-chain. + +These are design requirements and research goals, not a claim that every layer +is complete or independently operated today. + +## Upstream Foundations + +IPI deliberately evaluates established open-source foundations including +Cosmos SDK, CometBFT, CosmWasm, `wasmd`, Ethereum tooling, WebAuthn, and secure +hardware libraries. Using upstream infrastructure is normal protocol +engineering: it provides reviewed interfaces, interoperability, and a visible +history to build on. + +Attribution is explicit. Twenty-six public IPI forks currently contain no +commits ahead of upstream. `independency-daemon` has two IPI commits limited to +fork provenance and CI hardening. These forks are research references and must +not be read as IPI-authored implementations. IPI-specific public evidence lives +in the explorer, wallet model/test work, governance and architecture, +configuration, documentation, and integration boundaries described above. + +## Development Status + +IPI is under active development. No public repository should be assumed safe +for production assets unless a versioned release explicitly documents its +threat model, compatibility, reproducible build, tests, security review, and +support lifecycle. + +The main public evidence gaps are a consolidated IPI-specific node source and +genesis binding, public validator/deployment tooling, completed wallet signing +flows, reproducible releases, and public implementations for product identity, +secure-element attestation, checkout, payment, and receipts. The +[roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md) defines the +evidence expected before stronger maturity claims. + +## Start Here + +[Explorer](https://github.com/ipicoin/scan.ipi.io) · +[Architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md) · +[Repository audit](https://github.com/ipicoin/.github/blob/main/REPOSITORY_AUDIT.md) · +[Governance](https://github.com/ipicoin/.github/blob/main/GOVERNANCE.md) · +[IPI proposals](https://github.com/ipicoin/.github/tree/main/ipi) · +[Roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md) · +[Security](https://github.com/ipicoin/.github/blob/main/SECURITY.md) · +[Website](https://ipi.io) diff --git a/scripts/check_community.py b/scripts/check_community.py index e31124b..3972600 100644 --- a/scripts/check_community.py +++ b/scripts/check_community.py @@ -10,6 +10,7 @@ REQUIRED_FILES = [ "AGENTS.md", "ARCHITECTURE.md", + "REPOSITORY_AUDIT.md", "README.md", "profile/README.md", "CONTRIBUTING.md", @@ -37,6 +38,7 @@ CLAIM_SURFACE = [ "ARCHITECTURE.md", + "REPOSITORY_AUDIT.md", "README.md", "profile/README.md", "ROADMAP.md", From 3752883f0bde1450109de120aabe7da9b6f0f8d6 Mon Sep 17 00:00:00 2001 From: meles Date: Mon, 24 Aug 2026 18:55:42 +0200 Subject: [PATCH 2/4] docs: record dependency audit remediation --- REPOSITORY_AUDIT.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/REPOSITORY_AUDIT.md b/REPOSITORY_AUDIT.md index 36b7949..476a203 100644 --- a/REPOSITORY_AUDIT.md +++ b/REPOSITORY_AUDIT.md @@ -25,15 +25,15 @@ This is a presentation and source audit, not a security audit or certification. | --- | --- | --- | --- | | [`.github`](https://github.com/ipicoin/.github) | Governance, security, contribution policy, architecture, roadmap, IPI proposal process, validation script | Original public standards and evidence model | Active bootstrap process; community validation passes | | [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) | Browser explorer, local API proxy, native Cosmos/CometBFT queries, EVM JSON-RPC diagnostics | Explorer routing, rendering, search, account, validator, block, transaction, and EVM inspection | Active development; syntax checks and public explorer CI pass | -| [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) | JavaScript models, controllers, wallet-operation scaffolds, seven test files | Wallet/address/request/transaction/contract models and configurable Bech32 validation | 11 tests pass; key import/generation and transfer paths are incomplete or broken and untested; dependency audit blocks CI | -| [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) | Astro landing page, small Starlight documentation tree, OpenSpec change record | IPI website and launch/documentation presentation | Static build passes on Node 24; dependency audit currently blocks public CI | +| [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) | JavaScript models, controllers, wallet-operation scaffolds, seven test files | Wallet/address/request/transaction/contract models and configurable Bech32 validation | 11 tests pass; key import/generation and transfer paths are incomplete or broken and untested; high-severity audit remediation is in [PR #20](https://github.com/ipicoin/wallet-core.js/pull/20) | +| [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) | Astro landing page, small Starlight documentation tree, OpenSpec change record | IPI website and launch/documentation presentation | Static build passes on Node 24; dependency audit remediation is in [PR #11](https://github.com/ipicoin/www.ipi.io/pull/11) | | [`chainconfig`](https://github.com/ipicoin/chainconfig) | One Cosmos wallet configuration export and one coherence test | Historical IPI chain metadata and Bech32/denomination fields | Test passes; values identify legacy `ipi-mainnet-2`, not a canonical current release | -| [`protocolix`](https://github.com/ipicoin/protocolix) | Capacitor Android/iOS projects and the default camera/demo web shell | IPI package/bundle identifiers and native project scaffold | Web scaffold builds and native project trees are checked in; no wallet, signing, NFC, or secure-key implementation and no application tests; dependency audit blocks CI | +| [`protocolix`](https://github.com/ipicoin/protocolix) | Capacitor Android/iOS projects and the default camera/demo web shell | IPI package/bundle identifiers and native project scaffold | Web scaffold builds and native project trees are checked in; no wallet, signing, NFC, or secure-key implementation and no application tests; audit and build CI pass in [PR #11](https://github.com/ipicoin/protocolix/pull/11) | | [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) | Protobuf tree, two generated TypeScript client trees, Next.js comparison pages | Repository packaging and research framing | Upstream-derived integration sandbox; no IPI endpoints or RPC server implementation | | [`Iswap`](https://github.com/ipicoin/Iswap) | Hyperweb swap example with Cosmos Kit and Osmosis query dependencies | Status, provenance, and IPI research framing only | Imported sandbox; no IPI configuration, tests, or public CI | | [`Ivote`](https://github.com/ipicoin/Ivote) | Hyperweb governance proposal/vote example | Status, provenance, and IPI research framing only | Imported sandbox; no IPI configuration, tests, or public application CI | | [`ipi-nft`](https://github.com/ipicoin/ipi-nft) | Hyperweb/Stargaze NFT example with mint, sale, transfer, and burn hooks | Status, provenance, and IPI research framing only | Imported sandbox; no IPI configuration, tests, or public application CI | -| [`ipicoin.github.io`](https://github.com/ipicoin/ipicoin.github.io) | Default Vue/Vite demo, placeholder counter store, one default Playwright test | Repository naming and legacy presentation only | Build passes; no IPI product behavior and no unit tests; canonical source is `www.ipi.io` | +| [`ipicoin.github.io`](https://github.com/ipicoin/ipicoin.github.io) | Default Vue/Vite demo, placeholder counter store, one default Playwright test | Repository naming and legacy presentation only | Build passes; no IPI product behavior and no unit tests; canonical source is `www.ipi.io`; audit remediation is in [PR #10](https://github.com/ipicoin/ipicoin.github.io/pull/10) | | [`hq-spacecraft`](https://github.com/ipicoin/hq-spacecraft) | Compose include skeleton, one Pi-hole definition, empty service files, placeholder Python/Task commands | Self-hosting research organization and documentation | Prototype skeleton; not a deployable collaboration stack | | [`universal-independency-declaration`](https://github.com/ipicoin/universal-independency-declaration) | Empty JavaScript entry, hello-world Python/Rust, language manifests | Link to IPI-0001 research direction | Concept skeleton; no shared API, fixtures, or executable independence checks | | [`standard_repo_template`](https://github.com/ipicoin/standard_repo_template) | Repository readiness README, Apache license, empty source/test placeholders | IPI publication and evidence checklist | Documentation template, not an implementation | @@ -99,9 +99,11 @@ the assessment date. Zero means the fork contains no IPI-specific source change. checkout, payment, terminal, or receipt implementation. - No public end-to-end EVM or CosmWasm compatibility suite tied to an IPI node revision; the explorer demonstrates query integration only. -- Several active-development JavaScript repositories have dependency audit - failures, and some scaffolds advertise test commands without application - tests. +- The assessment found high-severity dependency audit failures in several + JavaScript repositories. Lockfile remediation is included in the linked + wallet-core, Protocolix, website, and legacy-site PRs; low-severity + InterchainJS/Ethers findings remain in wallet-core, and some scaffolds still + have no application tests. - No public release artifacts exist across the original repositories except one historical wallet-core release record; independent reproducibility remains unproven. From b0b2a2c21f9f2611610faa8067131d8065f52a71 Mon Sep 17 00:00:00 2001 From: meles Date: Mon, 24 Aug 2026 19:08:50 +0200 Subject: [PATCH 3/4] docs: strengthen source-linked IPI positioning --- ARCHITECTURE.md | 8 +++ REPOSITORY_AUDIT.md | 21 +++++++ profile/README.md | 133 ++++++++++++++++++++++++++++++-------------- 3 files changed, 119 insertions(+), 43 deletions(-) diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index aa8fd52..f4b139a 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -40,6 +40,14 @@ Protocol / Node → RPC/API → Wallet / Explorer → Product Identity / Secure Element → Checkout / Payment → Verification ``` +These components belong to one system because each layer carries evidence to +the next: consensus produces state, open APIs expose it, wallets authorize +changes, explorers let independent readers inspect results, product and chip +interfaces bind external events to explicit attestations, and checkout/receipt +flows turn those attestations and settlements into independently checkable +records. A hosted service may improve convenience, but it must not become the +only place where that chain of evidence can be reproduced. + ## Current public implementation map | Layer | Public source evidence | Current classification | diff --git a/REPOSITORY_AUDIT.md b/REPOSITORY_AUDIT.md index 476a203..96ac6f6 100644 --- a/REPOSITORY_AUDIT.md +++ b/REPOSITORY_AUDIT.md @@ -125,6 +125,27 @@ The corrective hierarchy is: 5. keep missing public implementations visible in one development-status section rather than repeating generic disclaimers above every capability. +## External-reader stress test + +- **Senior blockchain engineer:** can verify original explorer behavior, tested + wallet models, generated RPC surfaces, and public change control, while still + identifying the IPI-specific node and release process as the primary gap. +- **Technical infrastructure investor:** can see a coherent thesis connecting + protocol state, self-custody clients, independent verification, open + interfaces, and hardware/product/payment boundaries; execution maturity is + uneven, but the scope is materially broader than an asset and website. +- **Skeptical provenance reviewer:** can verify that most forks are unchanged + upstream references and that IPI does not claim their authorship. The same + reviewer cannot accurately reduce the organization to a renamed fork without + ignoring the original explorer, wallet model/tests, governance, configuration, + website, and integration work. + +The strongest defensible negative conclusion after this presentation pass is +that IPI is an incomplete infrastructure ecosystem without a public +IPI-specific node release—not that it is merely a token, website, or renamed +fork. Removing that remaining criticism requires new engineering evidence, not +different wording. + ## Recommended organization pins GitHub does not expose organization-profile pin management through the API used diff --git a/profile/README.md b/profile/README.md index 7e5468d..c027bf7 100644 --- a/profile/README.md +++ b/profile/README.md @@ -1,46 +1,60 @@ # IPI — Independent Protocol Infrastructure -**A multi-layer protocol infrastructure program connecting network state, open -APIs, self-custody clients, independent verification, and physical/digital -commerce research.** - -IPI is not organized as a token-only repository or a single web application. -Its architecture and public work are organized across blockchain and network -foundations, wallet and key infrastructure, a block explorer, RPC client -research, node and validator integration, EVM and CosmWasm integration -directions, governance and security processes, product-identity and -secure-element research, checkout/payment concepts, and independently operable -infrastructure. - -The public repositories contain different levels of evidence across those -layers. The strongest implemented components are linked first below; integration +**A public, multi-layer protocol infrastructure ecosystem connecting network +state, open APIs, self-custody clients, independent verification, governance, +and physical/digital commerce integration.** + +IPI organizes public engineering across blockchain and network foundations, +wallet and key infrastructure, a block explorer, RPC clients, node and validator +integration, EVM and CosmWasm interfaces, governance and security processes, +product identity and secure-element research, checkout/payment architecture, +and independently operable infrastructure. Together these layers define a path +from protocol state to user authorization, external-product verification, and +independently checkable outcomes. + +Start with the implemented and tested components below. Every primary capability +links directly to its code, tests, or governing technical document; integration and research work is labeled separately. ## What Exists Today - **A zero-dependency Cosmos/EVM testnet explorer.** - [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) implements block, - transaction, account, validator, native Cosmos, and EVM JSON-RPC inspection in - browser JavaScript, with same-origin API routing and passing public CI. + [`explorer.js`](https://github.com/ipicoin/scan.ipi.io/blob/main/explorer.js) + implements block, transaction, account, validator, native Cosmos, and EVM + JSON-RPC inspection in browser JavaScript. The repository also contains a + [local API proxy](https://github.com/ipicoin/scan.ipi.io/blob/main/dev-server.mjs), + a dedicated [EVM diagnostic view](https://github.com/ipicoin/scan.ipi.io/blob/main/evm.html), + and passing public CI. - **A tested JavaScript wallet model layer.** - [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) contains wallet, - address, request, transaction, and contract models plus Bech32 validation. - Eleven model/configuration tests pass; signing and transfer operations remain + [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) contains + [wallet, address, request, transaction, and contract models](https://github.com/ipicoin/wallet-core.js/tree/main/src/models) + plus configurable Bech32 validation. Its + [seven test files](https://github.com/ipicoin/wallet-core.js/tree/main/tests) + contain eleven passing tests; signing and transfer operations remain incomplete. - **Cosmos RPC transport and client-generation research.** - [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) contains protobuf inputs, - generated TypeScript clients, and comparison pages for gRPC-Web and - gRPC-Gateway. It is an upstream-derived integration sandbox, not an RPC server. + [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) contains + [Cosmos, IBC, Tendermint, and CosmWasm protobuf inputs](https://github.com/ipicoin/ipi-rpc/tree/main/proto), + generated TypeScript clients for + [gRPC-Web](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_web) and + [gRPC-Gateway](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_gateway), + and browser comparison pages. It is an upstream-derived integration sandbox, + not an RPC server. - **A public protocol-change and governance process.** - [`.github`](https://github.com/ipicoin/.github) contains the architecture, - security policy, governance rules, contribution standards, roadmap, and the - IPI Improvement Proposal process. IPI-0000 defines the process; IPI-0001 is a - draft evidence model for verifiable independence. + [`.github`](https://github.com/ipicoin/.github) contains the + [architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md), + [security policy](https://github.com/ipicoin/.github/blob/main/SECURITY.md), + [governance rules](https://github.com/ipicoin/.github/blob/main/GOVERNANCE.md), + roadmap, and IPI Improvement Proposal process. + [IPI-0000](https://github.com/ipicoin/.github/blob/main/ipi/IPI-0000.md) + defines the process; [IPI-0001](https://github.com/ipicoin/.github/blob/main/ipi/IPI-0001.md) + is a draft evidence model for verifiable independence. - **A public node foundation with explicit provenance.** [`independency-daemon`](https://github.com/ipicoin/independency-daemon) tracks CosmWasm `wasmd`, built on Cosmos SDK and CometBFT. Current IPI changes are provenance documentation and CI hardening; an IPI node release is not yet - implemented in that fork. + implemented in that fork. The exact boundary is recorded in + [`IPI_FORK_STATUS.md`](https://github.com/ipicoin/independency-daemon/blob/main/IPI_FORK_STATUS.md). - **Public product and documentation surfaces.** [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) is the Astro source for the website and documentation, while @@ -80,21 +94,40 @@ research directions without a public IPI implementation. See the ## Engineering Evidence -| Area | Public evidence | Status | -| --- | --- | --- | -| Explorer and verification UI | [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) | Active development; native Cosmos and EVM query paths implemented | -| Wallet and account models | [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) | Active development; model tests pass, signing/transfer incomplete | -| RPC/API clients | [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) | Integration research; upstream-derived generated-client comparison | -| Protocol/network foundation | [`independency-daemon`](https://github.com/ipicoin/independency-daemon) | Upstream foundation with IPI integration in progress | -| Mobile client | [`protocolix`](https://github.com/ipicoin/protocolix) | Capacitor Android/iOS scaffold; wallet logic not implemented | -| Network metadata | [`chainconfig`](https://github.com/ipicoin/chainconfig) | Tested legacy configuration; not canonical current identity | -| Governance and security | [`.github`](https://github.com/ipicoin/.github) | Active bootstrap process with automated document validation | -| Website and documentation | [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) | Active development; Astro static build | -| Independent infrastructure | [`hq-spacecraft`](https://github.com/ipicoin/hq-spacecraft) | Prototype scaffold; most service compositions are placeholders | -| Product identity / secure element | [architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md), [`node-ntag424` reference fork](https://github.com/ipicoin/nikeee___node-ntag424) | Research direction; no IPI-specific implementation | -| Checkout / payment / receipt | [roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md), [`cheer-gear` reference fork](https://github.com/ipicoin/cheer-gear) | Concept and hardware scaffold; no executable IPI integration | - -## Why IPI Is Different +| Layer | What exists | Evidence | Status | +| --- | --- | --- | --- | +| Explorer | Native blocks, transactions, accounts, validators, search, and EVM diagnostics | [`explorer.js`](https://github.com/ipicoin/scan.ipi.io/blob/main/explorer.js) | Active development; implemented and publicly tested | +| EVM interface | JSON-RPC transaction, block, address, balance, nonce, and bytecode inspection | [`explorer.js`](https://github.com/ipicoin/scan.ipi.io/blob/main/explorer.js), [`evm.html`](https://github.com/ipicoin/scan.ipi.io/blob/main/evm.html) | Query integration demonstrated; IPI EVM execution suite not public | +| CosmWasm interface | Protobuf/query client surface plus inherited `wasmd` execution foundation | [`ipi-rpc` CosmWasm clients](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_web/cosmwasm), [`independency-daemon`](https://github.com/ipicoin/independency-daemon) | Upstream foundation and client integration research; IPI execution suite not public | +| Wallet core | Wallet, address, request, transaction, and contract models; Bech32 validation | [`src/models`](https://github.com/ipicoin/wallet-core.js/tree/main/src/models), [`tests`](https://github.com/ipicoin/wallet-core.js/tree/main/tests) | Active development; eleven tests pass, signing/transfer incomplete | +| RPC/API clients | Cosmos/IBC/CosmWasm protobuf inputs and two generated TypeScript transport trees | [`proto`](https://github.com/ipicoin/ipi-rpc/tree/main/proto), [`gRPC-Web`](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_web), [`gRPC-Gateway`](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_gateway) | Integration research; upstream-derived, no IPI endpoint binding | +| Protocol/node | Buildable Cosmos SDK, CometBFT, IBC, and CosmWasm application foundation | [`independency-daemon`](https://github.com/ipicoin/independency-daemon), [fork boundary](https://github.com/ipicoin/independency-daemon/blob/main/IPI_FORK_STATUS.md) | Upstream foundation; IPI consensus/application delta not public | +| Mobile client | Capacitor Android/iOS project trees and browser shell | [`protocolix`](https://github.com/ipicoin/protocolix) | Prototype scaffold; wallet behavior not implemented | +| Network metadata | Tested historical Cosmos wallet configuration | [`config.json`](https://github.com/ipicoin/chainconfig/blob/main/config.json), [`test/config.test.js`](https://github.com/ipicoin/chainconfig/blob/main/test/config.test.js) | Verified legacy record; not canonical current identity | +| Governance/security | Architecture, security policy, public change control, and automated document validation | [`.github`](https://github.com/ipicoin/.github), [IPI proposals](https://github.com/ipicoin/.github/tree/main/ipi) | Active public bootstrap process | +| Website/docs | Astro landing and Starlight documentation source | [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) | Active development; public build CI passes | +| Independent infrastructure | Self-hosted service and Compose research structure | [`hq-spacecraft`](https://github.com/ipicoin/hq-spacecraft) | Prototype scaffold; most compositions are placeholders | +| Product identity / secure element | Architecture boundary and attributed NTAG 424 reference | [architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md), [`node-ntag424` reference](https://github.com/ipicoin/nikeee___node-ntag424) | Research direction; no IPI-specific implementation | +| Checkout/payment/receipt | Roadmap boundary and attributed terminal hardware scaffold | [roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md), [`cheer-gear` reference](https://github.com/ipicoin/cheer-gear) | Concept stage; no executable IPI integration | + +## Why This Is Not Just a Token Project + +The distinction is architectural and verifiable in source. A token-only project +can stop at an asset definition, marketing site, and third-party wallet link. +IPI's public organization separately exposes: + +- a native Cosmos and EVM inspection surface; +- wallet/account models and validation tests; +- protobuf inputs and generated RPC client transports; +- an attributed node/execution foundation; +- public governance, security, architecture, and change control; +- independently operable infrastructure research; and +- explicit hardware identity, product verification, and payment boundaries. + +These layers are not equally mature, but they form one protocol-infrastructure +architecture rather than a website wrapped around a token contract. + +## Engineering Thesis IPI's engineering thesis is that infrastructure should be inspectable and replaceable at every layer: @@ -133,6 +166,20 @@ not be read as IPI-authored implementations. IPI-specific public evidence lives in the explorer, wallet model/test work, governance and architecture, configuration, documentation, and integration boundaries described above. +## Project Scope and Continuity + +IPI development is broader than the history of a single daemon repository. Its +public record is distributed across protocol-foundation evaluation, explorer +implementation, wallet models, RPC clients, network configuration, governance, +security, independent-infrastructure research, and hardware/product/payment +architecture. Some repositories were imported, rebuilt, or created at different +stages and therefore have different histories. + +This is not a claim that IPI spent four continuous years writing a blockchain +core from zero. It is the narrower, verifiable claim that IPI is being developed +as a multi-component system, and that repository age or inherited history must +not be substituted for evidence of IPI-specific work. + ## Development Status IPI is under active development. No public repository should be assumed safe From aa8b5aaa48de36c6b402efc3720a70a2d82bf00a Mon Sep 17 00:00:00 2001 From: meles Date: Mon, 24 Aug 2026 19:28:09 +0200 Subject: [PATCH 4/4] docs: make organization profile evidence-first --- REPOSITORY_AUDIT.md | 17 +-- profile/README.md | 292 ++++++++++++++++++++------------------------ 2 files changed, 140 insertions(+), 169 deletions(-) diff --git a/REPOSITORY_AUDIT.md b/REPOSITORY_AUDIT.md index 96ac6f6..dafd01c 100644 --- a/REPOSITORY_AUDIT.md +++ b/REPOSITORY_AUDIT.md @@ -151,13 +151,16 @@ different wording. GitHub does not expose organization-profile pin management through the API used for this audit. The recommended manual order is: -1. [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) -2. [`.github`](https://github.com/ipicoin/.github) +1. [`.github`](https://github.com/ipicoin/.github) +2. [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) 3. [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) 4. [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) 5. [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) -6. [`independency-daemon`](https://github.com/ipicoin/independency-daemon) - -This order puts original, runnable or tested IPI work first and leaves the -attributed upstream node foundation visible only after its current status is -clear. +6. [`chainconfig`](https://github.com/ipicoin/chainconfig) + +This order puts the architecture/evidence index first, followed by original, +runnable or tested IPI work. `protocolix` is not recommended yet because its +public application behavior is still the default Capacitor scaffold; +`independency-daemon` is not recommended because its application code remains +the upstream `wasmd` foundation. Pinning either today would strengthen the +wrong first impression despite their intended architectural roles. diff --git a/profile/README.md b/profile/README.md index c027bf7..8d23d02 100644 --- a/profile/README.md +++ b/profile/README.md @@ -8,197 +8,165 @@ IPI organizes public engineering across blockchain and network foundations, wallet and key infrastructure, a block explorer, RPC clients, node and validator integration, EVM and CosmWasm interfaces, governance and security processes, product identity and secure-element research, checkout/payment architecture, -and independently operable infrastructure. Together these layers define a path -from protocol state to user authorization, external-product verification, and -independently checkable outcomes. - -Start with the implemented and tested components below. Every primary capability -links directly to its code, tests, or governing technical document; integration -and research work is labeled separately. - -## What Exists Today - -- **A zero-dependency Cosmos/EVM testnet explorer.** - [`explorer.js`](https://github.com/ipicoin/scan.ipi.io/blob/main/explorer.js) - implements block, transaction, account, validator, native Cosmos, and EVM - JSON-RPC inspection in browser JavaScript. The repository also contains a - [local API proxy](https://github.com/ipicoin/scan.ipi.io/blob/main/dev-server.mjs), - a dedicated [EVM diagnostic view](https://github.com/ipicoin/scan.ipi.io/blob/main/evm.html), - and passing public CI. -- **A tested JavaScript wallet model layer.** - [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) contains - [wallet, address, request, transaction, and contract models](https://github.com/ipicoin/wallet-core.js/tree/main/src/models) - plus configurable Bech32 validation. Its - [seven test files](https://github.com/ipicoin/wallet-core.js/tree/main/tests) - contain eleven passing tests; signing and transfer operations remain - incomplete. -- **Cosmos RPC transport and client-generation research.** - [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) contains - [Cosmos, IBC, Tendermint, and CosmWasm protobuf inputs](https://github.com/ipicoin/ipi-rpc/tree/main/proto), - generated TypeScript clients for - [gRPC-Web](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_web) and - [gRPC-Gateway](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_gateway), - and browser comparison pages. It is an upstream-derived integration sandbox, - not an RPC server. -- **A public protocol-change and governance process.** - [`.github`](https://github.com/ipicoin/.github) contains the - [architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md), - [security policy](https://github.com/ipicoin/.github/blob/main/SECURITY.md), - [governance rules](https://github.com/ipicoin/.github/blob/main/GOVERNANCE.md), - roadmap, and IPI Improvement Proposal process. - [IPI-0000](https://github.com/ipicoin/.github/blob/main/ipi/IPI-0000.md) - defines the process; [IPI-0001](https://github.com/ipicoin/.github/blob/main/ipi/IPI-0001.md) - is a draft evidence model for verifiable independence. -- **A public node foundation with explicit provenance.** - [`independency-daemon`](https://github.com/ipicoin/independency-daemon) tracks - CosmWasm `wasmd`, built on Cosmos SDK and CometBFT. Current IPI changes are - provenance documentation and CI hardening; an IPI node release is not yet - implemented in that fork. The exact boundary is recorded in - [`IPI_FORK_STATUS.md`](https://github.com/ipicoin/independency-daemon/blob/main/IPI_FORK_STATUS.md). -- **Public product and documentation surfaces.** - [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) is the Astro source for - the website and documentation, while - [`chainconfig`](https://github.com/ipicoin/chainconfig) preserves a tested but - legacy Cosmos wallet configuration that is explicitly non-canonical. -- **Application integration sandboxes.** - [`Iswap`](https://github.com/ipicoin/Iswap), - [`Ivote`](https://github.com/ipicoin/Ivote), and - [`ipi-nft`](https://github.com/ipicoin/ipi-nft) preserve attributed Hyperweb - examples for swap, governance, and NFT workflow evaluation. They do not yet - contain IPI network integration. +and independently operable infrastructure. + +The repositories are parts of one verification path: protocol state is exposed +through open interfaces, clients authorize or inspect changes, and governance +and evidence specifications make control and trust boundaries explicit. + +## Engineering evidence + +| Layer | Publicly verifiable implementation | Strongest evidence | Current role | +| --- | --- | --- | --- | +| Explorer | Browser code for blocks, transactions, accounts, validators, search, and native Cosmos queries | [`explorer.js`](https://github.com/ipicoin/scan.ipi.io/blob/main/explorer.js) | Implemented and publicly tested | +| EVM inspection | EVM JSON-RPC query, transaction, receipt, address, balance, nonce, and bytecode inspection | [`explorer.js`](https://github.com/ipicoin/scan.ipi.io/blob/main/explorer.js), [`evm.html`](https://github.com/ipicoin/scan.ipi.io/blob/main/evm.html) | Implemented explorer integration | +| Wallet core | Wallet, address, request, transaction, and contract models plus configurable Bech32 validation | [`src/models`](https://github.com/ipicoin/wallet-core.js/tree/main/src/models), [`tests`](https://github.com/ipicoin/wallet-core.js/tree/main/tests) | Tested JavaScript model layer | +| Mobile environment | Checked-in Capacitor Android and iOS application projects with IPI package identities | [`android`](https://github.com/ipicoin/protocolix/tree/main/android), [`ios`](https://github.com/ipicoin/protocolix/tree/main/ios) | Cross-platform integration environment | +| RPC/API clients | Cosmos, IBC, Tendermint, and CosmWasm protobuf inputs, code generators, and two generated TypeScript client trees | [`proto`](https://github.com/ipicoin/ipi-rpc/tree/main/proto), [`gRPC-Web`](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_web), [`gRPC-Gateway`](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_gateway) | RPC transport research workspace | +| CosmWasm surface | Generated CosmWasm query/transaction clients and an attributed `wasmd` node foundation | [`CosmWasm clients`](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_web/cosmwasm), [`independency-daemon`](https://github.com/ipicoin/independency-daemon) | Client integration and node-foundation work | +| Network configuration | Coherent IPI chain, denomination, Bech32, and wallet metadata with an automated test | [`config.json`](https://github.com/ipicoin/chainconfig/blob/main/config.json), [`config.test.js`](https://github.com/ipicoin/chainconfig/blob/main/test/config.test.js) | Historical network configuration evidence | +| Governance and security | Public architecture, security policy, change control, roadmap, and validated IPI Improvement Proposal framework | [`GOVERNANCE.md`](https://github.com/ipicoin/.github/blob/main/GOVERNANCE.md), [`SECURITY.md`](https://github.com/ipicoin/.github/blob/main/SECURITY.md), [`IPI-0000`](https://github.com/ipicoin/.github/blob/main/ipi/IPI-0000.md) | Active public framework | +| Product identity and hardware keys | Specified boundaries for P-256/R1, WebAuthn, NFC, secure elements, attestation, privacy, and replay protection | [`ARCHITECTURE.md`](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md), [`NTAG 424 reference`](https://github.com/ipicoin/nikeee___node-ntag424) | Hardware-backed identity research direction | + +## Project map + +| Area | Repository | Current role | +| --- | --- | --- | +| Governance and architecture | [`.github`](https://github.com/ipicoin/.github) | Public architecture, security, governance, roadmap, and IPI proposal framework | +| Explorer | [`scan.ipi.io`](https://github.com/ipicoin/scan.ipi.io) | IPI block, transaction, account, validator, native Cosmos, and EVM inspection interface | +| Wallet core | [`wallet-core.js`](https://github.com/ipicoin/wallet-core.js) | JavaScript wallet/account models and configurable Cosmos-compatible address validation | +| Mobile wallet environment | [`protocolix`](https://github.com/ipicoin/protocolix) | Capacitor Android/iOS application environment for future wallet and hardware-key integration | +| RPC tooling | [`ipi-rpc`](https://github.com/ipicoin/ipi-rpc) | gRPC-Web and gRPC-Gateway client-generation workspace for IPI RPC/API integration research | +| Network configuration | [`chainconfig`](https://github.com/ipicoin/chainconfig) | Tested IPI wallet/chain metadata retained as a historical network configuration record | +| Protocol node foundation | [`independency-daemon`](https://github.com/ipicoin/independency-daemon) | Cosmos SDK, CometBFT, IBC, and CosmWasm upstream foundation used to define the IPI node integration boundary | +| Website and documentation | [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) | Astro website and Starlight documentation source for public IPI interfaces and concepts | ## Architecture -The intended verification path is broader than any one repository: +### Demonstrated in public repositories today ```text -Cosmos SDK / CometBFT / CosmWasm foundation - ↓ -IPI node integration · validator/network operation - ↓ -RPC · REST · gRPC · EVM JSON-RPC · events - ↓ -Explorer · wallet core · mobile approval · external clients - ↓ -Product identity / secure element → checkout / payment → receipt - ↓ -Independent operation, governance, and verification evidence +Attributed Cosmos / CometBFT / CosmWasm node foundation + ↓ +Generated RPC clients + direct Cosmos / CometBFT / EVM query paths + ↓ +Explorer + tested wallet models + Android/iOS application projects + ↓ +Public governance + security + evidence specifications ``` -Today, the public explorer and governance/evidence layers are concrete; wallet -models and RPC clients are partial; the public node is still an upstream -foundation; and product identity, secure-element, checkout, and payment are -research directions without a public IPI implementation. See the -[architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md) and -[complete repository audit](https://github.com/ipicoin/.github/blob/main/REPOSITORY_AUDIT.md). +This is a map of public components, not a claim that every layer already forms +a released end-to-end system. The explorer, wallet model tests, generated RPC +surfaces, native application projects, and governance framework can be inspected +today; their integration maturity is recorded below. -## Engineering Evidence +### Target architecture -| Layer | What exists | Evidence | Status | -| --- | --- | --- | --- | -| Explorer | Native blocks, transactions, accounts, validators, search, and EVM diagnostics | [`explorer.js`](https://github.com/ipicoin/scan.ipi.io/blob/main/explorer.js) | Active development; implemented and publicly tested | -| EVM interface | JSON-RPC transaction, block, address, balance, nonce, and bytecode inspection | [`explorer.js`](https://github.com/ipicoin/scan.ipi.io/blob/main/explorer.js), [`evm.html`](https://github.com/ipicoin/scan.ipi.io/blob/main/evm.html) | Query integration demonstrated; IPI EVM execution suite not public | -| CosmWasm interface | Protobuf/query client surface plus inherited `wasmd` execution foundation | [`ipi-rpc` CosmWasm clients](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_web/cosmwasm), [`independency-daemon`](https://github.com/ipicoin/independency-daemon) | Upstream foundation and client integration research; IPI execution suite not public | -| Wallet core | Wallet, address, request, transaction, and contract models; Bech32 validation | [`src/models`](https://github.com/ipicoin/wallet-core.js/tree/main/src/models), [`tests`](https://github.com/ipicoin/wallet-core.js/tree/main/tests) | Active development; eleven tests pass, signing/transfer incomplete | -| RPC/API clients | Cosmos/IBC/CosmWasm protobuf inputs and two generated TypeScript transport trees | [`proto`](https://github.com/ipicoin/ipi-rpc/tree/main/proto), [`gRPC-Web`](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_web), [`gRPC-Gateway`](https://github.com/ipicoin/ipi-rpc/tree/main/codegen_grpc_gateway) | Integration research; upstream-derived, no IPI endpoint binding | -| Protocol/node | Buildable Cosmos SDK, CometBFT, IBC, and CosmWasm application foundation | [`independency-daemon`](https://github.com/ipicoin/independency-daemon), [fork boundary](https://github.com/ipicoin/independency-daemon/blob/main/IPI_FORK_STATUS.md) | Upstream foundation; IPI consensus/application delta not public | -| Mobile client | Capacitor Android/iOS project trees and browser shell | [`protocolix`](https://github.com/ipicoin/protocolix) | Prototype scaffold; wallet behavior not implemented | -| Network metadata | Tested historical Cosmos wallet configuration | [`config.json`](https://github.com/ipicoin/chainconfig/blob/main/config.json), [`test/config.test.js`](https://github.com/ipicoin/chainconfig/blob/main/test/config.test.js) | Verified legacy record; not canonical current identity | -| Governance/security | Architecture, security policy, public change control, and automated document validation | [`.github`](https://github.com/ipicoin/.github), [IPI proposals](https://github.com/ipicoin/.github/tree/main/ipi) | Active public bootstrap process | -| Website/docs | Astro landing and Starlight documentation source | [`www.ipi.io`](https://github.com/ipicoin/www.ipi.io) | Active development; public build CI passes | -| Independent infrastructure | Self-hosted service and Compose research structure | [`hq-spacecraft`](https://github.com/ipicoin/hq-spacecraft) | Prototype scaffold; most compositions are placeholders | -| Product identity / secure element | Architecture boundary and attributed NTAG 424 reference | [architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md), [`node-ntag424` reference](https://github.com/ipicoin/nikeee___node-ntag424) | Research direction; no IPI-specific implementation | -| Checkout/payment/receipt | Roadmap boundary and attributed terminal hardware scaffold | [roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md), [`cheer-gear` reference](https://github.com/ipicoin/cheer-gear) | Concept stage; no executable IPI integration | - -## Why This Is Not Just a Token Project - -The distinction is architectural and verifiable in source. A token-only project -can stop at an asset definition, marketing site, and third-party wallet link. -IPI's public organization separately exposes: - -- a native Cosmos and EVM inspection surface; -- wallet/account models and validation tests; -- protobuf inputs and generated RPC client transports; -- an attributed node/execution foundation; -- public governance, security, architecture, and change control; -- independently operable infrastructure research; and -- explicit hardware identity, product verification, and payment boundaries. - -These layers are not equally mature, but they form one protocol-infrastructure -architecture rather than a website wrapped around a token contract. - -## Engineering Thesis - -IPI's engineering thesis is that infrastructure should be inspectable and -replaceable at every layer: +```text +Protocol / Node +→ EVM + CosmWasm execution +→ RPC / REST / gRPC / EVM JSON-RPC +→ Wallet + Explorer +→ Product Identity / P-256 / NFC / Secure Element +→ Checkout / Payment / Receipt +→ Independent Verification +``` + +These layers belong together because consensus produces state, open APIs expose +it, wallets authorize changes, explorers enable independent inspection, +hardware and product interfaces bind external events to explicit attestations, +and checkout/receipt flows can turn settlement into a checkable record. The +[architecture document](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md) +separates current implementation from target interfaces in detail. + +## More than a token layer + +The public organization contains separate repositories for protocol and network +foundations, wallet software, native mobile projects, explorer code, RPC/API +client generation, governance and security, and hardware-backed product-identity +research. Much of the low-level protocol foundation is established upstream +open source; the broader public system and its IPI-specific boundaries are not +equivalent to a token contract plus a website. + +## Engineering thesis + +IPI is designed around infrastructure that others can inspect, replace, and +operate: - **Independence:** a hosted endpoint or organization account must not silently become the only way to operate or verify the system. -- **Self-custody:** keys and signing intent belong at the user-controlled edge; - wallets must make network identity and authorized actions explicit. +- **Self-custody:** keys and signing intent belong at the user-controlled edge. - **Independent operation:** nodes, clients, explorers, and optional services - should have documented deployment, recovery, and exit paths. + need documented deployment, recovery, and exit paths. - **Reproducibility:** protocol claims should resolve to source revisions, dependency locks, build procedures, tests, and observable evidence. - **Open interfaces:** RPC, REST, gRPC, EVM JSON-RPC, events, and portable data formats are boundaries that independent implementations can reproduce. - **Transparent governance:** protocol and trust changes belong in public, - versioned proposals with security, compatibility, and operational analysis. + versioned proposals with security and compatibility analysis. - **Hardware-backed identity direction:** P-256/R1, NFC, and secure-element work - is treated as a separate attestation and privacy problem, not as a marketing - shortcut or a reason to put secret data on-chain. + is treated as a separate attestation and privacy problem, with secrets kept + off-chain. -These are design requirements and research goals, not a claim that every layer -is complete or independently operated today. - -## Upstream Foundations +## Upstream foundations IPI deliberately evaluates established open-source foundations including Cosmos SDK, CometBFT, CosmWasm, `wasmd`, Ethereum tooling, WebAuthn, and secure -hardware libraries. Using upstream infrastructure is normal protocol -engineering: it provides reviewed interfaces, interoperability, and a visible -history to build on. - -Attribution is explicit. Twenty-six public IPI forks currently contain no -commits ahead of upstream. `independency-daemon` has two IPI commits limited to -fork provenance and CI hardening. These forks are research references and must -not be read as IPI-authored implementations. IPI-specific public evidence lives -in the explorer, wallet model/test work, governance and architecture, -configuration, documentation, and integration boundaries described above. - -## Project Scope and Continuity - -IPI development is broader than the history of a single daemon repository. Its -public record is distributed across protocol-foundation evaluation, explorer -implementation, wallet models, RPC clients, network configuration, governance, -security, independent-infrastructure research, and hardware/product/payment -architecture. Some repositories were imported, rebuilt, or created at different -stages and therefore have different histories. - -This is not a claim that IPI spent four continuous years writing a blockchain -core from zero. It is the narrower, verifiable claim that IPI is being developed -as a multi-component system, and that repository age or inherited history must -not be substituted for evidence of IPI-specific work. +hardware libraries. Their use provides reviewed interfaces, interoperability, +and visible development history. Licenses and provenance remain explicit; IPI +does not claim upstream code as original work. + +The public audit found that most forks have no IPI commits. The node tracking +fork currently adds provenance documentation and CI hardening rather than an +IPI consensus or application delta. IPI-specific public evidence is concentrated +in the explorer, wallet models and tests, governance and architecture, network +configuration, website, and integration work. See the +[complete repository audit](../REPOSITORY_AUDIT.md) +for the per-repository boundary. ## Development Status -IPI is under active development. No public repository should be assumed safe -for production assets unless a versioned release explicitly documents its -threat model, compatibility, reproducible build, tests, security review, and -support lifecycle. - -The main public evidence gaps are a consolidated IPI-specific node source and -genesis binding, public validator/deployment tooling, completed wallet signing -flows, reproducible releases, and public implementations for product identity, -secure-element attestation, checkout, payment, and receipts. The -[roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md) defines the -evidence expected before stronger maturity claims. - -## Start Here +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. + +Precise current classifications: + +- `scan.ipi.io` is an implemented explorer under active development. +- `wallet-core.js` is a tested model/validation layer; signing, transaction, + fee, and recovery workflows remain incomplete. +- `protocolix` is a cross-platform prototype scaffold; wallet, NFC, and + secure-key behavior is not implemented in its public source. +- `ipi-rpc` is an upstream-derived RPC client-generation research workspace; + it is not an IPI RPC server. +- `independency-daemon` is an attributed upstream node foundation; a public + IPI-specific node release and validator/sentry deployment remain incomplete. +- `chainconfig` is tested historical metadata, not a canonical current network + identity. +- product identity, secure-element attestation, checkout, payment, and receipt + remain research or target-architecture layers without public IPI-specific + implementations. + +The public repositories do not yet contain a versioned, reproducible artifact +that ties IPI block production, native EVM transfers, EVM contract deployment, +or CosmWasm upload/execution to a specific public IPI node revision. Those +execution claims are therefore not presented as completed evidence here. + +IPI's development record spans protocol-foundation evaluation, network +configuration, explorer and wallet work, RPC clients, governance, security, +infrastructure research, hardware/product-identity architecture, payments, and +migrations or rebuilds. This is not a claim that the current public GitHub proves +four continuous years of original blockchain-core development. + +The [roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md) defines +the evidence required before stronger maturity claims. + +## Start here [Explorer](https://github.com/ipicoin/scan.ipi.io) · [Architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.md) · -[Repository audit](https://github.com/ipicoin/.github/blob/main/REPOSITORY_AUDIT.md) · +[Repository audit](../REPOSITORY_AUDIT.md) · [Governance](https://github.com/ipicoin/.github/blob/main/GOVERNANCE.md) · [IPI proposals](https://github.com/ipicoin/.github/tree/main/ipi) · [Roadmap](https://github.com/ipicoin/.github/blob/main/ROADMAP.md) ·