Security at Pantheon.

Pantheon is a self-custody trading interface. That single design choice does more for your security than every other item on this page combined: we never hold your funds, never sign transactions on your behalf, and never have the ability to move money out of your wallet — even if our entire infrastructure were compromised. Everything else here is defense-in-depth on top of that core property.

Self-custody by default

Every order placed through Pantheon is signed locally in your browser using your wallet (MetaMask, WalletConnect, etc.). The signed payload then goes directly from your browser to Hyperliquid, the underlying exchange. Pantheon's servers do not see your private key, your seed phrase, or the signed payload's contents in a way that would let us replay or alter it.

• No private keys ever leave your device.
• No server-side signing for any user trade, ever — this is a hard architectural rule, not a configuration we could quietly turn off.
• No custodial accounts. Your funds sit in your wallet on Hyperliquid; we don't have a deposit address for you.

The practical implication: if Pantheon's website went offline right now, your open positions and balances on Hyperliquid would be unaffected, and you could close them from any other Hyperliquid client. We are a UI on top of an exchange you already control.

Account authentication

For features that aren't trade-related — your trading journal, analytics, settings — Pantheon uses Clerk as the authentication provider. Clerk handles session management, password storage, multi-factor enrollment, and OAuth flows. Two independent benefits:

• We don't write our own auth code, which is the single largest class of preventable vulnerabilities in web apps.
• Clerk's security posture (SOC 2 Type II, regular pen-tests) is inherited by Pantheon as a sub-processor.

API routes that touch user-specific data require a valid Clerk session by default. The list of routes that are explicitly public is short and reviewed every time it changes — currently just the contact form.

In-transit security

• HTTPS-only. Every page is served over TLS. Plain HTTP requests are 308-redirected at the edge. After your first visit, your browser is told (via HSTS with a 2-year max-age) to refuse plain HTTP for pantheonfi.com forever.
• TLS 1.2+ minimum. Older protocol versions (1.0, 1.1) are rejected at the edge. TLS 1.3 is preferred.
• HTTP/3. Modern transport with reduced handshake latency and better resilience on flaky networks.
• Strict origin certs. Cloudflare requires that our origin (Vercel) presents a fully valid certificate before forwarding traffic — there's no “permissive” fallback.

Application-layer hardening

• Content Security Policy. Pantheon ships a tightly-scoped CSP allowlist for scripts, frames, and outbound connections. Third-party origins (Clerk, Hyperliquid, Cloudflare Turnstile) are listed explicitly; everything else is denied.
• Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy are all set on every response. Camera, microphone, geolocation, payment, and USB APIs are disabled at the policy level.
• CORS allowlist on our edge API. Our Cloudflare Worker (api.pantheonfi.com) only echoes Access-Control-Allow-Origin for hosts we explicitly recognize. Random websites can't use our infrastructure as a free Hyperliquid proxy from the browser.
• Per-IP rate limits at the edge. Both the price /info channel and the order /exchange channel have generous per-IP caps that absorb normal page-load bursts but kill scraper-grade sustained traffic.

Edge protection

Pantheon sits behind Cloudflare. The relevant active layers:

• Web Application Firewall (WAF) with the Cloudflare Managed Ruleset and OWASP Core Ruleset deployed in block mode. Catches SQLi, XSS, command injection, and the OWASP Top 10 patterns before they reach our application.
• Leaked-credentials check. Login attempts using credentials from public data dumps are flagged and blocked at the edge.
• Bot Fight Mode + Super Bot Fight Mode. High-confidence bot signals are blocked outright; medium- confidence signals get a managed challenge. Verified bots (Googlebot, etc.) pass through.
• Page Shield. Continuous monitoring of every third-party script our pages load (Clerk, Turnstile, etc.) for unauthorized changes. If any of our dependencies' CDNs were compromised and started serving malicious code, we'd be notified before our users were affected.

Bot protection on the contact form

Our public contact form is gated by Cloudflare Turnstile (an invisible-by-default CAPTCHA replacement) plus a server-side honeypot field. The vast majority of legitimate visitors submit without ever seeing a challenge.

Error monitoring & PII handling

When an unexpected error occurs in your browser or our servers, we send a stack trace to our error-monitoring service so we can diagnose and fix it. Before any event leaves your device, it passes through a scrubbing layer that:

• Masks wallet addresses (any 0x-prefixed 40-character hex) anywhere they appear in the event.
• Masks transaction hashes and signature components (32-byte hex) the same way.
• Fully redacts the body of any /exchange request — these contain signed action payloads that should never leave your device, even in scrubbed form.
• Drops object fields named signature, secret, apiKey, and similar.

We also explicitly do not use Sentry's Session Replay feature, which would record user-visible screen activity. Even with masking, we don't want a market-order entry, signed payload, or wallet address ever captured to a third-party SaaS. We accept slightly harder debugging in exchange for not creating a class of “the replay leaked it” bugs.

What we explicitly don't do

These are commitments. If any of them ever changes, we'll announce it loudly and in advance.

• We never custody your funds. Pantheon does not have a custody license, a deposit address, or a “user balance” we control.
• We never sign transactions for you. Every trade requires a fresh signature from your wallet; we cannot place orders on your behalf and never will.
• We never log full signed payloads or signatures to our servers or to third-party error-monitoring.
• We never sell user data. We don't run an ad network, we don't broker user lists, we don't license the journal text you write to anyone.
• We never require KYC, government ID, or bank information to use the trading interface.

Reporting a vulnerability

If you've found a security issue, please report it via the contact form with the category set to Security. The form routes directly to our security inbox and is our canonical channel. For automated tooling, our security.txt is published per RFC 9116.

Response SLA

• Acknowledgement within 24 hours (weekdays) / 48 hours (weekends).
• First triage and severity classification within 3 business days.
• Fix ETA communicated in the first triage. Critical issues (credential exposure, auth bypass, ability to move user funds) are reviewed same-day regardless of day.

Safe harbor

We will not pursue legal action against security researchers who make a good-faith effort to follow our disclosure policy. Don't intentionally degrade service for our users, don't access another user's wallet or PII (use your own test accounts), and don't disclose publicly until we've had a reasonable window to ship a fix.

Researchers who report issues in good faith get named in our acknowledgments (with permission) once a fix ships.

What's out of scope

The following are not Pantheon vulnerabilities even if you can demonstrate them — please report them to the appropriate upstream:

• Hyperliquid protocol bugs. Their signing, matching engine, margin math, liquidation logic — all upstream. Report to Hyperliquid.
• Clerk platform vulnerabilities. Report to Clerk.
• User-wallet compromise via phishing or device malware. Self-custody means we can't defend users from attacks on their own device.
• Theoretical risks without demonstrated impact. Raw automated-scanner output without a working exploit isn't actionable.