Security

Flip is a non-custodial interface to a third-party settlement network. The non-custodial design means Flip itself cannot move user funds — every transaction is signed locally in the user's wallet. This minimizes the security surface that Flip controls, but real risks still exist (interface compromise, supply-chain attacks, dependency vulnerabilities) and we take them seriously.

Vulnerability disclosure

Report security issues via the contact form — pick the "Security disclosure" category so it routes correctly. We'll acknowledge receipt within 72 hours and provide a disposition (accepted / declined / needs more info) within 14 days for non-trivial reports.

Please do not publicly disclose unpatched issues. Coordinated disclosure: we'll work with you on a timeline for publication once a fix is verified.

Scope

In scope: the flipdex.co interface, its API routes (/api/quote, /api/status, /api/tokens), our handling of wallet signature flows, our handling of user input (address validation, amount parsing, recipient/refund), our deposit-address display logic, our use of third-party dependencies (Sentry, Plausible, wagmi, NEAR Wallet Selector).

Out of scope:the underlying settlement protocol (NEAR Intents 1Click). Report issues with the protocol directly to its maintainers — disclosure paths are in the protocol's own documentation. We'll happily relay if you're not sure where to send a report.

Bug bounty

Flip does not currently run a public bug bounty program. For material findings (severity Medium or above on the CVSS scale) we offer ad-hoc rewards, scaled to impact and quality of the report. Reach out via the contact form before doing testing that could affect other users.

Incident history

No known security incidents as of the last-updated date above. If we ever experience one, it will be disclosed here with the full timeline, root cause, and remediation.

Architecture summary

Flip's server-side API routes proxy requests to the underlying settlement protocol. Sensitive credentials (the protocol JWT) stay on the server and never reach the client. Rate limiting, origin lock, method gates, and content-type guards are enforced at the edge (proxy.ts). Server-side input validation rejects malformed asset IDs, suspicious deadlines, and out-of-range slippage values before forwarding to the protocol.

See Trust & security for the user-facing trust model and how to verify any swap independently.

What does NOT need to be reported

Best-practice findings without an exploit path (e.g., "you're missing header X" without a demonstrated impact), social engineering attempts against the operator, denial-of-service through volume, or issues in third-party dependencies that have already been disclosed upstream.