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 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 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.