trade.fun
Executive Summary
Trade.fun is a Solana-based trading terminal built for fast memecoin sniping, with prediction markets (via Polymarket), perpetual futures (via Hyperliquid), and yield products (via Kamino) bolted on. Their token, $TRADE, launched on pump.fun on 2026-04-23 and graduated to PumpSwap. The audit covered the token, the contract address, the live web product, and the project's public footprint.
On-chain: the team did the right things. Mint and freeze authorities are revoked, so the supply is fixed and no wallet can be frozen. 57.25% of the total supply is locked in two Streamflow vesting contracts — 37.25% vesting linearly over 3 years, and 20% vesting over 4 years with a 1-year cliff. Both locks are non-cancellable, beneficiary is the team treasury itself, and the schedules can be independently verified on Streamflow's dashboard. Launch behavior was clean: no sniper bundle, no Jito-tip insider buying, no coordinated wallets funded from a single source. The remaining unlocked team supply (13.4%, split across two vanity-prefix wallets) is the main on-chain risk to a buyer — the larger of the two has already begun redistributing tokens to other wallets within the first day, so sell pressure from this slice can hit the market at any time.
Product: the live app is built on a reputable third-party stack — Turnkey for embedded non-custodial wallets, Hyperliquid for perps, Polymarket for prediction markets, Streamflow for the vests, Helius and 0slot for transaction submission and MEV protection, Datadog for monitoring. Static review of the ~8 MB JS bundle found no drainer patterns, no hardcoded credentials, no eval usage, and no clipboard or WebUSB exfiltration. Live walkthrough confirmed that all third-party hosts the app contacts map to those declared integrations — no surprise outbound, no bearer tokens leaked off-origin. Tested input fields correctly escape HTML.
The product-security findings are defense-in-depth gaps, not exploitable behaviors. The two medium findings (session tokens stored in localStorage rather than an HttpOnly cookie, and no confirmed Content-Security-Policy header) are well-understood patterns the team should fix even though there's no live exploit chain. The three low findings (trading params changeable without re-auth, Polygon RPC privacy, plaintext RPC URL strings in the bundle) are smaller hardening items.
Speed-first UX is intentional. Trades fire in instant mode (no separate confirm screen) and the send dialog goes directly to "Send" without a separate review step. This is a deliberate product choice for the trader audience — the sniper-terminal niche, including BullX, Photon, Trojan, and Axiom, all behave the same way. We document it here as informational so non-trader readers understand the trade-off, but it does not deduct from the score: it's a feature, not a bug. The implication for users is operational, not technical: double-check the destination address and amount before clicking, because there's no second prompt to back out of.
Final score: 82/100. Verdict: PASS, low_risk. The audit produced no critical, no high, two medium, and three low findings on the product side. The on-chain side is strong, with most of the team supply locked for years and clean launch behavior. The 13.4% of unlocked team supply is the main buyer-aware caveat — it can be sold at any time and the larger holder is already moving tokens around. Trade.fun is appropriate for the trader audience it was built for, and the team has put real on-chain commitment behind the launch.
Rug Risk Assessment
Audit Scope
| Scope Item | Status | Notes |
|---|---|---|
| Token authority and supply analysis | complete | Verified via Helius DAS getAsset and getMultipleAccounts on top holders. |
| Streamflow vesting verification | complete | Both lock metadata accounts decoded directly from on-chain bytes; durations and amounts confirmed. |
| Holder concentration | limited | Top 20 enumerated via getTokenLargestAccounts; full holder count via paginated DAS not run because top 5 already showed the structural picture. |
| Bundle and coordinated-buy detection | complete | First 80 SWAP transactions on the mint reviewed. No bundling pattern. |
| Domain WHOIS and DNS | complete | trade.fun registered 2024-05-17 via NameCheap, Cloudflare DNS, expires 2027-05-17. |
| Twitter profile review | limited | X.com blocks automated scraping; profile content was reviewed via reader proxy. Profile is active, content matches product, pinned tweet announces the same contract address. Follower / engagement stats not enumerated. |
| Frontend JS bundle static review | complete | 8.1 MB minified Vite bundle plus ethers, Datadog RUM, service worker, and manifest fetched and grepped for secrets, drainer patterns, eval/Function constructor, hardcoded keys, third-party endpoints, and known wallet integrations. |
| Live in-product walkthrough | complete | Cloudflare Turnstile blocked direct Playwright automation. Walkthrough run via the operator's signed-in browser session and reported back as structured findings (network map, storage layout, transaction-construction observations, input rendering, authorization scope on own data). |
| Top-level response header enumeration | limited | Cloudflare challenge intercepts curl with credentials. CSP/HSTS/XFO/Referrer/Permissions headers could not be confirmed via direct curl or via the in-page agent. Recommend the team verify externally. |
| Auth-stripped replay test | limited | The in-page agent runtime blocks credentialed cross-origin fetches, so the standard 'remove auth header and replay' check could not be confirmed. Personal-data endpoints in the API are scoped implicitly via session rather than via path-embedded user IDs, which is the safer pattern by construction. |
| Build verification / source review | not applicable | External review tier — no source code provided. Static review limited to the production bundle. |
Findings (5)
| ID | Severity | Title |
|---|---|---|
| TG-001 | medium | App session tokens stored in localStorage rather than HttpOnly cookie |
| TG-002 | medium | No CSP meta tag; real CSP header could not be confirmed |
| TG-003 | low | Trading parameters changeable without re-auth |
| TG-004 | low | Polygon RPC traffic via Alchemy exposes user request patterns to a third-party |
| TG-005 | low | Plaintext Solana RPC URLs present as string literals in bundle |
The only HTTP cookie set on the document is _dd_s (Datadog session). Trade.fun's own auth-bearing material lives in localStorage under names including token, websocketToken, sessions, plus three high-entropy obfuscated keys. localStorage is reachable by any same-origin script, including third-party libraries loaded by the app (TradingView charting library, Datadog RUM, Google Tag Manager). If any of those is ever compromised — or if a future XSS bug slips through the 48 dangerouslySetInnerHTML usages — the session is stealable. Note: Turnkey's credentialBundle correctly belongs in localStorage by Turnkey's design and is not part of this finding.
DevTools → Application → Local Storage → trade.fun
Move long-lived auth tokens (token, websocketToken, server-issued session) to an HttpOnly + Secure + SameSite=Lax cookie set by the api*.trade.fun backends. Keep only material that must be readable by client-side wallet code (Turnkey credentialBundle) in localStorage, and minimize its lifetime.
The page has no <meta http-equiv="Content-Security-Policy"> element, and the response-header CSP could not be enumerated either via direct curl (Cloudflare bot-challenge intercepts) or from inside the page (the in-page agent could not read top-level response headers). Combined with 48 dangerouslySetInnerHTML usages in the bundle (mostly legitimate — TradingView, emoji, chart layers), the absence of an explicit, restrictive CSP is a defense-in-depth gap. Search inputs that were tested do correctly escape user-typed HTML, but a strict CSP would mitigate any future regression.
trade.fun document response headers
Confirm via direct curl from a trusted IP. If absent or weak, ship a header-mode CSP with a tight script-src (no unsafe-inline, no unsafe-eval if avoidable), frame-ancestors 'none', plus HSTS (includeSubDomains, preload), X-Content-Type-Options: nosniff, and Referrer-Policy: strict-origin-when-cross-origin.
Slippage tolerance, priority fee, bribe / tx-speed presets, and Quickbuy settings can all be modified from the gear-icon settings dialog with no re-authentication step. Standalone this is fine — it's a UX expectation. The chained risk is that if a future XSS were exploited, an attacker could push slippage to ~99% and have the next user-initiated trade self-drain via slippage on a constructed swap. Mitigated for now by the input-escaping pattern observed in tested fields.
Settings → Trading subtab
Optional: require a step-up auth (re-enter password / Turnkey re-stamp) before saving a slippage value above some threshold (e.g., 5%). Or cap slippage server-side regardless of client-set value.
Polymarket reads route through polygon-mainnet.g.alchemy.com. This is the standard pattern for reading Polymarket on-chain data, but Alchemy will see your users' polling cadence, which markets they read, and which positions they hold (correlated to wallet addresses queried). Not a token-leak risk; it's a data-residency / vendor-disclosure concern.
Outbound network — Polymarket data fetch path
Either disclose this in the privacy policy, or front-end with an internal proxy (e.g., apiv2.trade.fun/poly/...) so the read pattern looks first-party.
http://api.mainnet-beta.solana.com (and http://api.devnet.solana.com, http://api.testnet.solana.com) appear as string literals in the production JS bundle. These are likely web3.js library defaults that the runtime never actually selects (the app uses https://sender.helius-rpc.com and 0slot relays at runtime). Worth confirming none of the fallback / error-recovery paths can land on plain-HTTP.
/assets/index.BDT8T3i8.js
Either patch the constants to enforce HTTPS, or add a runtime guard that rejects non-HTTPS connection strings.
This audit was performed by Opcode using AI-assisted review with human oversight. No audit can guarantee the complete absence of vulnerabilities. This report is not financial or legal advice.
© 2026 Opcode — opcode.run