Skip to content

Security & Disclosure

We take the security of the protocol and the people who use it seriously. If you have found a vulnerability, we want to hear from you — this page sets out how to report it, what is in scope, and how we recognise the researchers who help keep Vibestarter safe.

[ Reporting a vulnerability ]

Email security@vibestarter.xyz with a clear description of the issue, the affected component, and the steps to reproduce it. A working proof-of-concept — and, for contract issues, a test against a local fork or testnet — helps us triage quickly and assess severity accurately.

We aim to acknowledge your report within 3 business days and to give an initial severity assessment within 10 business days. Please give us a reasonable opportunity to remediate before any public disclosure; we will keep you updated and credit your work.

[ Safe harbor ]

We consider good-faith security research conducted in line with this policy to be authorized. We will not pursue or support legal action against researchers for accidental, good-faith violations of this policy, and we will work with you to understand and resolve the issue. This protection does not extend to actions that harm users, exfiltrate data, or exploit live funds.

[ In scope ]

  • The deployed mainnet smart-contract suite (source: github.com/vibesprotocol/vibestarter-contracts).
  • The web application at app.vibestarter.xyz and its API routes.
  • Authentication and authorization, fund-custody flows, tranche release, and challenge-window logic.

[ Out of scope ]

The following are generally not eligible. We still appreciate the heads-up and may credit notable reports, but they are not treated as protocol vulnerabilities:

  • Email spoofing and missing or weak SPF, DKIM, or DMARC records (we do not send transactional email or collect user emails — these carry no funds or account risk).
  • Missing security headers, cookie flags, or TLS configuration nits without a demonstrated, impactful exploit.
  • Self-XSS, clickjacking on pages with no sensitive action, and other issues requiring unrealistic user interaction.
  • Rate-limiting, brute-force, volumetric denial-of-service, or network-layer DDoS.
  • Output of automated scanners without a working proof-of-concept.
  • Social engineering, phishing, and physical attacks against staff or infrastructure.
  • Vulnerabilities in third-party services we do not control (e.g. Privy, Vercel, Supabase, RPC providers, wallet software).
  • Testnet-only issues with no corresponding mainnet impact.

[ Severity & rewards ]

Rewards are assessed case-by-case on demonstrated impact. Monetary rewards are reserved for issues that directly put funds at risk or compromise system-critical, privileged functions. Other valid findings are recognised with platform points and public credit.

Critical / High

Direct theft or loss of user or protocol funds; unauthorized admin or privileged-role control; bypass of fund-custody, vesting, or challenge-window logic; unauthorized minting, draining, or freezing of assets.

RewardMonetary reward, scaled to severity and impact — plus platform points and public credit.

Medium

A genuine bug with no demonstrated path to funds or privileged control — for example logic errors, access-control gaps, or denial-of-service confined to non-fund flows.

RewardPlatform points and public credit. Monetary awards are at our discretion and not guaranteed at this tier.

Low / Informational

Security hygiene and best-practice findings with limited or theoretical impact — for example email-authentication gaps, missing headers, or configuration nits.

RewardPublic credit and, at our discretion, platform points. These are not eligible for monetary rewards.

[ Rules of engagement ]

  • Test only against your own accounts and wallets — never against real users’ funds or data.
  • Demonstrate fund-impacting contract issues on a local fork or testnet. Do not exploit mainnet contracts that hold real funds.
  • Do not access, modify, or exfiltrate data that is not yours, and do not degrade or interrupt the service.
  • Keep findings confidential until we have shipped a fix and agreed on a disclosure timeline.
→ Security audits← All documentation