diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index 35a9880..f4b139a 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -1,105 +1,149 @@ # 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 +``` + +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 | +| --- | --- | --- | +| 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 +157,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..dafd01c --- /dev/null +++ b/REPOSITORY_AUDIT.md @@ -0,0 +1,166 @@ +# 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; 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; 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`; 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 | + +## 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. +- 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. + +## 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. + +## 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 +for this audit. The recommended manual order is: + +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. [`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 191ce94..8d23d02 100644 --- a/profile/README.md +++ b/profile/README.md @@ -1,105 +1,174 @@ # IPI — Independent Protocol Infrastructure -### Infrastructure for systems that can be independently operated, verified, and extended. +**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. + +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 | -**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: +## Project map -- 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. +| 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 + +### Demonstrated in public repositories today + +```text +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 +``` + +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. + +### Target architecture + +```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. +- **Independent operation:** nodes, clients, explorers, and optional services + 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 and compatibility analysis. +- **Hardware-backed identity direction:** P-256/R1, NFC, and secure-element work + is treated as a separate attestation and privacy problem, with secrets kept + off-chain. + +## Upstream foundations + +IPI deliberately evaluates established open-source foundations including +Cosmos SDK, CometBFT, CosmWasm, `wasmd`, Ethereum tooling, WebAuthn, and secure +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 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). +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 -- 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 | -| --- | --- | --- | -| 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](https://github.com/ipicoin/scan.ipi.io) · +[Architecture](https://github.com/ipicoin/.github/blob/main/ARCHITECTURE.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) · +[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",