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