Reference
Support and vulnerability disclosure
How to prepare a reproducible support packet, verify an official contact, and understand the current disclosure boundary.
Official public channel not yet publishedNo verified public support or disclosure destination is published
Before public Testnet support is announced, the release operator must publish the exact destination on an official FLIP domain and immutable release documentation, then cross-link it from the application. Until that happens, this page’s honest state is unavailable—not a guessed email address.
Prepare a reproducible support packet
- Chain ID, release, Source A and manifest hash; finalized block/hash and readiness response timestamp.
- Transaction hash, receipt status, contract role/address from the accepted manifest, and receipt-derived Bet/Ticket/Request/liability/Epoch/launch identifier.
- Exact API method/path, HTTP status, public reasonCode and request ID. Redact authorization headers, cookies, signatures that authorize a live action, private RPC credentials and all secrets.
- Expected and observed raw integer amounts plus token decimals. Include the relevant event names and raw balance deltas rather than only formatted UI values.
- For Parity include target, horizon, source identity, capture/read timestamps and evidence hash; for JIT include liability/quote IDs; for Holder include Epoch/index/account/root/proof status.
- A screenshot may illustrate an interface symptom but never replaces a receipt, finalized block, runtime hash, proof or API identity.
Vulnerability disclosure requirements
| Required field | Publication rule |
|---|---|
| Official destination | HTTPS page and monitored security contact under an official FLIP domain, cross-linked from the application and docs |
| Scope | Exact contracts, services, websites, chains, releases and excluded third-party systems |
| Safe harbor | Good-faith testing rules, prohibited data/fund access and coordinated disclosure expectations |
| Response SLA | Acknowledgement, triage and status-update targets plus emergency escalation |
| Reward policy | Whether a bounty exists, severity method, eligibility, payout range and duplicate/report-quality rules |
| Release binding | Affected current/legacy release identities and a public remediation/retest trail after disclosure |
The Mainnet replacement ID public-vulnerability-disclosure remains open until these controls and a handling drill are evidenced. Publishing this explanatory page does not close that ID and does not create a bounty.
If you observe an active risk before a channel exists
- 01
Do not exploit or move funds
Stop testing beyond the minimum harmless reproduction. Do not access another user’s data or attempt to prove impact by taking assets.
- 02
Preserve public evidence
Record finalized transaction/block identifiers, release identity, affected public endpoint/contract and minimal non-secret reproduction steps.
- 03
Verify any claimed destination
Accept a contact only after it appears on the official application and this official documentation under a valid HTTPS domain. An unsolicited social account or direct message is not sufficient.
- 04
Do not publish weaponized details
Until a verified channel and remediation plan exist, avoid posting private exploit payloads, credentials or instructions that create immediate user risk.