> ## Documentation Index > Fetch the complete documentation index at: https://docs.dequan.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Key Handling Most trading-tool docs hand-wave on this topic. We're going to be specific because security claims that aren't specific aren't claims, they're vibes. ## Your main wallet Your main wallet's private key — the seed phrase you control, the keys for Phantom/Solflare/Backpack/hardware — **never enters Dequan's systems in any form.** * We do not request it. * We do not receive it. * We do not store it. * We have no recovery flow for it because there is nothing on our side to recover. Every signature for non-custodial trades originates from your wallet's signing surface (browser extension, mobile app, hardware device). Dequan receives the *signed result*, not the key. ## Authentication: signed challenge, not key transmission When you "sign in" to Dequan, the system asks your wallet to sign a short, random message — a *challenge* — generated server-side specifically for this authentication attempt. The signed message proves you control the wallet's private key without transmitting it. The challenge is single-use: replaying the same signed message later doesn't work because the server only accepts that exact challenge once, and it expires within a short window if not used. The signature you produce is bound to: * The specific challenge string * A timestamp window * The Dequan domain A signed challenge captured by an attacker cannot be replayed against a different domain, a different time window, or a different challenge. The standard is the same as production-grade Sign-In-with-Solana implementations. ## Session tokens, not key reuse After successful challenge auth, the server issues a short-lived **JWT** (JSON Web Token) that authenticates subsequent API calls during your session. The JWT: * Is signed by the server with a key you cannot forge * Expires automatically after a short window * Can be revoked instantly if needed (e.g., if you log out, hit a rate limit boundary, or the system detects abuse) This is the same auth pattern used by major financial APIs. It is conventional, well-understood, and battle-tested. ## Lightning Wallet keys [Lightning Wallet](/execution/lightning-wallet) is the only place where Dequan holds key material on your behalf — and it is held inside a **hardware-backed key management boundary** that meets institutional-custody standards. Operators cannot read the key. The system can only use the key to sign trades that match enabled rules. The funds in Lightning Wallet are sandboxed: capped balance, withdrawable any time, never silently transferred elsewhere. The key handling for Lightning is more rigorous than industry-standard "encrypt at rest" — see [Lightning Wallet](/execution/lightning-wallet) for details. ## What we log, what we don't Logged for operational and audit purposes: * Public addresses * Trade signatures (already public on chain) * Per-trade timing data * Errors and rate-limit events **Never** logged: * Private keys (we don't have them) * Wallet seed material (we don't have it) * Session tokens beyond what's needed to validate the active session * Personal identifying information beyond what you voluntarily provide ## What you should still do Even with all of the above, **basic wallet hygiene is on you**: * Use a hardware wallet for long-term holdings. * Use Dequan with a wallet whose balance you'd be ok losing if your machine were compromised. * Don't paste your seed into anything, ever. * Verify the URL is `snipe.dequan.xyz` before connecting. * Verify the URL of any wallet popup matches. We can secure our half of the contract. We can't secure your laptop. How the referral system prevents farming and self-referral abuse.