Security & Risks

Status: HyperSui is under active development. Security controls and procedures below reflect our intended posture and will be finalized before mainnet. Funds from the current presale are allocated to audits, monitoring, and operational readiness.

10.1 Risk Classes

• Smart-contract risk. Bugs or incorrect assumptions in AMM or routing logic may lead to loss or mis-accounting despite reviews.

• Market & liquidity risk (LPs). Impermanent loss (IL) and thin liquidity can erode returns; fee APRs fluctuate with volume/TVL and are not predictive.

• Execution risk. Stale quotes or overly tight slippage during volatility can cause failures or worse fills if users widen limits without context.

• Interface & phishing risk. Look-alike tokens, spoofed domains, or unsolicited signatures can misdirect funds. Verification and “import-by-address” are mandatory habits.

• Bridge/oracle dependency (where applicable). External components for wrapped assets or price references introduce correlated failure modes.

10.2 Security Controls (prevent & reduce blast radius)

• Non-custodial design. Funds stay in user wallets; the app never asks for seed phrases or private keys.

• Contract reviews & audits. Contracts are reviewed pre-release and monitored post-launch; independent third-party audits are planned prior to mainnet.

• Change control. Upgrades and parameter changes are executed via multisig + timelock with public changelog entries and contract/version references.

• Scoped circuit breakers. Ability to disable specific pools or routes under anomaly without halting the entire protocol; emergency paths are documented and limited in scope.

• Safe token discovery. Curated lists plus explicit import-by-address; the UI flags unusual symbols, high price impact, and off-domain prompts.

10.3 Monitoring & Alerts

• On-chain telemetry. Continuous tracking of swaps, fee flows, pool balances, and anomalous routes; alerting on sudden TVL shifts, abnormal price impact, or fee spikes.

• Release transparency. Semantic versioning and public Changelog for deployments, parameter changes, and incident summaries.

• Status communications. Incident notices and post-mortems are published through verified channels alongside mitigation steps and affected contract addresses.

10.4 Incident Severity & Playbooks

• Severity S0 — Critical loss or ongoing exploit.

  • Immediate: Pause affected pool/route; block risky paths via router guards.

  • Notify: Publish “critical incident” banner in app + official channels; share impacted addresses/tx.

  • Contain/Recover: Hotfix behind timelock exception approved by multisig; snapshot state where applicable; coordinate with partners/exchanges if needed.

  • After: Full post-mortem within 72h with root cause, patch, and user guidance.

• Severity S1 — Material but contained anomaly.

  • Restrict impacted route(s); raise user warnings; deploy fix via standard timelock; post summary.

• Severity S2 — Degradation or UI/quoting issues.

  • Raise in-app notice; prefer safe re-quotes; publish status and expected resolution window; roll into next release notes.

10.5 User Safety Checklist (everyday hygiene)

• Use only verified links; confirm you’re on the official domain before connecting a wallet.

• Verify by address, not by name/icon when importing tokens or pools.

• Start with small test transactions, especially on new pools or unfamiliar assets.

• Keep slippage conservative; widen only with clear rationale and awareness of pool depth.

• Never share seed phrases or sign unsolicited approvals; stop if the UI shows unusual impact or off-domain prompts.