QuorumProof handles professional credential attestation on Stellar Soroban. Security issues in the contracts, API server, or ZK verification pipeline can directly affect the integrity of issued credentials — please report them responsibly rather than disclosing them publicly.
Only the code on the main branch and the most recently deployed mainnet
contract versions receive security fixes. There are no separate LTS branches
at this time.
Do not open a public GitHub issue for security vulnerabilities.
Report suspected vulnerabilities privately to:
If the report concerns a deployed smart contract with an active exploit path (e.g. a bug that lets funds or credentials be stolen or forged right now), say so explicitly in the subject line so it can be triaged immediately.
- A clear description of the vulnerability and its impact.
- Affected component(s):
contracts/quorum_proof,contracts/sbt_registry,contracts/zk_verifier,contracts/bbs_plus_v1,api-server,frontend,dashboard, or infrastructure/CI. - Steps to reproduce, or a proof-of-concept (a failing test against the contract test harness is ideal for on-chain issues).
- The commit hash or deployed contract address you tested against.
- Your assessment of severity and any suggested mitigation, if you have one.
Encrypt your report if it contains exploit details you consider sensitive; otherwise plain email is fine.
- Acknowledgment — within 3 business days of your report.
- Triage — we confirm the issue, assess severity and affected scope, and reply with our initial assessment within 7 business days.
- Fix development — a patch is developed and tested privately. For contract bugs this includes a testnet redeployment dry run before any mainnet action; see Disaster Recovery for the emergency pause/redeploy procedure used if the bug is actively exploitable.
- Disclosure coordination — we agree on a disclosure date with you (see Embargo Periods below).
- Release & credit — the fix ships, an advisory is published, and you are credited (see Credit below) unless you ask to remain anonymous.
We ask for a coordinated disclosure embargo so affected users have time to act, particularly for anything touching deployed contracts (on-chain fixes cannot be silently "patched" the way a server can):
| Severity | Target embargo |
|---|---|
| Critical (active fund/credential exploit) | Up to 90 days, or until a fix is deployed and confirmed, whichever is sooner |
| High (exploitable but not actively abused) | Up to 60 days |
| Medium/Low | Up to 30 days, or by mutual agreement |
If a vulnerability is already being actively exploited in the wild, we will move to emergency disclosure and mitigation (contract pause, key rotation, etc.) ahead of any embargo — see the emergency procedures in docs/disaster-recovery.md.
We will extend or shorten these windows in discussion with the reporter based on real-world risk, complexity of the fix, and whether third parties (exchanges, integrators, custodians) need advance notice.
Reporters who follow this policy and give us reasonable time to fix the issue before public disclosure will be credited by name (or handle) in the security advisory and release notes, unless they request anonymity. We do not currently run a paid bug bounty program.
In scope:
contracts/quorum_proof,contracts/sbt_registry,contracts/zk_verifier,contracts/bbs_plus_v1— logic errors, authorization bypass, storage corruption, integer overflow, denial-of-service via gas exhaustion, cryptographic weaknesses in the ZK verification or BBS+ signing paths.api-server— authentication/authorization bypass, injection, request signing/HMAC weaknesses, rate-limiting/DDoS-protection bypass.frontend,dashboard— XSS, CSRF, key-handling bugs (e.g. exposing a wallet secret), dependency vulnerabilities with a real exploit path.- CI/CD and deployment scripts — anything that could lead to a supply-chain compromise of a release artifact or deployed contract.
Out of scope:
- Issues requiring physical access to a user's device.
- Social engineering against QuorumProof maintainers or third-party institutions issuing credentials.
- Vulnerabilities in third-party dependencies with no demonstrated impact on QuorumProof specifically (report those upstream instead).
- Best-practice suggestions with no concrete exploit — open those as a normal GitHub issue or discussion instead.
- Threat Model & Security Analysis — asset identification, threat actors, attack vectors and mitigations already considered. Please check here first; a report that matches an already -documented and accepted risk will be triaged accordingly.
- Security Best Practices Guide
- Security Audit Checklist — internal review checklist, useful context for what we already check for.
- Known Limitations (ZK proof scheme)
- Disaster Recovery Procedures — what happens operationally once a critical issue is confirmed (emergency pause, redeployment, credential restoration).