SolFlux
Security Vulnerability disclosure policy

Found something? We want to hear it.

SolFlux is built by OmniGuardLabs, a security firm. If you report in good faith, we'll work with you, credit you and keep you safe from legal action. Email admin@omniguardlabs.com. No encryption key is published yet, so that mail is not encrypted.

How to report

Email admin@omniguardlabs.com with the subject line SolFlux security report. Please include:

  • the affected surface, URL or chain family;
  • clear steps to reproduce, with a proof of concept against a local fork where possible;
  • impact as you understand it, and which severity level you think applies;
  • how you'd like to be credited, or that you'd like to stay anonymous.

We don't take reports by phone. This policy and our security.txt follow RFC 9116. No encryption key exists yet. security.txt has no Encryption field. Reports sent to the mailbox are not encrypted. Do not treat a syntax check of that file as proof that its canonical host resolves.

Safe harbor

If you research and report in good faith under this policy, we consider your work authorized. That means:

  • we won't pursue or support legal action against you for it, including under anti-hacking laws (such as the CFAA or equivalent laws elsewhere) or anti-circumvention laws (such as the DMCA);
  • we treat it as authorized access for any of our terms of service that would otherwise restrict it;
  • if a third party takes legal action over research that followed this policy, we'll say publicly that you acted with our authorization.

Good faith means you follow the rules of engagement, don't deliberately harm users or their funds, don't extort us, and give us reasonable time to fix the issue before you disclose it. If you're unsure whether something is allowed, ask us first.

Severity

We triage using the levels below and adjust for real-world exploitability. The response targets are what we hold ourselves to.

Severity levels, examples and response targets
LevelExamplesFix target
CriticalTheft or permanent freezing of user funds; draining or redirecting a fee vault; compromise of a receipt-signing or vault-authority key; arbitrary execution in a swap path.7 days
HighForging a receipt so it verifies falsely; bypassing screening so an unsafe token gets a buy; fee capture skipped or misdirected; authentication bypass on a gated surface.30 days
MediumStored or reflected XSS on a SolFlux web surface; misleading quote or receipt display that doesn't move funds; leaks of non-public operational data.60 days
LowMissing hardening (headers, cookie flags) with a plausible impact; low-impact information disclosure; rate-limit weaknesses that don't put funds at risk.90 days

We acknowledge reports within 2 business days and send a triage decision within 5 business days.

Scope

In scope

  • This website, solflux.io, once it is being served
  • SolFlux on-chain programs after a release publishes an address. No address is published on this site. The Solana program is in devnet testing. Nothing is live. No settled receipt exists. Proofs so far ran on a local validator.

Not in scope until they exist

  • API and SDK: not built
  • Browser extension: not built
  • Security-screened discovery funnel and listing site: not built
  • Telegram trade bot: not launched. t.me/solfluxhq is a channel, not a trade bot
  • Embeddable swap widget: not launched
  • Fee capture and receipt checks on a live deployment: nothing is live, so there is no live family to test

Out of scope

  • Third-party DEXs, aggregators, RPC providers, wallets and bridges, plus the base chains themselves. Please report those upstream.
  • Vulnerabilities in third-party tokens. (A failure of our own screening would be in scope only once that screening is built. It is not built.)
  • Denial of service, volumetric or load testing, spam and social engineering of staff or users
  • Physical attacks, and attacks that need a compromised device or a malicious browser extension
  • Reports from automated scanners with no demonstrated impact, missing best practices with no exploit path, self-XSS, and clickjacking on pages with no sensitive actions
  • Actively testing access-gated internal surfaces (see the rules below)

Coordinated disclosure timeline (90 / 30)

  1. Day 0: you report and we acknowledge within 2 business days.
  2. Within 5 business days: we confirm or decline the finding and agree a severity with you.
  3. Fix: we work to the targets above and keep you updated at least every 14 days.
  4. Disclosure: details may be published at the earlier of 90 days after the report or 30 days after the fix ships. The 30 days give integrators and users time to update.
  5. Exceptions: if a bug is being actively exploited, we may disclose sooner with mitigations. Either side may ask for an extension, and we'll agree one if a fix is credibly in progress.

Rules of engagement

  • Test on devnet, testnets or local forks. On mainnet, use only your own wallets and funds, and never move other people's funds, even to "rescue" them.
  • Don't access, change or keep other users' data. If you come across it, stop, tell us, and delete it.
  • Don't attempt to bypass authentication on access-gated internal surfaces, including the private fee monitor. The hostname is not published on this site. If you think one is exposed, report what you saw without accessing anything further.
  • No denial of service, spam, social engineering or physical testing.
  • Use only the minimum interaction needed to prove the issue, and stop once you have.
  • Keep findings confidential until the disclosure timeline above allows publication.
  • Follow applicable law. This policy can't authorize testing of third-party systems.

Acknowledgments

We thank researchers who help keep SolFlux users safe. Verified reporters who agree to be named will be listed here, with the date and severity.

No acknowledged reports yet. Yours could be the first. This sentence is the state of this page, not a claim about every mailbox we have ever used.