From 858d452cad5753c3f6eae90466dbe7f87f86801a Mon Sep 17 00:00:00 2001
From: ipicoinrepo <119383174+ipicoinrepo@users.noreply.github.com>
Date: Wed, 15 Jul 2026 04:58:09 +0200
Subject: [PATCH] docs: establish IPI open-source foundation
---
.github/ISSUE_TEMPLATE/bug_report.yml | 84 +++++
.github/ISSUE_TEMPLATE/config.yml | 14 +
.github/ISSUE_TEMPLATE/feature_request.yml | 68 ++++
.github/PULL_REQUEST_TEMPLATE.md | 46 +++
.github/dependabot.yml | 11 +
.github/workflows/blank.yml | 44 +--
AGENTS.md | 104 +++++-
ARCHITECTURE.md | 125 ++++++++
CODE_OF_CONDUCT.md | 55 ++++
CONTRIBUTING.md | 105 +++++++
GOVERNANCE.md | 112 +++++++
LICENSING.md | 35 +++
MAINTAINERS.md | 66 ++++
README.md | 61 +++-
ROADMAP.md | 113 +++++++
SECURITY.md | 64 ++++
SUPPORT.md | 23 ++
ipi/IPI-0000.md | 284 +++++++++++++++++
ipi/IPI-0001.md | 347 +++++++++++++++++++++
ipi/IPI-template.md | 78 +++++
ipi/README.md | 54 ++++
profile/README.md | 111 ++++++-
scripts/check_community.py | 165 ++++++++++
workflows/blank.yml | 49 +--
24 files changed, 2140 insertions(+), 78 deletions(-)
create mode 100644 .github/ISSUE_TEMPLATE/bug_report.yml
create mode 100644 .github/ISSUE_TEMPLATE/config.yml
create mode 100644 .github/ISSUE_TEMPLATE/feature_request.yml
create mode 100644 .github/PULL_REQUEST_TEMPLATE.md
create mode 100644 .github/dependabot.yml
create mode 100644 ARCHITECTURE.md
create mode 100644 CODE_OF_CONDUCT.md
create mode 100644 CONTRIBUTING.md
create mode 100644 GOVERNANCE.md
create mode 100644 LICENSING.md
create mode 100644 MAINTAINERS.md
create mode 100644 ROADMAP.md
create mode 100644 SECURITY.md
create mode 100644 SUPPORT.md
create mode 100644 ipi/IPI-0000.md
create mode 100644 ipi/IPI-0001.md
create mode 100644 ipi/IPI-template.md
create mode 100644 ipi/README.md
create mode 100644 scripts/check_community.py
diff --git a/.github/ISSUE_TEMPLATE/bug_report.yml b/.github/ISSUE_TEMPLATE/bug_report.yml
new file mode 100644
index 0000000..92446b6
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.yml
@@ -0,0 +1,84 @@
+name: Bug report
+description: Report a reproducible defect in an IPI component
+title: "bug: "
+labels:
+ - bug
+body:
+ - type: markdown
+ attributes:
+ value: |
+ Thank you for helping improve IPI. Search existing reports first.
+ Do not report vulnerabilities here; use the private Security process.
+
+ - type: input
+ id: component
+ attributes:
+ label: Component
+ description: Repository, package, application, module, or endpoint
+ placeholder: ipicoin/repository — component
+ validations:
+ required: true
+
+ - type: input
+ id: version
+ attributes:
+ label: Version
+ description: Release, commit SHA, build identifier, or network identity
+ placeholder: Commit SHA or exact version
+ validations:
+ required: true
+
+ - type: textarea
+ id: expected
+ attributes:
+ label: Expected behavior
+ description: What should have happened?
+ validations:
+ required: true
+
+ - type: textarea
+ id: actual
+ attributes:
+ label: Actual behavior
+ description: What happened instead?
+ validations:
+ required: true
+
+ - type: textarea
+ id: reproduce
+ attributes:
+ label: Minimal reproduction
+ description: Exact steps, commands, inputs, and configuration with secrets removed
+ placeholder: |
+ 1. Start from...
+ 2. Run...
+ 3. Observe...
+ validations:
+ required: true
+
+ - type: textarea
+ id: environment
+ attributes:
+ label: Environment
+ description: Operating system, architecture, runtime, dependencies, and relevant network configuration
+ validations:
+ required: true
+
+ - type: textarea
+ id: evidence
+ attributes:
+ label: Logs and evidence
+ description: Paste the smallest useful output after removing secrets and personal data
+ render: shell
+
+ - type: checkboxes
+ id: checks
+ attributes:
+ label: Submission checks
+ options:
+ - label: I searched existing issues and Discussions.
+ required: true
+ - label: This report contains no secret, private key, seed phrase, or personal data.
+ required: true
+ - label: This is not a security vulnerability.
+ required: true
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
new file mode 100644
index 0000000..6648af9
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -0,0 +1,14 @@
+blank_issues_enabled: false
+
+contact_links:
+ - name: Questions and design discussions
+ url: https://github.com/orgs/ipicoin/discussions
+ about: Ask for help or discuss an idea before opening an implementation issue.
+
+ - name: Report a security vulnerability
+ url: https://github.com/ipicoin/.github/security/advisories/new
+ about: Send suspected vulnerabilities privately. Do not open a public issue.
+
+ - name: Read the IPI proposal process
+ url: https://github.com/ipicoin/.github/tree/main/ipi
+ about: Use an IPI Improvement Proposal for protocol, compatibility, trust, or governance changes.
diff --git a/.github/ISSUE_TEMPLATE/feature_request.yml b/.github/ISSUE_TEMPLATE/feature_request.yml
new file mode 100644
index 0000000..69fbbdc
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.yml
@@ -0,0 +1,68 @@
+name: Feature request
+description: Propose a bounded improvement grounded in a concrete problem
+title: "feat: "
+labels:
+ - enhancement
+body:
+ - type: markdown
+ attributes:
+ value: |
+ Describe the problem before the solution. Protocol, compatibility,
+ governance, or cross-repository changes may require an IPI proposal.
+
+ - type: textarea
+ id: problem
+ attributes:
+ label: Problem
+ description: Who is affected, what cannot be done, and what evidence shows the need?
+ validations:
+ required: true
+
+ - type: textarea
+ id: outcome
+ attributes:
+ label: Desired outcome
+ description: Define observable success without prescribing unnecessary implementation details
+ validations:
+ required: true
+
+ - type: textarea
+ id: proposal
+ attributes:
+ label: Proposed approach
+ description: Describe a bounded approach, public interfaces, and relevant constraints
+
+ - type: textarea
+ id: alternatives
+ attributes:
+ label: Alternatives
+ description: Include existing workarounds and the option of making no change
+ validations:
+ required: true
+
+ - type: textarea
+ id: independence
+ attributes:
+ label: Independence, security, and operational impact
+ description: Does this add a coordinator, key holder, provider, oracle, service, or other required dependency?
+ validations:
+ required: true
+
+ - type: checkboxes
+ id: contribution
+ attributes:
+ label: Contribution
+ options:
+ - label: I can help specify this change.
+ - label: I can help implement or test this change.
+ - label: I can help document this change.
+
+ - type: checkboxes
+ id: checks
+ attributes:
+ label: Submission checks
+ options:
+ - label: I searched existing issues, Discussions, and IPI proposals.
+ required: true
+ - label: I described a problem and a verifiable outcome.
+ required: true
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
new file mode 100644
index 0000000..77ee174
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,46 @@
+## Summary
+
+Describe the problem and the outcome of this change.
+
+## Why this belongs in IPI
+
+Explain the user, operator, protocol, or contributor need. Link the issue,
+Discussion, or IPI proposal.
+
+Closes:
+
+## Change type
+
+- [ ] Bug fix
+- [ ] Feature
+- [ ] Documentation
+- [ ] Refactor or maintenance
+- [ ] Security hardening with no embargoed details
+- [ ] IPI proposal or implementation
+- [ ] Breaking or migration-requiring change
+
+## Verification
+
+List the exact checks, tests, environments, and results. Attach reproducible
+evidence for performance or independence claims.
+
+## Compatibility and operations
+
+Describe API, consensus, data, dependency, deployment, upgrade, rollback, and
+operator effects. Write “none” only after considering each area.
+
+## Security and privacy
+
+Identify changed trust boundaries, privileged roles, keys, data exposure, or
+failure modes. Do not disclose an unpatched vulnerability here.
+
+## Checklist
+
+- [ ] I kept the change focused and reviewed the complete diff.
+- [ ] Tests cover the behavior or I explained why no test applies.
+- [ ] Documentation and migration guidance are updated.
+- [ ] No secret, seed phrase, private key, personal data, or private endpoint is included.
+- [ ] Third-party licenses, notices, and upstream attribution are preserved.
+- [ ] Claims are supported by a reproducible method and evidence.
+- [ ] A required IPI proposal is linked, or this change does not require one.
+- [ ] I read the Code of Conduct and contributor guidance.
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
new file mode 100644
index 0000000..d7fb332
--- /dev/null
+++ b/.github/dependabot.yml
@@ -0,0 +1,11 @@
+version: 2
+
+updates:
+ - package-ecosystem: github-actions
+ directory: /
+ schedule:
+ interval: monthly
+ labels:
+ - dependencies
+ - github-actions
+ open-pull-requests-limit: 5
diff --git a/.github/workflows/blank.yml b/.github/workflows/blank.yml
index 01502b1..dc6c871 100644
--- a/.github/workflows/blank.yml
+++ b/.github/workflows/blank.yml
@@ -1,36 +1,26 @@
-# This is a basic workflow to help you get started with Actions
+name: Community standards
-name: CI
-
-# Controls when the workflow will run
on:
- # Triggers the workflow on push or pull request events but only for the "main" branch
- push:
- branches: [ "main" ]
pull_request:
- branches: [ "main" ]
+ push:
+ branches:
+ - main
- # Allows you to run this workflow manually from the Actions tab
- workflow_dispatch:
+permissions:
+ contents: read
+
+concurrency:
+ group: community-standards-${{ github.ref }}
+ cancel-in-progress: true
-# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
- # This workflow contains a single job called "build"
- build:
- # The type of runner that the job will run on
+ validate:
+ name: Community standards
runs-on: ubuntu-latest
-
- # Steps represent a sequence of tasks that will be executed as part of the job
+ timeout-minutes: 5
steps:
- # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- - uses: actions/checkout@v4
-
- # Runs a single command using the runners shell
- - name: Run a one-line script
- run: echo Hello, world!
+ - name: Check out the repository
+ uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
- # Runs a set of commands using the runners shell
- - name: Run a multi-line script
- run: |
- echo Add other actions to build,
- echo test, and deploy your project.
+ - name: Validate community and proposal files
+ run: python3 scripts/check_community.py
diff --git a/AGENTS.md b/AGENTS.md
index 123c17d..9ccf968 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1 +1,103 @@
-# SELF-IMPROOVE AND SPREAD YOUR BEST KNOWN CONTENTS OF THIS GUIDEFILES
+# Working in the IPI GitHub organization
+
+These instructions apply to automated coding agents and human contributors
+working in this repository.
+
+## Mission
+
+Help IPI become protocol infrastructure that unrelated people can operate,
+verify, reproduce, and extend. Prefer working evidence over slogans. Keep the
+current distinction between implemented, experimental, planned, and unknown
+behavior visible.
+
+Read before changing the repository:
+
+1. [README.md](README.md)
+2. [CONTRIBUTING.md](CONTRIBUTING.md)
+3. [GOVERNANCE.md](GOVERNANCE.md)
+4. [SECURITY.md](SECURITY.md)
+5. [LICENSING.md](LICENSING.md)
+6. [IPI-0000](ipi/IPI-0000.md) and, for independence claims,
+ [IPI-0001](ipi/IPI-0001.md)
+
+More specific AGENTS.md files override this file within their directories.
+
+## Non-negotiable safeguards
+
+- Never publish a secret, seed phrase, private key, access token, recovery code,
+ private endpoint, customer record, or unrelated personal data.
+- Never push directly to a protected default branch. Use a focused feature
+ branch and a pull request.
+- Do not delete repositories, branches, tags, releases, or history unless the
+ user explicitly authorizes that exact destructive action.
+- Do not rewrite public history to hide a leaked secret; rotate the secret first
+ and follow the private security process.
+- Do not relicense or remove third-party attribution without documented rights.
+- Do not describe a component as production-ready, independent, audited,
+ decentralized, or performance-leading without reproducible evidence.
+- Preserve unrelated user changes in a dirty working tree.
+
+## Bringing code into an IPI repository
+
+Before publishing code:
+
+1. Identify the correct destination repository and read its local instructions.
+2. Inspect Git status, branches, remotes, commit history, and existing user
+ changes.
+3. Inventory licenses, upstream origins, generated files, large binaries, and
+ contributor notices.
+4. Scan the complete candidate tree and history for credentials and private
+ information without printing discovered secret values.
+5. Confirm that the destination license is explicit and compatible. If it is
+ missing or uncertain, stop before publishing and open a licensing decision.
+6. Run the repository's tests, linters, builds, and security checks.
+7. Create a narrowly named branch from the current default branch.
+8. Make small attributable commits with clear subjects.
+9. Push only the feature branch and open a pull request using the template.
+10. Link the relevant issue, Discussion, or IPI proposal and include exact test
+ results, compatibility effects, known limitations, and rollback notes.
+
+If the source is an existing Git repository, preserve its useful history and
+upstream relationship instead of copying an unattributed snapshot. Never merge
+unrelated histories merely to make a push succeed.
+
+## Change classification
+
+Use an ordinary pull request for local fixes, tests, documentation, and
+implementation of an already accepted design. Start or update an IPI
+Improvement Proposal for consensus, cryptography, accounts, public interfaces,
+compatibility, governance, trust assumptions, or coordinated changes across
+repositories.
+
+Security-sensitive work follows [SECURITY.md](SECURITY.md) and may require a
+private fork or security advisory instead of a public branch.
+
+## Required validation
+
+For this repository, run:
+
+~~~shell
+python3 scripts/check_community.py
+git diff --check
+~~~
+
+For another repository, run every check documented there. Do not claim a check
+passed if it was skipped, unavailable, flaky, or run against a different
+revision.
+
+## Pull request handoff
+
+The final handoff must state:
+
+- the branch and commit;
+- the files and behavior changed;
+- the exact validation performed and its result;
+- security, privacy, license, migration, and operational effects;
+- anything not verified; and
+- the next safe action required from a maintainer.
+
+Do not merge your own material change as its only reviewer unless an
+organization owner has explicitly authorized a documented bootstrap change and
+the branch rules allow it. If the project does not yet have an independent
+reviewer, keep technical proposals in Draft, state the limitation plainly, and
+record the bootstrap authorization in the pull request.
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
new file mode 100644
index 0000000..35a9880
--- /dev/null
+++ b/ARCHITECTURE.md
@@ -0,0 +1,125 @@
+# 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.
+
+## 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.
+
+## Target layers
+
+~~~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.
+
+## Component boundaries
+
+### Protocol node
+
+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.
+
+### 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.
+
+### 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.
+
+### Checkout and receipts
+
+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.
+
+### Explorers, indexers, and public APIs
+
+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.
+
+### Interoperability and anchoring
+
+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.
+
+## Current maturity
+
+| 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.
+
+## Design rules
+
+1. **Verify at the edge.** A wallet, operator, or application should be able to
+ check important claims without trusting the service that presented them.
+2. **Keep consensus deterministic.** External calls, private services, and
+ nondeterministic inputs do not belong inside consensus state transitions.
+3. **Make authority explicit.** Keys, allowlists, issuers, upgrades, recovery,
+ and emergency actions are documented control points.
+4. **Keep secrets off-chain.** Publish proofs and lifecycle state, not signing
+ 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
+ provider or local-operation path.
+7. **Design the exit before the launch.** Recovery, migration, shutdown, and
+ continuity are protocol requirements.
+
+## 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.
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 0000000..93fa6fd
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,55 @@
+# IPI Code of Conduct
+
+IPI depends on rigorous disagreement, shared evidence, and respect for the
+people doing the work. This Code of Conduct applies to all project spaces,
+including repositories, issues, pull requests, Discussions, events, and
+project-related private communication.
+
+## Expected behavior
+
+Community participants are expected to:
+
+- discuss ideas and evidence without attacking people;
+- make technical criticism specific, actionable, and proportionate;
+- welcome questions and explain project conventions without gatekeeping;
+- disclose relevant conflicts of interest;
+- respect privacy, attribution, licenses, and responsible disclosure;
+- accept correction and repair harm when a mistake is made; and
+- help maintain a space in which people can contribute regardless of
+ background, identity, experience, location, or native language.
+
+## Unacceptable behavior
+
+The following is not acceptable:
+
+- harassment, threats, discrimination, stalking, or sexualized attention;
+- insults, personal attacks, deliberate humiliation, or sustained disruption;
+- publishing another person's private information without permission;
+- impersonation, deceptive attribution, or manipulation of project decisions;
+- pressuring someone to reveal credentials, identity, or private security
+ information; or
+- retaliation against a good-faith report.
+
+Bad-faith use of process, repeated low-effort disruption, and knowingly false
+technical or security claims may also result in moderation.
+
+## Reporting
+
+Report conduct concerns privately to [hello@ipi.io](mailto:hello@ipi.io) with
+the subject “Code of Conduct”. Include links, dates, context, and any immediate
+safety concern. Do not investigate or publish sensitive evidence yourself.
+
+Reports will be limited to the people needed to assess and address them.
+Conflicts of interest must be disclosed and the conflicted responder must step
+away. Project maintainers will aim to acknowledge reports promptly, gather the
+minimum necessary facts, and communicate the outcome when it is safe to do so.
+
+## Enforcement
+
+Responses may include clarification, a private warning, content moderation,
+temporary participation limits, removal of project access, or a permanent ban.
+The response will consider severity, pattern, impact, intent, and willingness to
+repair harm. Immediate protective action may be taken before a complete review.
+
+Project owners are responsible for enforcement. Maintainers are responsible for
+escalating reports they cannot handle impartially.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..caff4e2
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,105 @@
+# Contributing to IPI
+
+Thank you for helping build infrastructure that people can operate and verify
+for themselves. Contributions are welcome across protocol engineering,
+security, documentation, product design, testing, operations, and research.
+
+IPI is early-stage. Clear problem statements, reproducible evidence, and small
+reviewable changes are more valuable than broad claims or large undocumented
+rewrites.
+
+## Choose the right path
+
+- Ask usage and architecture questions in
+ [GitHub Discussions](https://github.com/orgs/ipicoin/discussions).
+- Report a reproducible bug in the repository where it occurs.
+- Suggest a bounded enhancement with the feature request template.
+- Use an [IPI Improvement Proposal](ipi/README.md) for protocol behavior,
+ compatibility, governance, security assumptions, or changes spanning multiple
+ repositories.
+- Follow [SECURITY.md](SECURITY.md) instead of opening a public issue for a
+ suspected vulnerability.
+
+If you are unsure where a change belongs, start a Discussion. A maintainer can
+help narrow the scope before implementation work begins.
+
+## Before writing code
+
+1. Search existing issues, Discussions, pull requests, and IPI proposals.
+2. Confirm the repository maturity and read its local contributing guide.
+3. For a substantial change, agree on the problem and acceptance criteria
+ before opening a large pull request.
+4. Check [LICENSING.md](LICENSING.md). Do not copy code, media, or text unless
+ its license is compatible and its provenance can be preserved.
+
+## Development workflow
+
+1. Fork the repository and branch from its current default branch.
+2. Keep one logical change per branch.
+3. Add or update tests for behavior changes.
+4. Update user, operator, API, and migration documentation where applicable.
+5. Run the repository's documented checks locally.
+6. Open a pull request using the provided template and link the issue or IPI.
+
+Use concise commit subjects in the imperative mood, for example:
+
+~~~text
+feat(wallet): verify network identity before signing
+fix(node): reject inconsistent chain configuration
+docs(ipi): define evidence for operator diversity
+~~~
+
+Conventional Commit prefixes are encouraged but not required. A clean,
+explainable history is required.
+
+## Pull request expectations
+
+A reviewable pull request:
+
+- explains the problem, not only the implementation;
+- states how the result was verified;
+- identifies compatibility, migration, security, and operational effects;
+- avoids unrelated formatting or generated-file churn;
+- contains no credentials, personal data, private endpoints, or chain keys;
+- preserves copyright notices and upstream attribution; and
+- does not make performance, decentralization, security, or readiness claims
+ without reproducible evidence.
+
+Draft pull requests are encouraged for early technical feedback. A pull request
+is ready to merge only when its checks pass, review conversations are resolved,
+and the required reviewers approve it.
+
+## Tests and evidence
+
+Tests should be deterministic and should fail for the behavior they protect.
+Performance claims require the workload, configuration, hardware, raw result,
+and reproduction procedure. Network-independence claims require evidence under
+[IPI-0001](ipi/IPI-0001.md); latency alone is not sufficient.
+
+Screenshots can support a user-interface change but do not replace behavioral
+tests. For protocol changes, include upgrade and rollback considerations.
+
+## AI-assisted contributions
+
+The contributor remains responsible for every submitted line. Review generated
+changes for correctness, licensing, security, hidden dependencies, and
+unnecessary scope. State material use of generated code or content in the pull
+request when it affects provenance or review.
+
+## Review and decision-making
+
+Maintainers evaluate correctness, safety, scope, evidence, compatibility, and
+alignment with the accepted roadmap. Review is technical, not personal.
+Maintainers may ask that a broad pull request be split or moved into an IPI.
+
+Submitting a contribution does not guarantee acceptance. Decisions follow
+[GOVERNANCE.md](GOVERNANCE.md), and conduct follows
+[CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).
+
+## Licensing of contributions
+
+Each repository must state its own license. By submitting a contribution, you
+represent that you have the right to submit it under that repository's stated
+terms. If a repository has no explicit license, do not assume permission to
+reuse or redistribute its contents; open a licensing issue before making a
+substantial contribution.
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
new file mode 100644
index 0000000..0cdaa83
--- /dev/null
+++ b/GOVERNANCE.md
@@ -0,0 +1,112 @@
+# IPI Governance
+
+This document defines how the IPI open-source project makes technical and
+community decisions. It governs project repositories and processes; it does not
+claim to be on-chain governance and does not give a token, company, or informal
+title authority over the project.
+
+## Principles
+
+IPI governance should be:
+
+- **evidence-led** — important claims and decisions must be reproducible;
+- **open by default** — normal decisions happen in public issues, Discussions,
+ pull requests, and IPI proposals;
+- **least-authority** — access and emergency powers should be narrow, visible,
+ and reviewable;
+- **reversible where possible** — experiments should have exit and rollback
+ paths;
+- **attributable** — upstream work and contributor decisions remain traceable;
+ and
+- **independence-oriented** — changes should reduce hidden coordinators and make
+ independent operation easier to verify.
+
+## Roles
+
+### Contributors
+
+Anyone who participates constructively. Contributors can open issues,
+Discussions, pull requests, reviews, and IPI proposals.
+
+### Reviewers
+
+Contributors with demonstrated knowledge of an area who provide substantive
+review. Reviewers do not gain merge or administrative access automatically.
+
+### Maintainers
+
+People trusted with merge access for a defined repository or component.
+Maintainers triage work, protect compatibility and security, review changes,
+and steward releases. They must follow [MAINTAINERS.md](MAINTAINERS.md).
+
+### Security responders
+
+A small group with access to private vulnerability reports. They coordinate
+validation, remediation, and disclosure and must avoid conflicts of interest.
+
+### Organization owners
+
+Custodians of GitHub organization settings, recovery, permissions, and legal or
+security escalation. Ownership is an infrastructure responsibility, not
+automatic technical authority.
+
+The current GitHub permission configuration is the authoritative access record.
+Titles in documents never grant access by themselves.
+
+## Decision paths
+
+### Routine repository changes
+
+Bug fixes, tests, documentation, and bounded implementation changes use normal
+pull-request review. The repository's branch rules and CODEOWNERS, when present,
+define the minimum approval requirements.
+
+### Substantial changes
+
+Protocol behavior, public interfaces, consensus rules, compatibility,
+cryptography, trust assumptions, governance, or coordinated changes across
+repositories require an [IPI Improvement Proposal](ipi/README.md).
+
+Implementation can begin experimentally before a proposal is accepted, but
+acceptance must not be implied and production compatibility must not depend on
+an unaccepted proposal.
+
+### Security changes
+
+Security fixes may be developed privately and merged with limited advance
+detail. The reasoning, affected versions, and credit should be published after
+coordinated disclosure when doing so is safe.
+
+### Urgent operational action
+
+An organization owner may temporarily restrict access, disable a compromised
+workflow, protect a branch, rotate credentials, or take another bounded action
+to prevent immediate harm. The action must be documented after containment,
+with sensitive details withheld only as long as necessary.
+
+## Reaching a decision
+
+The preferred outcome is reasoned consensus: objections are answered with
+evidence or the proposal changes. Consensus does not require unanimity.
+
+If material disagreement remains, maintainers record the alternatives, risks,
+and rationale. An accepted IPI requires approval from the maintainers
+responsible for every affected component and no unresolved blocking security or
+licensing issue. A maintainer must not approve their own change as the only
+reviewer.
+
+When the project lacks enough independent maintainers for this rule, a proposal
+remains Draft or Review rather than creating the appearance of independent
+approval.
+
+## Conflicts of interest
+
+Decision-makers must disclose financial, employment, personal, or security
+interests that a reasonable contributor could view as affecting judgment. A
+conflicted person may provide facts but should not be the deciding reviewer.
+
+## Changes to governance
+
+Material changes to this document use the IPI process. Administrative fixes,
+broken links, and clarifications that do not change authority may use an ordinary
+pull request.
diff --git a/LICENSING.md b/LICENSING.md
new file mode 100644
index 0000000..7556944
--- /dev/null
+++ b/LICENSING.md
@@ -0,0 +1,35 @@
+# IPI Licensing Policy
+
+Open source requires an explicit license. Public visibility alone does not grant
+permission to use, modify, or redistribute a repository.
+
+## Repository requirements
+
+Before an IPI repository is described as open source, it must:
+
+1. contain a license file approved for the code and content it actually holds;
+2. identify important third-party code and preserve its notices and history;
+3. document any differently licensed documentation, media, data, or generated
+ artifacts; and
+4. avoid relicensing material unless the necessary rights are documented.
+
+Repositories without a license must be treated as **license pending**, even if
+they are public. Contributors should not assume a default license.
+
+## Upstream forks
+
+IPI uses and experiments with upstream open-source software. A fork must retain
+the upstream license, copyright notices, contributor history, and a clear link
+to its source. IPI-specific modifications should be distinguishable in commits
+and release notes. A fork must not be presented as original IPI work.
+
+## Original IPI work
+
+The license for original code and specifications must be selected deliberately
+by the relevant rights holders. Code, protocol specifications, documentation,
+brands, and media may require different licenses. Until those decisions are
+recorded, no automated process should add a blanket license across existing
+repositories.
+
+License questions should be raised publicly as issues unless they contain
+private legal or contributor information.
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
new file mode 100644
index 0000000..1213173
--- /dev/null
+++ b/MAINTAINERS.md
@@ -0,0 +1,66 @@
+# IPI Maintainer Policy
+
+Maintainers are stewards of defined components, not owners of community work.
+Their responsibility is to keep contributions reviewable, releases verifiable,
+and authority narrow enough that the project can survive individual departures.
+
+## Becoming a maintainer
+
+A candidate should demonstrate:
+
+- sustained, high-quality contributions in the relevant area;
+- reliable review and respectful communication;
+- sound security, compatibility, and licensing judgment;
+- willingness to document decisions and help other contributors grow; and
+- availability consistent with the component's maintenance needs.
+
+Nomination should happen publicly. Granting write or admin access requires
+approval from at least two existing maintainers or, while the project has fewer
+than two independent maintainers, an organization owner plus a documented plan
+to remove that bootstrap exception.
+
+## Access rules
+
+- Use an individual GitHub account, a unique credential, and two-factor
+ authentication.
+- Do not share passwords, access tokens, signing keys, or recovery codes.
+- Grant the least privilege needed for the role.
+- Use pull requests for normal changes; do not bypass branch rules for
+ convenience.
+- Keep release and infrastructure credentials outside source repositories.
+- Review access after role changes and at least every six months.
+
+Organization-owner access should be separate from routine development wherever
+practical. Bots and service accounts must have a documented owner, purpose,
+scope, and removal procedure.
+
+## Review and releases
+
+Maintainers must not be the sole approver of their own material changes. Changes
+to consensus, cryptography, releases, signing, permissions, or security require
+independent review appropriate to the risk.
+
+A release should identify its source revision, build procedure, dependency
+versions, artifacts and checksums, compatibility, known limitations, and
+upgrade or rollback path. A public endpoint is not evidence of release quality.
+
+## Inactivity and removal
+
+Maintainers may step down at any time. Access may be reduced after sustained
+inactivity, a role change, a security concern, repeated policy violations, or a
+request from the maintainer. Removal should preserve attribution and should be
+documented without exposing private information.
+
+Compromised or abandoned access may be suspended immediately and reviewed after
+containment.
+
+## Current maintainer record
+
+Until repository-specific maintainer teams are published, GitHub repository and
+team permissions are the authoritative record. Each active repository should
+add a public maintainer section or CODEOWNERS file once at least two responsible
+reviewers have accepted the role.
+
+General coordination: [GitHub Discussions](https://github.com/orgs/ipicoin/discussions)
+
+Private security or access concern: [hello@ipi.io](mailto:hello@ipi.io)
diff --git a/README.md b/README.md
index 579b263..e76130c 100644
--- a/README.md
+++ b/README.md
@@ -1,8 +1,57 @@
-# IPI on github
+# IPI community standards
+This repository is the public entry point for the
+[IPI GitHub organization](https://github.com/ipicoin). It contains the
+organization profile, contributor standards, governance rules, security policy,
+roadmap, and the IPI Improvement Proposal process.
-#### documented statements by __IPI DAO__
-- [Branding notice](./statements/BRANDING_NOTICE.md)
-- [Privacy policy](./statements/PRIVACY_POLICY.md)
-- [Terms of service](./statements/TERMS_OF_SERVICE.md)
-- [Terms of sales](./statements/TERMS_OF_SALES.md)
\ No newline at end of file
+GitHub automatically uses supported community-health files from this repository
+as defaults for organization repositories that do not define their own.
+Repository-specific instructions always take precedence.
+
+## Documentation
+
+| Document | Purpose |
+| --- | --- |
+| [Organization profile](profile/README.md) | Public mission, project map, and entry points |
+| [Architecture](ARCHITECTURE.md) | Target layers, trust boundaries, and current maturity |
+| [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 |
+| [Support](SUPPORT.md) | Where to ask questions and report problems |
+| [Governance](GOVERNANCE.md) | Roles and decision-making |
+| [Maintainers](MAINTAINERS.md) | Access, review, and stewardship expectations |
+| [Roadmap](ROADMAP.md) | Milestones and public exit criteria |
+| [Licensing](LICENSING.md) | Licensing and upstream-attribution policy |
+| [IPI proposals](ipi/README.md) | Protocol and governance proposal process |
+
+## Proposal naming
+
+An **IPI Improvement Proposal** uses the identifier
+**IPI-####**. The process definition is [IPI-0000](ipi/IPI-0000.md), the first
+technical principles proposal is [IPI-0001](ipi/IPI-0001.md), and new proposals
+start from [the template](ipi/IPI-template.md).
+
+## Project status
+
+IPI is under active development and is not yet a production-ready public
+network. A repository, endpoint, or testnet must not be presented as a stable
+release unless its documentation explicitly says so and provides reproducible
+verification evidence.
+
+## Existing legal documents
+
+Files under [statements/](statements/) and [translations/](translations/) are
+preserved separately from the technical and community standards in this
+repository. Their presence does not make them a current protocol specification
+or a substitute for qualified legal review. Changes to those files require an
+explicit legal review process.
+
+## Historical and incubating material
+
+The [knowledge/](knowledge/) tree and the root-level [workflows/](workflows/)
+directory predate this community baseline and are preserved for traceability.
+They are not canonical protocol specifications or active GitHub Actions.
+Executable organization workflows live only under [.github/workflows/](.github/workflows/).
+New normative protocol work belongs in an IPI proposal and an identified
+implementation repository.
diff --git a/ROADMAP.md b/ROADMAP.md
new file mode 100644
index 0000000..647cbbb
--- /dev/null
+++ b/ROADMAP.md
@@ -0,0 +1,113 @@
+# IPI Roadmap
+
+IPI's goal is a protocol stack for digital systems that can be independently
+operated, verified, and extended. This roadmap separates that goal from the
+evidence currently available.
+
+It is a sequence of verification gates, not a promise of dates, token value,
+performance, or production readiness. Priorities can change through issues and
+[IPI Improvement Proposals](ipi/README.md).
+
+## Stage 0 — Make the project legible
+
+**Objective:** a new contributor can understand what exists, what is inherited,
+what is planned, and how decisions are made.
+
+- Publish community, security, governance, and contribution standards.
+- Establish the IPI proposal process.
+- Inventory repositories as active, experimental, upstream fork, archived, or
+ license pending.
+- Preserve upstream provenance and resolve licenses for original work.
+- Publish a canonical architecture and repository map.
+
+**Exit evidence:** every highlighted repository has an owner, maturity label,
+license status, build instructions, security contact, and issue tracker.
+
+## Stage 1 — Reproducible protocol baseline
+
+**Objective:** consolidate the active IPI node into a reviewable public
+baseline.
+
+- Document the Cosmos SDK, CometBFT, Cosmos EVM, CosmWasm, and IBC compatibility
+ matrix.
+- Reproduce clean genesis, node build, startup, state verification, and upgrade
+ procedures.
+- Define chain identity, account formats, native key paths, and public
+ interfaces.
+- Separate upstream code from IPI-specific modules and changes.
+- Add deterministic tests, dependency scanning, release artifacts, checksums,
+ and software-bill-of-materials generation.
+
+**Exit evidence:** an independent contributor can build the same source, start a
+node from documented public data, verify network identity, and reproduce the
+required compatibility tests.
+
+## Stage 2 — Verifiable commerce primitives
+
+**Objective:** make physical and digital commerce claims independently
+verifiable without placing secret material on-chain.
+
+- Specify product passports, product and chip registries, issuers, revocation,
+ and lifecycle rules.
+- Define P-256/R1 and hardware-backed identity use cases and their threat models.
+- Build checkout, receipts, wallet signing, and terminal flows around explicit
+ state transitions.
+- Specify privacy boundaries and the separation between public proofs and
+ private business or personal data.
+- Test ordinary NFC tags before introducing secure-chip attestation paths.
+
+**Exit evidence:** public specifications, test vectors, threat models, and
+end-to-end tests demonstrate the same result across independently implemented
+clients.
+
+## Stage 3 — Independent operation
+
+**Objective:** remove hidden operational dependencies.
+
+- Publish node, wallet, explorer, faucet, indexer, terminal, monitoring, snapshot,
+ and recovery procedures.
+- Support independent bootstrap and state verification.
+- Document all privileged keys, coordinators, infrastructure providers, and
+ emergency controls.
+- Measure operator and provider diversity without converting it into a single
+ misleading score.
+- Exercise backup, restore, migration, degraded-mode, and exit procedures.
+
+**Exit evidence:** at least two unrelated operators reproduce the deployment
+from public documentation and can continue verification through a simulated
+loss of one project-operated service.
+
+## Stage 4 — Interoperability with explicit trust
+
+**Objective:** connect systems without hiding new trust assumptions.
+
+- Harden IBC paths and cross-system identity.
+- Specify Bitcoin anchoring and independently verify inclusion and continuity.
+- Evaluate asset wrapping, routing, and liquidity only with public threat models,
+ custody models, accounting invariants, and failure procedures.
+- Reject “trustless” or “independent” labels that are not supported by
+ reproducible evidence.
+
+**Exit evidence:** each integration publishes its trust boundaries, key holders,
+failure modes, verification procedure, and safe shutdown or migration path.
+
+## Stage 5 — Community-operated releases
+
+**Objective:** make IPI maintainable without dependence on one person or
+organization.
+
+- Grow independent maintainers and component reviewers.
+- Run public release candidates and an externally operated testnet.
+- Commission security reviews for production-bound components.
+- Publish reproducible governance, release, incident, and upgrade records.
+- Establish a stable compatibility policy and long-term maintenance process.
+
+**Exit evidence:** releases receive independent review, multiple operators and
+implementations verify the network, governance records are public, and no
+single undocumented service is required for normal operation.
+
+## Current focus
+
+The immediate focus is Stage 0 and Stage 1. Work from later stages can remain in
+experiments, but it must not be marketed as accepted or production-ready before
+its earlier dependencies and exit evidence are complete.
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000..82a34c1
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,64 @@
+# Security Policy
+
+Security reports are welcome. Please give maintainers a reasonable opportunity
+to investigate and coordinate a fix before public disclosure.
+
+## Report a vulnerability privately
+
+Do not open a public issue, Discussion, or pull request for a suspected
+vulnerability.
+
+1. Use the affected repository's **Report a vulnerability** form under its
+ Security tab when available.
+2. If private vulnerability reporting is unavailable, email
+ [hello@ipi.io](mailto:hello@ipi.io) with the subject
+ “SECURITY: repository and short summary”.
+
+Include:
+
+- the affected repository, revision, component, and environment;
+- a clear description of the behavior and realistic impact;
+- minimal reproduction steps or a proof of concept;
+- whether the issue has been disclosed elsewhere;
+- any suggested mitigation; and
+- a safe way to contact you.
+
+Encrypt sensitive material before sending it by ordinary email and ask for a
+secure transfer method if needed. Never send private keys, seed phrases,
+production credentials, or unrelated personal data.
+
+## What to expect
+
+The project aims to acknowledge a complete report within five business days.
+Validation, remediation, release, and disclosure timing depend on severity and
+affected dependencies. The reporter will receive updates when there is
+meaningful progress. No bug bounty or payment is promised unless a written
+program explicitly says otherwise.
+
+## Supported versions
+
+IPI is pre-release software. Unless a repository states otherwise, only its
+current default branch and most recent explicitly supported release receive
+security fixes. Historical branches, experiments, demonstrations, and testnets
+may be changed or retired without backports.
+
+No public endpoint, testnet, wallet, terminal, bridge, or contract should be
+assumed production-safe merely because it is reachable.
+
+## Good-faith research
+
+Use only accounts and assets you control. Avoid privacy violations, data
+destruction, service degradation, denial of service, social engineering,
+physical attacks, and access beyond what is necessary to demonstrate the issue.
+Stop and report if testing exposes private data or creates risk for others.
+
+The project will treat good-faith research that follows this policy as an effort
+to improve IPI. This policy does not authorize testing of third-party services
+or infrastructure.
+
+## Operational secrets
+
+If a secret appears in a repository, treat it as compromised even after the
+file is removed. Notify the project privately so the credential can be revoked,
+rotated, and investigated. Rewriting Git history is not a substitute for
+rotation.
diff --git a/SUPPORT.md b/SUPPORT.md
new file mode 100644
index 0000000..0fba59a
--- /dev/null
+++ b/SUPPORT.md
@@ -0,0 +1,23 @@
+# IPI Support
+
+IPI is an early-stage open-source project. Community support is public and
+best-effort; there is currently no guaranteed response time or production
+support agreement.
+
+## Where to go
+
+| Need | Channel |
+| --- | --- |
+| Usage or architecture question | [GitHub Discussions](https://github.com/orgs/ipicoin/discussions) |
+| Reproducible software defect | Issue in the affected repository |
+| Protocol or governance change | [IPI Improvement Proposal](ipi/README.md) |
+| Security vulnerability | Private process in [SECURITY.md](SECURITY.md) |
+| Conduct concern | Private process in [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) |
+
+Before asking, search existing issues and Discussions and read the repository's
+README. Include the repository revision, operating system, configuration with
+secrets removed, expected result, actual result, and the smallest reproducible
+example.
+
+Please do not send support requests to individual contributors. Public,
+searchable answers reduce repeated work and make the project easier to join.
diff --git a/ipi/IPI-0000.md b/ipi/IPI-0000.md
new file mode 100644
index 0000000..3bc6734
--- /dev/null
+++ b/ipi/IPI-0000.md
@@ -0,0 +1,284 @@
+---
+ipi: 0000
+title: IPI Improvement Proposal Process
+description: Lifecycle and editorial requirements for IPI protocol and governance proposals
+author: IPI contributors
+discussions-to: https://github.com/orgs/ipicoin/discussions
+status: Active (bootstrap)
+type: Process
+created: 2026-07-15
+requires: none
+---
+
+# IPI-0000: IPI Improvement Proposal Process
+
+## Abstract
+
+This document defines how IPI Improvement Proposals are written, reviewed,
+numbered, accepted, implemented, and maintained. The process is designed to keep
+protocol decisions public, technically reviewable, attributable, and possible
+to challenge with evidence.
+
+This is a bootstrap process. Its active status means it can be used now; it does
+not imply that the project already has independent maintainers or mature
+governance. Material amendments to this process require another IPI.
+
+## Motivation
+
+The process exists to:
+
+- separate a problem and specification from a particular implementation;
+- expose security, compatibility, governance, and operational consequences
+ before they become dependencies;
+- create a durable record of alternatives and decisions;
+- make it possible for independent implementations to reach the same result;
+ and
+- prevent marketing claims from substituting for tests or specifications.
+
+## Scope and non-goals
+
+This process governs project-wide technical and governance proposals. It does
+not replace ordinary issue triage, repository review, private vulnerability
+coordination, or the authority of an affected upstream project. A proposal
+number records identity and history; it does not confer approval, ownership, or
+implementation priority.
+
+## Specification
+
+Authors, editors, reviewers, and maintainers MUST use the types, metadata,
+sections, lifecycle, and decision requirements below. Process automation MAY
+enforce editorial structure but MUST NOT decide technical merit.
+
+## Proposal types
+
+### Standards Track
+
+A normative change to protocol behavior or a stable public interface.
+
+Categories:
+
+- **Core** — consensus, state transition, accounts, cryptography, fees,
+ governance, or upgrades;
+- **Interface** — RPC, API, wallet, contract, event, query, or data formats;
+- **Interoperability** — IBC, anchoring, bridging, wrapping, or external-system
+ verification; and
+- **Application** — shared application-layer behavior intended for compatible
+ implementations.
+
+### Process
+
+A change to governance, proposal handling, releases, maintenance, or another
+project-wide process.
+
+### Informational
+
+Research, architecture guidance, or a design record that does not create a
+normative compatibility requirement.
+
+## Required metadata
+
+Every proposal contains:
+
+- ipi — assigned number or “draft” before assignment;
+- title — concise and descriptive;
+- description — one-line purpose;
+- author — accountable author names or GitHub handles;
+- discussions-to — canonical public Discussion;
+- status — current lifecycle status;
+- type — proposal type and optional category;
+- created — date in YYYY-MM-DD form; and
+- requires — prerequisite IPI numbers or “none”.
+
+Optional metadata can record replacements, superseded proposals, and target
+versions.
+
+## Required sections
+
+A proposal must include:
+
+1. **Abstract**
+2. **Motivation**
+3. **Scope and non-goals**
+4. **Specification**
+5. **Rationale and alternatives**
+6. **Compatibility and migration**
+7. **Security considerations**
+8. **Privacy considerations**
+9. **Operational considerations**
+10. **Independence impact**
+11. **Test and verification plan**
+12. **Reference implementation**
+13. **Open questions**
+
+“Not applicable” is acceptable only with an explanation.
+
+## Lifecycle
+
+| Status | Meaning |
+| --- | --- |
+| Draft | The author is actively defining the proposal. |
+| Review | The specification is complete enough for broad technical review. |
+| Last Call | Maintainers believe the decision is ready; the deadline and unresolved objections are public. |
+| Accepted | The specification is approved for implementation but may not yet be deployed. |
+| Implemented | At least one conforming implementation and its verification evidence are public. |
+| Final | The change is deployed or adopted and its compatibility commitment is stable. |
+| Deferred | Work is paused without rejecting the proposal. |
+| Rejected | The stated proposal will not be adopted; the rationale remains public. |
+| Withdrawn | The authors ended consideration. |
+| Superseded | Another numbered proposal replaces it. |
+
+Only an editor changes lifecycle metadata, based on the decision record. Editors
+must not change the technical meaning without author and reviewer agreement.
+
+## From Draft to Review
+
+A Draft can enter Review when:
+
+- all required sections exist;
+- normative language is unambiguous;
+- affected components and maintainers are identified;
+- compatibility and security effects are explicit;
+- the verification plan can distinguish conformance from non-conformance; and
+- major alternatives are represented fairly.
+
+Editorial completeness does not mean technical endorsement.
+
+## Last Call and acceptance
+
+Last Call must state a public closing date, normally at least fourteen days
+after announcement. Longer review is appropriate for consensus, cryptography,
+custody, governance, privacy, or irreversible migrations.
+
+Acceptance requires:
+
+- responsible maintainers for every affected component;
+- independent technical review proportionate to risk;
+- no unresolved blocking security, licensing, or compatibility objection;
+- a recorded response to material objections; and
+- approval under [GOVERNANCE.md](../GOVERNANCE.md).
+
+If the project does not yet have enough independent reviewers, the proposal
+remains in Review. Urgency is not evidence of consensus.
+
+## Implementation and conformance
+
+Accepted means the specification may be implemented. It does not mean a
+particular implementation is correct.
+
+Implemented status requires a public implementation, tests tied to the
+normative requirements, reproducible results, and documentation of deviations.
+Final status additionally requires the specified deployment or governance
+adoption and a clear compatibility commitment.
+
+Reference implementations must not silently add requirements absent from the
+proposal. When code and the accepted specification disagree, the discrepancy is
+a bug or requires an amendment.
+
+## Amendments
+
+Draft and Review proposals can change through normal review. Accepted proposals
+may receive clarifications that do not change observable behavior. A material
+behavioral, security, compatibility, or governance change requires a new IPI
+that updates or supersedes the earlier one.
+
+Proposal files are never removed merely because they are rejected, withdrawn,
+or superseded. The permanent record is part of the process.
+
+## Editorial responsibilities
+
+Editors:
+
+- check structure, clarity, links, metadata, and numbering;
+- ensure the proposal describes alternatives and consequences;
+- manage status changes according to this process; and
+- avoid deciding technical merit through editorial control.
+
+Editors may return an incomplete proposal with actionable feedback. The current
+maintainer record is defined in [MAINTAINERS.md](../MAINTAINERS.md).
+
+## Rationale and alternatives
+
+A versioned proposal in Git preserves review history, links specifications to
+implementations, and can be mirrored with the code. Using only chat, issues, or
+mutable web pages was rejected because those channels do not provide a stable,
+structured compatibility record. Letting implementations define the standard
+after deployment was rejected because it hides design choices and disadvantages
+independent implementations.
+
+## Compatibility and migration
+
+This process changes no protocol behavior. Existing decisions are not
+retroactively accepted IPIs. They can be documented by a new Informational or
+Standards Track proposal when a durable specification is needed.
+
+File names, numbers, and accepted normative behavior are stable references.
+Editorial tooling can change as long as it continues to accept the metadata and
+lifecycle defined here or a superseding proposal provides a migration.
+
+## Security considerations
+
+The public process must not force disclosure of an unpatched vulnerability,
+private key, personal data, or exploitable operational detail. Embargoed work
+follows [SECURITY.md](../SECURITY.md) and completes its public record after
+coordinated disclosure.
+
+Editors and maintainers are control points. Branch protection, independent
+review, narrow permissions, and permanent history reduce the risk that one
+person can silently alter an accepted specification.
+
+## Privacy considerations
+
+Authors can use established public GitHub identities and are not required to
+publish legal names or private contact details. Disclosures should identify
+relevant organizational or financial conflicts without exposing unrelated
+personal information.
+
+## Operational considerations
+
+The proposal index, metadata, links, and required headings SHOULD be validated
+in continuous integration. Accepted and Final proposals SHOULD be mirrored with
+release documentation so a temporary loss of GitHub does not erase the
+specification.
+
+At least two editors are desirable. Until that role is independently staffed,
+the bootstrap limitation must remain visible.
+
+## Independence impact
+
+The process moves decisions from private coordination into portable, versioned
+files. It still depends initially on GitHub organization permissions and a small
+maintainer set. Repository mirrors, multiple editors, signed releases, and a
+documented recovery path are required to reduce that dependency.
+
+## Test and verification plan
+
+The repository validation script checks proposal metadata and required
+sections. The process will be tested by reviewing IPI-0001 from Draft through
+its next lifecycle decision and recording ambiguities as amendments.
+
+Before this process loses its bootstrap designation, the project must show that
+an unrelated contributor can discover the template, submit a conforming draft,
+receive editorial review, and reproduce the resulting decision record.
+
+## Reference implementation
+
+The [IPI directory](README.md), [proposal template](IPI-template.md), pull
+request template, and community validation workflow are the initial reference
+implementation.
+
+## Open questions
+
+- Who will serve as the first independent proposal editors?
+- Which metadata should become machine-readable without duplicating the
+ Markdown source of truth?
+- Where should canonical mirrors be maintained?
+- Which proposal categories require longer Last Call periods or specialist
+ review?
+
+## Copyright and licensing
+
+Proposal authors must have the right to submit their text and examples. The
+project-wide documentation license remains pending until the relevant rights
+holders record a decision under [LICENSING.md](../LICENSING.md). Until then,
+public access to a proposal must not be mistaken for permission to reuse it
+outside the rights provided by law.
diff --git a/ipi/IPI-0001.md b/ipi/IPI-0001.md
new file mode 100644
index 0000000..f5a9ce4
--- /dev/null
+++ b/ipi/IPI-0001.md
@@ -0,0 +1,347 @@
+---
+ipi: 0001
+title: Verifiable Independence
+description: Evidence model for systems that claim to be independently operable and verifiable
+author: IPI contributors
+discussions-to: https://github.com/orgs/ipicoin/discussions
+status: Draft
+type: Standards Track / Core
+created: 2026-07-15
+requires: 0000
+---
+
+# IPI-0001: Verifiable Independence
+
+## Abstract
+
+This proposal defines independence as a set of observable system properties
+rather than a slogan, topology, or performance number. A conforming IPI system
+must publish enough evidence for an unrelated operator to verify state, identify
+control points, reproduce releases, operate without mandatory private
+coordination, and follow a documented exit or continuity path.
+
+The proposal introduces an evidence matrix across verification, control,
+operation, reproducibility, governance, exit, and diversity. Unknown or
+undisclosed dependencies remain unknown; they do not become independent through
+assumption.
+
+## Motivation
+
+Distributed systems are commonly compared using transaction throughput, block
+time, or time to finality. Those measurements can be useful, but they answer
+performance questions. They do not establish who controls software upgrades,
+which keys can override normal rules, whether users can verify state without a
+project-operated service, whether infrastructure is concentrated, or whether
+the system survives the loss of a coordinator.
+
+We could not identify a chain-agnostic, independently reproducible test that
+converts an advertised low finality number into proof of operational
+independence. IPI therefore rejects finality as a proxy for independence.
+
+This is not a claim that every fast-finality network is dependent. It is a claim
+about evidence: speed alone cannot prove independence. Each system, including
+IPI, must expose and test its actual trust and control structure.
+
+## Scope and non-goals
+
+This proposal applies to IPI protocol releases, networks, clients, wallets,
+operators, public services, interoperability paths, and governance processes
+that are described as independent.
+
+It does not:
+
+- define one universal decentralization score;
+- guarantee safety, liveness, privacy, legal autonomy, or economic fairness;
+- require every component to use a blockchain;
+- declare another project independent or dependent without system-specific
+ evidence;
+- equate a permissionless interface with distributed control; or
+- make early IPI experiments production-ready.
+
+## Definitions
+
+**Independent operation** means an unrelated, authorized operator can deploy,
+verify, maintain, and recover a component using public specifications and data,
+without a mandatory undocumented service or private permission.
+
+**Independent verification** means a party can determine whether stated rules
+were followed using locally executed software and authenticated public inputs,
+without trusting the party making the claim.
+
+**Control point** means a key, account, role, service, repository permission,
+release channel, network position, or governance mechanism capable of changing,
+blocking, censoring, fabricating, or selectively presenting system behavior.
+
+**Required dependency** means a component or actor whose loss prevents the
+documented normal operation or verification path.
+
+**Exit** means a documented ability to export state or assets, change provider,
+continue from public data, migrate to a compatible system, or fork the software
+and rules, subject to explicitly stated limitations.
+
+**Evidence** means a public artifact or repeatable observation tied to a defined
+version and procedure. A promise, brand, architecture diagram, or endpoint is
+not sufficient by itself.
+
+## Specification
+
+### 1. Evidence matrix
+
+Every release or network claiming IPI-conformant independence MUST publish an
+evidence matrix with the dimensions below. Each entry MUST be marked
+**verified**, **partial**, **not verified**, or **unknown**, and MUST link the
+artifact and procedure supporting that status.
+
+| Dimension | Minimum evidence question |
+| --- | --- |
+| Verification | Can a new operator verify identity and state from authenticated public inputs? |
+| Control | Are privileged keys, roles, override paths, and upgrade authority enumerated? |
+| Operation | Can normal operation continue without a mandatory private coordinator or project API? |
+| Reproducibility | Can source, dependencies, builds, artifacts, and provenance be independently checked? |
+| Governance | Can an observer reconstruct how a change was proposed, approved, activated, and challenged? |
+| Exit | Is there a tested export, migration, recovery, continuation, or fork path? |
+| Diversity | Are critical operators and providers identified well enough to detect common control or failure? |
+
+A system MUST NOT collapse the matrix into a single score that hides a failed or
+unknown dimension. Summaries MAY be provided if the complete matrix remains
+prominent.
+
+### 2. Verification
+
+A conforming system MUST document:
+
+- canonical network or component identity;
+- authenticated sources for genesis, checkpoints, releases, and configuration;
+- the rules used to accept state and transitions;
+- bootstrap and synchronization procedures;
+- how a verifier detects inconsistent or selectively presented data; and
+- which facts still require external trust.
+
+At least one verification path MUST run without a project-hosted explorer,
+wallet, indexer, or RPC endpoint. A hosted service MAY improve access, but it
+MUST NOT be the only way to check a protocol claim.
+
+### 3. Control disclosure
+
+All known control points MUST be documented with:
+
+- capability and scope;
+- holder or selection mechanism;
+- threshold and rotation procedure;
+- auditability;
+- emergency use and expiration;
+- effect of compromise or unavailability; and
+- removal or replacement path.
+
+This includes administrator, upgrade, validator, sequencer, bridge, oracle,
+issuer, signing, release, DNS, repository, package registry, infrastructure, and
+recovery authority where applicable.
+
+The absence of a disclosed control point MUST mean “not known”, not “does not
+exist”, unless the claim is supported by the specification and tests.
+
+### 4. Reproducible software and releases
+
+For each supported release, the project MUST publish:
+
+- source revision and complete dependency resolution;
+- supported build environment and commands;
+- artifact checksums and signing or provenance information;
+- generated-code and binary-blob inventory;
+- compatibility and migration notes;
+- known limitations; and
+- a method for comparing an independently built artifact.
+
+Reproducible builds SHOULD be the target. Until byte-for-byte reproduction is
+available, the evidence matrix MUST state what remains non-reproducible and how
+the released artifact was produced.
+
+### 5. Independent operation
+
+Deployment documentation MUST distinguish required components from optional
+project services. It MUST identify external providers, credentials, allowlists,
+private data, and manual steps.
+
+A release claiming independent operation MUST be exercised by at least two
+operators who do not share organizational control. Their reports MUST include
+the tested revision, environment, deviations, failures, and evidence that loss
+of one project-operated service does not prevent the stated verification path.
+
+### 6. Governance and change control
+
+Every consensus, compatibility, trust, or governance change MUST have a durable
+public record linking:
+
+- the specification or IPI;
+- material alternatives and objections;
+- accountable reviewers and disclosed conflicts;
+- implementation and test evidence;
+- activation conditions;
+- emergency authority, if any; and
+- rollback, recovery, or supersession procedure.
+
+Private handling MAY be used for embargoed security work. The public record MUST
+be completed after coordinated disclosure when safe.
+
+### 7. Exit and continuity
+
+The system MUST document which forms of exit are possible and which are not.
+Applicable procedures MUST cover:
+
+- user-controlled key and data export;
+- state snapshot and independent restoration;
+- change of RPC, wallet, validator, operator, or infrastructure provider;
+- software fork and network-continuation prerequisites;
+- bridge, wrapped-asset, or custody unwind; and
+- behavior when the original maintainers, domain, or hosted services disappear.
+
+At least one continuity or exit exercise MUST be performed before a network is
+described as production-ready.
+
+### 8. Diversity evidence
+
+Operator count alone is insufficient when operators share control,
+infrastructure, release binaries, keys, jurisdiction, or a required coordinator.
+Diversity reporting SHOULD cover, where observable:
+
+- beneficial or organizational control;
+- hosting and network providers;
+- geographic and jurisdictional concentration;
+- software implementations and build provenance;
+- signing, custody, and governance dependencies; and
+- correlated failure modes.
+
+Unobservable ownership or coordination MUST be reported as unknown. The project
+MUST NOT infer independence from pseudonym count alone.
+
+### 9. Finality claims
+
+Finality claims MUST define:
+
+- the precise finality condition;
+- measurement start and end;
+- network and workload configuration;
+- validator or operator assumptions;
+- reorganization, halt, and partition behavior; and
+- the reproducible measurement procedure and result.
+
+Finality evidence MAY support a performance claim. It MUST NOT, on its own,
+upgrade any independence-matrix dimension to verified.
+
+## Rationale and alternatives
+
+### Why not a single score?
+
+A weighted score makes severe weaknesses disappear inside an average. A system
+with many operators but one upgrade key, or reproducible software but one
+mandatory sequencer, needs an explicit warning rather than a high aggregate
+rating.
+
+### Why include governance and exit?
+
+A system can distribute normal transaction processing while retaining
+centralized change authority or making migration impossible. Independence must
+cover change and failure, not only steady-state topology.
+
+### Why allow partial and unknown?
+
+Honest uncertainty is more useful than false precision. The matrix is intended
+to direct engineering work and independent review, not manufacture a badge.
+
+### Alternative: define independence only by consensus participation
+
+Rejected. Consensus participation does not cover client verification, release
+provenance, administration, hosted dependencies, custody, or exit.
+
+## Compatibility and migration
+
+This proposal adds documentation and verification requirements. It does not
+change consensus behavior.
+
+Existing components can adopt it incrementally:
+
+1. publish an initial matrix with unknowns;
+2. enumerate control points and required services;
+3. attach repeatable verification procedures;
+4. run independent operation and continuity exercises; and
+5. update maturity claims as evidence changes.
+
+No component is required to claim full independence. A precise partial result is
+conformant; an unsupported complete claim is not.
+
+## Security considerations
+
+Publishing control points can improve review but can also reveal high-value
+targets. Documentation SHOULD describe capabilities and rotation without
+publishing secrets or unnecessary personal information.
+
+Independent operators may reproduce unsafe configurations. Procedures MUST
+distinguish demonstrations from production settings, remove test credentials,
+and define safe resource limits.
+
+The evidence model does not prove implementation correctness. Audits, threat
+models, adversarial tests, incident response, and dependency management remain
+necessary.
+
+## Privacy considerations
+
+Transparency about control and diversity MUST be balanced with contributor and
+operator privacy. Publish organizational relationships and technical
+dependencies needed to evaluate correlated control; do not require home
+addresses, personal documents, private keys, or unrelated identifying data.
+
+Product, payment, identity, wallet, and chip systems MUST separately document
+linkability, retention, consent, selective disclosure, and public-chain data.
+“Verifiable” must not be used as a reason to place confidential data on-chain.
+
+## Operational considerations
+
+Evidence expires. Every matrix MUST identify the assessed version and date and
+SHOULD be reviewed for each release and material infrastructure change.
+
+Automated checks SHOULD verify links, artifact hashes, build instructions, and
+configuration drift. Human review remains necessary for beneficial control,
+governance, and undocumented coordination.
+
+## Independence impact
+
+This proposal creates no new runtime coordinator. It raises the burden for IPI
+to disclose its own dependencies and prevents performance, permissionless
+access, or open source from being presented as sufficient proof of independence.
+
+The proposal process and evidence hosting are themselves project dependencies.
+Their complete Git history and portable open formats provide an initial exit
+path; independent mirrors and multiple maintainers remain future requirements.
+
+## Test and verification plan
+
+Before this proposal moves to Accepted:
+
+- apply the matrix to the current IPI testnet without hiding unknowns;
+- have two unrelated reviewers independently reach comparable classifications;
+- test a node bootstrap and state-verification path without a project explorer;
+- inventory privileged keys, hosted services, repositories, and release paths;
+- perform a documented loss-of-service and recovery exercise; and
+- publish disagreements and refine ambiguous criteria.
+
+Conformance tests should include a deliberately centralized example that must
+not pass merely because it has low finality or many nominal node identities.
+
+## Reference implementation
+
+No complete reference implementation exists. The current IPI testnet and
+tooling will be used to produce the first evidence matrix after this proposal
+receives review. Until then, IPI independence remains a goal under test, not a
+certification.
+
+## Open questions
+
+- Which evidence fields can be generated from release and network telemetry
+ without creating privacy risks?
+- What minimum independent-operator relationship is practical at each maturity
+ stage?
+- How should evidence be signed, mirrored, and versioned?
+- Which continuity exercises should be mandatory before a public testnet and
+ before a production release?
+- Can compatible tools compare matrices without turning them into a misleading
+ universal score?
diff --git a/ipi/IPI-template.md b/ipi/IPI-template.md
new file mode 100644
index 0000000..540f496
--- /dev/null
+++ b/ipi/IPI-template.md
@@ -0,0 +1,78 @@
+---
+ipi: draft
+title: Short descriptive title
+description: One-line purpose
+author: Name or GitHub handle
+discussions-to: URL
+status: Draft
+type: Standards Track / Core
+created: YYYY-MM-DD
+requires: none
+---
+
+# IPI-draft: Short descriptive title
+
+## Abstract
+
+State the proposed change and its result in a short paragraph.
+
+## Motivation
+
+Describe the concrete problem, affected users or operators, current evidence,
+and why existing behavior is insufficient.
+
+## Scope and non-goals
+
+Define what this proposal changes and what it deliberately leaves unchanged.
+
+## Specification
+
+Define observable behavior precisely. Use normative MUST, MUST NOT, SHOULD,
+SHOULD NOT, and MAY only where an implementation can be tested against them.
+Specify state transitions, formats, validation, errors, versioning, and failure
+behavior as applicable.
+
+## Rationale and alternatives
+
+Explain the major design choices, alternatives considered, and why they were
+not selected. Include the option of making no change.
+
+## Compatibility and migration
+
+Describe backward and forward compatibility, activation, data migration,
+rollback, client behavior, and impact on existing integrations.
+
+## Security considerations
+
+Identify assets, actors, trust boundaries, privileged roles, attack paths,
+failure modes, and mitigations. State assumptions explicitly.
+
+## Privacy considerations
+
+Identify public, private, linkable, retained, and erasable data. Explain
+metadata leakage and any effect on consent or data minimization.
+
+## Operational considerations
+
+Describe configuration, monitoring, resource requirements, dependencies,
+deployment order, recovery, shutdown, and incident handling.
+
+## Independence impact
+
+Evaluate the proposal against [IPI-0001](IPI-0001.md). State whether it adds a
+coordinator, key holder, service provider, oracle, bridge, sequencer, or another
+required dependency and how an operator can verify or replace it.
+
+## Test and verification plan
+
+List deterministic conformance tests, test vectors, adversarial cases,
+reproduction commands, and evidence required before each lifecycle transition.
+
+## Reference implementation
+
+Link implementations or state that none exists. A reference implementation does
+not replace the specification.
+
+## Open questions
+
+List unresolved decisions and the evidence needed to close them.
diff --git a/ipi/README.md b/ipi/README.md
new file mode 100644
index 0000000..4e27c5c
--- /dev/null
+++ b/ipi/README.md
@@ -0,0 +1,54 @@
+# IPI Improvement Proposals
+
+An **IPI Improvement Proposal** is a versioned design document for changes that
+affect the IPI protocol, public interfaces, compatibility, security model,
+governance, or multiple repositories.
+
+Proposal identifiers use **IPI-####**. “IPI” in this context means
+**IPI Improvement Proposal**.
+
+## Read first
+
+- [IPI-0000 — IPI Improvement Proposal Process](IPI-0000.md)
+- [IPI-0001 — Verifiable Independence](IPI-0001.md)
+- [IPI proposal template](IPI-template.md)
+
+## When an IPI is required
+
+Use an IPI for:
+
+- consensus, state-machine, transaction, account, or cryptographic changes;
+- stable RPC, API, data-format, wallet, contract, or interoperability changes;
+- network upgrades and compatibility policy;
+- new trust assumptions, privileged roles, or security boundaries;
+- project-wide governance and release policy; or
+- a coordinated change spanning multiple repositories.
+
+An ordinary issue or pull request is usually enough for a local bug fix,
+refactor, test, documentation correction, or implementation of an already
+accepted proposal.
+
+## Proposal index
+
+| IPI | Title | Type | Status |
+| ---: | --- | --- | --- |
+| [0000](IPI-0000.md) | IPI Improvement Proposal Process | Process | Active (bootstrap) |
+| [0001](IPI-0001.md) | Verifiable Independence | Standards Track / Core | Draft |
+
+## Contributing a proposal
+
+1. Start a focused
+ [GitHub Discussion](https://github.com/orgs/ipicoin/discussions) describing
+ the problem, constraints, and alternatives.
+2. Establish that an IPI is the right level of change and identify affected
+ maintainers.
+3. Copy [IPI-template.md](IPI-template.md) to a draft named
+ IPI-draft-short-title.md.
+4. Complete the motivation, specification, security, compatibility, test,
+ operational, and independence sections.
+5. Open a pull request and link the Discussion.
+6. An editor assigns the next number when the proposal meets the minimum
+ editorial requirements. A number does not mean acceptance.
+
+The repository history, proposal metadata, linked Discussion, and implementation
+pull requests together form the public decision record.
diff --git a/profile/README.md b/profile/README.md
index bd245e5..b391399 100644
--- a/profile/README.md
+++ b/profile/README.md
@@ -1,8 +1,103 @@
-## [Independent Protocol Infrastructure](https://ipi.io/)
-> WE COMBINE THE BEST PROTOCOLS TO BUILD THE FASTEST, SAFEST AND SIMPLEST INDEPENDENT BLOCKCHAIN FOR STORING, TRADING, DAPPS, DEFI, NFT AND MORE POWERED BY IPI UTILITY COIN. MOST POPULAR COINS WRAPPED.
-
-##### About IPI
-- [advantages](https://ipi.io/#advantages)
-- [platform](https://ipi.io/#platform)
-- [ecosystem](https://ipi.io/#ecosystem)
-- [getting wallet](https://www.ipi.io/wallet.html)
+# 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/orgs/ipicoin/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/orgs/ipicoin/discussions) ·
+[Governance](/ipicoin/.github/blob/main/GOVERNANCE.md) ·
+[IPI proposals](/ipicoin/.github/tree/main/ipi)
diff --git a/scripts/check_community.py b/scripts/check_community.py
new file mode 100644
index 0000000..71acc74
--- /dev/null
+++ b/scripts/check_community.py
@@ -0,0 +1,165 @@
+#!/usr/bin/env python3
+"""Validate the IPI organization profile and community standards."""
+
+from pathlib import Path
+import sys
+
+
+ROOT = Path(__file__).resolve().parents[1]
+
+REQUIRED_FILES = [
+ "AGENTS.md",
+ "ARCHITECTURE.md",
+ "README.md",
+ "profile/README.md",
+ "CONTRIBUTING.md",
+ "CODE_OF_CONDUCT.md",
+ "SECURITY.md",
+ "SUPPORT.md",
+ "GOVERNANCE.md",
+ "MAINTAINERS.md",
+ "ROADMAP.md",
+ "LICENSING.md",
+ ".github/PULL_REQUEST_TEMPLATE.md",
+ ".github/ISSUE_TEMPLATE/bug_report.yml",
+ ".github/ISSUE_TEMPLATE/feature_request.yml",
+ ".github/ISSUE_TEMPLATE/config.yml",
+ "ipi/README.md",
+ "ipi/IPI-0000.md",
+ "ipi/IPI-0001.md",
+ "ipi/IPI-template.md",
+]
+
+CLAIM_SURFACE = [
+ "ARCHITECTURE.md",
+ "README.md",
+ "profile/README.md",
+ "ROADMAP.md",
+ "ipi/README.md",
+ "ipi/IPI-0001.md",
+]
+
+BANNED_UNSUPPORTED_CLAIMS = [
+ "fast" + "est",
+ "safe" + "st",
+ "simple" + "st",
+ "unlimited " + "tps",
+]
+
+PROPOSAL_FIELDS = [
+ "ipi",
+ "title",
+ "description",
+ "author",
+ "discussions-to",
+ "status",
+ "type",
+ "created",
+ "requires",
+]
+
+PROPOSAL_SECTIONS = [
+ "## Abstract",
+ "## Motivation",
+ "## Scope and non-goals",
+ "## Specification",
+ "## Rationale and alternatives",
+ "## Compatibility and migration",
+ "## Security considerations",
+ "## Privacy considerations",
+ "## Operational considerations",
+ "## Independence impact",
+ "## Test and verification plan",
+ "## Reference implementation",
+ "## Open questions",
+]
+
+
+def read_text(relative_path: str) -> str:
+ return (ROOT / relative_path).read_text(encoding="utf-8")
+
+
+def local_markdown_targets(content: str) -> list[str]:
+ targets: list[str] = []
+ for remainder in content.split("](")[1:]:
+ target = remainder.split(")", 1)[0].strip()
+ if target:
+ targets.append(target.split()[0].strip("<>"))
+ return targets
+
+
+def main() -> int:
+ failures: list[str] = []
+
+ for relative_path in REQUIRED_FILES:
+ path = ROOT / relative_path
+ if not path.is_file():
+ failures.append(f"missing required file: {relative_path}")
+ continue
+ if not path.read_text(encoding="utf-8").strip():
+ failures.append(f"required file is empty: {relative_path}")
+
+ for relative_path in CLAIM_SURFACE:
+ lowered = read_text(relative_path).lower()
+ for phrase in BANNED_UNSUPPORTED_CLAIMS:
+ if phrase in lowered:
+ failures.append(
+ f"unsupported claim '{phrase}' found in {relative_path}"
+ )
+
+ for relative_path in ["ipi/IPI-0000.md", "ipi/IPI-0001.md"]:
+ content = read_text(relative_path)
+ lines = content.splitlines()
+ if not lines or lines[0] != "---":
+ failures.append(f"missing metadata header: {relative_path}")
+ for field in PROPOSAL_FIELDS:
+ prefix = f"{field}:"
+ if not any(line.startswith(prefix) for line in lines):
+ failures.append(f"missing proposal field '{field}': {relative_path}")
+ for heading in PROPOSAL_SECTIONS:
+ if heading not in content:
+ failures.append(f"missing proposal section '{heading}': {relative_path}")
+
+ for relative_path in REQUIRED_FILES:
+ if not relative_path.endswith(".md"):
+ continue
+ source = ROOT / relative_path
+ if not source.is_file():
+ continue
+ for target in local_markdown_targets(read_text(relative_path)):
+ if target.startswith(("http://", "https://", "mailto:", "#", "/")):
+ continue
+ local_part = target.split("#", 1)[0]
+ if local_part and not (source.parent / local_part).exists():
+ failures.append(
+ f"broken local link '{target}' in {relative_path}"
+ )
+
+ private_name_fragments = [
+ "mlasz" + "czewski",
+ "lasz" + "czewski",
+ ]
+ for path in ROOT.rglob("*"):
+ if not path.is_file() or ".git" in path.parts:
+ continue
+ try:
+ lowered = path.read_text(encoding="utf-8").lower()
+ except UnicodeDecodeError:
+ continue
+ for fragment in private_name_fragments:
+ if fragment in lowered:
+ failures.append(
+ f"prohibited personal reference found in {path.relative_to(ROOT)}"
+ )
+
+ if failures:
+ for failure in failures:
+ print(f"ERROR: {failure}")
+ return 1
+
+ print("Community standards validation passed.")
+ return 0
+
+
+if __name__ == "__main__":
+ sys.exit(main())
diff --git a/workflows/blank.yml b/workflows/blank.yml
index 01502b1..3af8e21 100644
--- a/workflows/blank.yml
+++ b/workflows/blank.yml
@@ -1,36 +1,13 @@
-# This is a basic workflow to help you get started with Actions
-
-name: CI
-
-# Controls when the workflow will run
-on:
- # Triggers the workflow on push or pull request events but only for the "main" branch
- push:
- branches: [ "main" ]
- pull_request:
- branches: [ "main" ]
-
- # Allows you to run this workflow manually from the Actions tab
- workflow_dispatch:
-
-# A workflow run is made up of one or more jobs that can run sequentially or in parallel
-jobs:
- # This workflow contains a single job called "build"
- build:
- # The type of runner that the job will run on
- runs-on: ubuntu-latest
-
- # Steps represent a sequence of tasks that will be executed as part of the job
- steps:
- # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- - uses: actions/checkout@v4
-
- # Runs a single command using the runners shell
- - name: Run a one-line script
- run: echo Hello, world!
-
- # Runs a set of commands using the runners shell
- - name: Run a multi-line script
- run: |
- echo Add other actions to build,
- echo test, and deploy your project.
+# Legacy reference retained without deleting history.
+#
+# GitHub does not execute workflows from this directory. The active,
+# security-pinned community validation workflow is:
+#
+# ../.github/workflows/blank.yml
+#
+# New automation must be added under ../.github/workflows/ and reviewed through
+# the normal pull-request process.
+
+status: legacy
+active: false
+canonical_workflow: ../.github/workflows/blank.yml