Security
QsnDEX implements defense-in-depth security measures across all three layers of the architecture: smart contracts, backend, and frontend.
Smart Contract Security
Reentrancy Protection
Reentrancy guards are applied at two levels:
- OpenZeppelin ReentrancyGuard: Used on the Router, all Staking contracts, Launchpad, BatchSwap, FeeCollector, and LimitOrder contracts. This is a standard mutex-based guard that prevents nested calls to protected functions.
- Custom single-bit lock on Pair: The Pair contract uses a gas-efficient single-bit reentrancy lock rather than the full OpenZeppelin implementation. The invariant (
x * y >= kfor constant product, or the StableSwap equivalent) is checked after any callbacks complete (including flash swap callbacks), ensuring that no state manipulation during the callback can violate pool integrity.
Economic Attack Mitigations
| Protection | Mechanism |
|---|---|
| First-depositor attack | MINIMUM_LIQUIDITY of 1000 wei locked on pool creation |
| Donation attack | Permanent locked liquidity prevents full pool drainage |
| Stale transaction execution | Deadline parameter on all Router functions |
| Excessive slippage | Minimum output amount enforced on all swap functions |
| Fee-on-transfer tokens | Actual balance measurement instead of stated transfer amounts |
Access Control
- Two-step ownership transfer on the FeeCollector contract. Ownership is not transferred in a single call; the new owner must explicitly accept the transfer. This prevents accidental loss of admin access due to typos or incorrect addresses.
- Owner-only configuration for fee parameters, with hard-coded maximum bounds enforced at the contract level.
Solidity-Level Protections
- Solidity 0.8+ provides built-in overflow and underflow protection on all arithmetic operations. No external SafeMath library is required.
- EIP-2612 Permit support on LP tokens enables gasless approvals via off-chain signatures, reducing the attack surface from approve-based phishing (users sign typed data with clear context rather than sending blind approval transactions).
- EIP-712 domain separator includes chain ID and is recalculated on fork detection, preventing cross-chain signature replay.
Backend Security
Rate Limiting
All resource-intensive endpoints are protected by Redis-based rate limiting. Limits are applied per-user (identified by wallet address or IP).
| Endpoint Category | Rate Limit |
|---|---|
| AI analysis | 10 requests/hour |
| Autopilot | 5 requests/hour |
| Safety checks | 20 requests/hour |
Rate limit state is stored in Redis with automatic expiration, ensuring limits reset correctly even if the backend restarts.
Input Validation
All user-supplied inputs are validated before processing:
- Token addresses are checked for valid format and checksummed.
- Numeric values are bounded and checked for overflow.
- Query parameters are sanitized to prevent injection attacks.
CORS
Cross-Origin Resource Sharing (CORS) headers are configured to restrict API access to authorized frontend origins only. This prevents unauthorized third-party sites from making requests to the backend on behalf of users.
Secret Management
No private keys, API secrets, or sensitive credentials are stored in the codebase or database. All secrets are loaded exclusively from environment variables at runtime. Database connection strings, Groq API keys, and RPC endpoint URLs are never committed to version control.
Frontend Security
No Secret Storage
The frontend application does not store any private keys, seed phrases, or sensitive credentials. All transaction signing is delegated to the user's connected wallet (via RainbowKit/wagmi). The frontend only constructs unsigned transaction data and passes it to the wallet for approval.
Transaction Simulation
Before presenting a transaction for the user to sign, the frontend performs:
- Gas estimation to predict transaction costs and detect likely reverts before submission.
- Transaction simulation where possible to preview the expected outcome and surface errors before the user commits gas.
Safety Warnings
The swap interface integrates token safety information directly into the trading flow. When a user selects a token that has been flagged by the safety check system (honeypot detection, high tax tokens, unverified contracts), warnings are displayed inline within the swap UI. This provides contextual risk information at the point of decision, rather than requiring users to check a separate tool.