Please do not open public GitHub issues for security vulnerabilities.

Report them through a private GitHub security advisory on this repository.

A useful report includes:

• The affected component and commit or deployment (contract address, frontend build, or scanner version).
• Steps to reproduce, a proof of concept, or the specific code path involved.
• Your assessment of impact (loss of funds, privacy de-anonymization, denial of service, etc.).

We aim to acknowledge security reports within 5 business days and will keep you updated as we investigate. Please give us a reasonable window to ship a fix before any public disclosure; we are happy to coordinate timing and credit you in the advisory.

We will not pursue legal action against good-faith research that respects user privacy, avoids data destruction, and stays within testnet or your own accounts.

Open a GitHub issue with a clear title (for example, Abuse report: or Sanctions concern:) and enough detail for us to investigate. Do not include sensitive personal data in public issues when a private advisory is more appropriate.

The reference wallet also surfaces an in-app summary at /abuse-policy (see frontend/src/components/AbusePolicyPage.tsx).

Security fixes are applied to the latest code on the main branch. When we tag a release, notes appear on the GitHub Releases page.

Advisory response windows and the routine update-batching schedule are defined in .github/CONTRIBUTING.md. The full supply-chain policy — hash-pinning, reproducible builds, and the separate PR-blocking monitoring of the Rust WASM build chain (scanner/ / wasm-bindgen) — is in docs/supply-chain-policy.md.

The following packages handle cryptographic operations or proof generation and receive extra review on every version bump. They are pinned to exact versions in frontend/package.json — dependabot opens individual PRs for each.

When publishing @opaquecash/stellar to npm, builds use --provenance to attach a signed build attestation. This ties the published package to the specific CI run and commit that produced it, preventing supply-chain attacks via compromised build environments.

CI runs npm audit on every PR against both the root and frontend/ workspaces (ci.yml, supply-chain job) to catch known vulnerabilities in production dependencies.

.github/workflows/codeql.yml analyzes JavaScript/TypeScript and Rust on every pull request to main and every Monday at 06:30 UTC. Results are published in the repository's Code scanning alerts.

The repository owner (@collinsadi) or a security maintainer explicitly delegated by the owner is responsible for reviewing and dismissing CodeQL findings. Pull-request authors may investigate and propose a resolution, but may not dismiss their own finding without that review.

• Triage new alerts promptly; critical and high-severity findings are assessed before the affected change is merged.
• Fix confirmed, reachable findings in a tracked pull request or private security advisory, as appropriate.
• Dismiss an alert only with GitHub's matching reason — false positive, used in tests, or won't fix — and a dismissal comment that identifies the affected code, explains why it is not exploitable, and links to the relevant issue, advisory, test, or compensating control.
• Won't fix requires an explicit, documented risk acceptance by the repository owner, including a review date. Reopen dismissed alerts when the code, threat model, or mitigating control changes.

Contract upgrade authority, process, and user-visible guarantees are documented in docs/UPGRADE_GOVERNANCE.md.

If an admin, governance, multisig signer, or deployer key is suspected or confirmed compromised, follow the per-contract-role playbooks (pause / freeze, admin transfer, contract upgrade) and the quarterly drill checklist in docs/ADMIN_KEY_COMPROMISE_PLAYBOOKS.md. Those playbooks assume the admin-authority model documented in docs/MULTISIG_ADMIN.md.

• Soroban contracts in contracts/
• Reference frontend in frontend/
• Scanner WASM in scanner/
• Deployment manifests and CI verification scripts

Out of scope: third-party wallets, Stellar network consensus, and self-hosted forks unless they use official deployment credentials we operate.