Security & Responsible Disclosure

How to report a vulnerability

Email [email protected].

We prefer an initial one-paragraph summary plus reproduction steps. Proof-of-concept code is welcome but not required for the first contact. You will receive a human acknowledgment from us, not an auto-responder.

Our response commitments

• Initial acknowledgment: within 48 hours of receipt, we reply with a tracking ID and a named point of contact.
• Triage: within 5 business days we confirm whether the report is in-scope, assign severity, and outline remediation.
• Critical fixes: deployed within 30 days of triage.
• High-severity fixes: within 60 days.
• Public disclosure: coordinated. We ask for 90 days from triage before public disclosure; we'll ship sooner when possible.

Bug bounty program

We run a private-beta bounty program, expanding scope as the team grows. Rewards below are guidance; final amounts depend on exploitability, blast radius, and quality of the report.

Severity	Examples	Reward
Critical	Remote code execution, unauthenticated access to another merchant's funds, hot-wallet key disclosure, full dashboard takeover across accounts.	$2,000 – $5,000
High	Authenticated horizontal privilege escalation, webhook signature forgery, sanctioned-address denylist bypass, MFA bypass on payout.	$500 – $2,000
Medium	Stored XSS behind auth, CSRF on sensitive writes, sensitive-data leakage in logs, rate-limit bypass that meaningfully raises abuse surface.	$150 – $500
Low	Informational-only header issues, open redirects without sensitive context, self-XSS, clickjacking on non-transactional pages.	Public thanks · swag where practical

In scope

• orbchain.io and all subdomains we operate (status, docs, blog, api, pay, dashboard).
• Our public REST + webhook API surface.
• Official open-source repositories under github.com/orbchain — including the SDKs (orbchain-sdk-js, -python, -php) and the 16 e-commerce plugins.
• The merchant dashboard SPA and the hosted /pay/:trackId pages.

Out of scope

• Third-party infrastructure we do not operate: Cloudflare edge, Postgres / Redis hosts, Voltage (Lightning), blockchain node RPC endpoints, Resend (email), Twilio, Turnstile.
• Staging (staging.orbchain.io) — please test there freely, but staging-only findings are not rewarded unless they prove an in-scope production issue.
• Plugins on marketplace hosts (wordpress.org, packagist, npm, PyPI) — the underlying plugin source is in scope; marketplace metadata issues are not.
• Denial-of-service, volumetric flooding, and social-engineering of our team, contractors, or users.
• Physical attacks against offices, data centers, or individuals.
• Auto-scanner output without validation — dictionary-brute attempts, generic CVE matches without a working PoC, headers-only findings on non-transactional pages.
• Already-known issues tracked in our internal queue or disclosed in prior reports.

Ground rules

• Use the staging environment whenever possible. Mainnet testing must not move real merchant funds, send email to non-researcher addresses, or degrade service for other users.
• Never access data that is not yours beyond what is necessary to demonstrate the issue. Stop, document, and report.
• One issue per report. Chain-exploits are welcome — describe the chain in one report, not five.
• Give us a reasonable window to fix before going public. See the SLA above.
• Duplicates go to whoever reported first, by Postgres ts. Please don't share reports with third parties before disclosure.

Threat model

We optimize defenses against the threats that cause real customer loss, in this order:

1. Account takeover of a live merchant — session hijack, credential stuffing, password reset abuse. Defenses: Cloudflare Turnstile on auth routes, per-account exponential lockout, per-IP credential-stuffing block, optional TOTP with step-up on every payout, mandatory email verification before payouts or MFA changes.
2. Payout abuse from a compromised or fraudulent merchant — drain the hot balance before anyone notices. Defenses: 24-hour first-payout cooldown on fresh accounts, per-merchant velocity caps, OFAC + known-hacker address denylist on every payout, signed append-only audit log.
3. API-key leakage in the wild — SDK + plugin distribution means keys end up in public repos and frontend bundles. Defenses: scoped keys with per-key IP allowlists, prefixed key format suitable for GitHub secret-scanning, append-only audit log of key create/revoke events.
4. Supply-chain compromise of our SDKs or plugins — poisoned release propagates to every merchant. Defenses: provenance attestations on npm / PyPI / Packagist, gitleaks + Dependabot on every repo, signed git tags, reproducible builds for the plugin bundles.
5. Signup spam + disposable-email abuse — floods metrics, burns staging resources. Defenses: ~120k-domain disposable-email denylist, MX record check, Cloudflare Turnstile, rate limits at both nginx and the application layer.
6. Insider or admin error — fat-finger payout approval, accidental mass-disable. Defenses: append-only audit log enforced at the Postgres trigger layer (UPDATE + DELETE raise, even as a privileged role). Role split + 4-eye approval on destructive ops is on the near roadmap.

Architecture at a glance

• No pooled reserve. Each merchant settles to its own non-pooled BIP-44 branch, and we hold funds only as long as required by the settlement model you selected — auto-sweep forwards to a wallet you control, and hot-wallet sweeps to cold custody run daily above a per-coin USD threshold.
• HD-wallet multi-tenant model. One master seed derives m/44'/coin'/merchantIndex'/0/userIndex branches. Index 0 is reserved for the platform hot wallet; each merchant gets a unique merchantIndex atomically claimed at signup.
• Webhook signatures. Every outbound webhook is HMAC-SHA512 signed with the merchant's dedicated webhook secret. Each event carries a deterministic event_id safe to use as an idempotency key; 5 retries with exponential backoff.
• SSRF hardening. Every webhook dispatch resolves the target host and rejects private, loopback, link-local, and multicast IPs. Axios runs with maxRedirects: 0 so a public origin cannot 302 into an internal target.
• Append-only audit log. Security-relevant events (logins, lockouts, payouts, API-key CRUD, MFA changes, admin actions) are written to an append-only Postgres table. A database-layer trigger raises on UPDATE or DELETE, so a compromised app server cannot quietly rewrite history.
• Signed settlement receipts. Every PAID payment carries an Ed25519-signed canonical JSON receipt; the public key is published at /v1/common/receipt-public-key.

Hall of fame

Researchers whose reports have shipped a fix are credited here with their consent. This list starts empty — help us populate it.

• Your name here — be the first.

machine-readable

/.well-known/security.txt (view) follows RFC 9116.

Contact

Security inbox: [email protected]
General press / ops: [email protected]
Compliance: see the AML & Compliance policy.