Responsible disclosure policy
If you've found a security issue in BitView, we want to hear about it privately first. Below is the channel, the scope, the SLA, and what you should expect from us in return.
How to report
Email security@bitview.so. Encrypt with our PGP key (fingerprint published in the site footer once production launches; placeholder during MVP).
If you cannot email, open a private security advisory on the relevant GitHub repository:
bitview-bot(backend service)bitview-app(frontend)distributor(on-chain program)checkpoint(this site — yes, even doc bugs that mislead users count if they affect security understanding)
Do not open public GitHub issues, post on X / Discord, or contact individual team members for a security finding before it has been disclosed through this channel and remediated.
What to include
| Field | Details |
|---|---|
| Summary | One-sentence description |
| Affected component(s) | bitview-bot / bitview-app / distributor / smart contract address / etc. |
| Severity (your assessment) | Critical / High / Medium / Low (we'll re-classify if needed) |
| Reproduction | Step-by-step, ideally with PoC code |
| Impact | What an attacker could do if exploited |
| Suggested fix | Optional, appreciated |
| Discovery date | When you first noticed the issue |
| Public disclosure preference | Coordinated 90-day default; we'll discuss if you prefer different |
What you should expect
| Time from your report | What happens |
|---|---|
| < 24 hours | Acknowledgment of receipt |
| < 72 hours (critical / high) | Initial triage assessment with our severity rating |
| < 7 days | Confirmation of in-scope/out-of-scope, bounty eligibility (if bug bounty applies) |
| < 30 days (typical critical) | Patch deployed |
| < 60 days (typical) | Patch verified, coordinated public disclosure window opens |
| 90 days | Default public disclosure deadline if not earlier |
Critical findings can move faster — the contract above is a maximum, not a minimum.
What we ask of you
While we triage and fix:
- Do not exploit the vulnerability beyond what's needed to demonstrate it.
- Do not access user data beyond your own test accounts.
- Do not disrupt service, drain funds, or pivot to other systems.
- Do not publicly disclose until coordinated disclosure window opens.
- Do report quickly — sitting on a finding extends real users' exposure.
These are good-faith expectations, not legal demands. We treat researchers acting in good faith as collaborators, not adversaries. The bug bounty page describes what crosses the line into disqualifying behavior.
Scope
In scope for security reports (and bounty payment):
- The audited merkle distributor program at
4ffj6hEnx6cqp4ToMALExqk6QwPNSbZyr8ro9yW1Qvok - BitView-deployed Solana programs (vesting, governance, sponsorship escrow when those ship)
- The
bitview-botRust backend - The
bitview-appNext.js frontend - BitView-operated infrastructure (api.bitview.so, app.bitview.so, checkpoint.bitview.so)
- BitView-controlled Solana wallets (treasury, fee collection, etc.) for theft / unauthorized-spend findings
- Wallet-link auth flow (Twitch OAuth → ed25519 signature → MongoDB persistence)
- Sybil detection (theoretical bypass that would not require account takeover)
Out of scope:
- Solana network itself (report to Solana Foundation)
- Underlying Metaplex programs (report to Metaplex)
- Jupiter / Meteora pool contracts (report to those teams)
- MongoDB / Solana RPC providers (vendor-side)
- Twitch (Twitch's own bug bounty)
- Self-XSS, social engineering of BitView staff, denial-of-service via volume alone, missing security headers without exploitable consequence, vulnerabilities in dependencies that don't reach a reachable code path in our products
Coordinated disclosure timeline
Our default is 90 days from confirmed report to public disclosure, or earlier when patched. We will:
- Patch first, disclose second.
- Credit the researcher in the post-mortem (or anonymously if preferred).
- Publish a post-mortem on the checkpoint site within 30 days of patch deployment for confirmed vulnerabilities affecting users.
- Coordinate the disclosure date with the researcher.
If 90 days passes and the vulnerability is unpatched without legitimate reason, the researcher may publicly disclose. We commit to keeping you informed if a patch is taking longer than 90 days and explaining why.
What is a security issue vs a bug
For clarity:
| Type | Channel |
|---|---|
| Smart-contract exploit allowing fund theft | security@ |
| API auth bypass | security@ |
| XSS / CSRF / SQL injection | security@ |
| Sybil-detection bypass with material impact | security@ |
| OFAC screening bypass | security@ |
| Wallet-link impersonation | security@ |
| API rate-limit bug | security@ |
| Frontend UX bug | GitHub issue (public OK) |
| Documentation typo | GitHub issue (public OK) |
| Feature request | GitHub discussion |
When in doubt, prefer security@ — we'd rather get a soft tip and re-route than miss a real issue.
Our PGP key
Will be published here at production launch. During MVP send unencrypted with the understanding that email transport is best-effort secure.
Hall of fame
Researchers who have helped secure BitView are credited (with consent) on the audits page. Bounty payouts and credit are independent — we credit researchers who decline payment, and we pay researchers who decline credit.