Security
This page is the canonical record of HikariSwap's security posture: what has been done, what is in scope, and how to report issues.
Approach
HikariSwap is engineered to a senior audit standard. The contracts repository ships its full testing and static-analysis configuration so an external auditor can reproduce every result.
- Differential testing of
HikariPairagainst canonical Uniswap V2. The fee-rate change (35 bps total) is the only intentional behavioral divergence; every other code path must produce byte-identical state transitions. - Property-based fuzzing (≥ 10,000 runs in CI) on swap math, LP accounting, and the constant-product invariant.
- Multi-actor invariant testing (≥ 1,024 runs at depth 128 in CI) covering k-monotonicity, solvency, and supply conservation across interleaved actor sequences.
- Static analysis with Slither and Mythril run on every PR.
- Solhint with a strict ruleset on every change.
The Uniswap V2 codebase has been audited continuously by the wider DeFi community for years; staying minimally divergent inherits that scrutiny. The HikariSwap-specific surfaces — fee constants, the token factory and its templates, the locker — receive direct attention.
Immutable bounds
Every owner-settable knob in the protocol is bounded by a constant baked in at deploy time. The bounds cannot be raised — even by a fully compromised owner key. The setter functions revert outside the band and emit a public event on success.
HikariTokenFactory
| Knob | Bound | Source |
|---|---|---|
| Creation price (any archetype) | 10,000 – 500,000 LCAI | MIN_PRICE() / MAX_PRICE() |
| Token decimals | 0 – 18 | Reverted in _validateMetadata |
| Tax rates (per side, immutable per token) | ≤ 1,000 bps (10%) | Constructor of HikariTaxToken |
The factory has no privileged role on any token it deploys — it cannot mint supply it didn't issue, cannot pause a token, and cannot drain holders. Once a token is deployed, the factory's relationship with it ends.
HikariLocker
| Knob | Bound | Source |
|---|---|---|
| Lock duration | ≤ ~100 years | MAX_LOCK_DURATION() |
| Beneficiary | Non-zero address | Reverted in lock() |
Locks are non-custodial in the sense that only the beneficiary can withdraw, and only after unlockAt. Locks can be extended forward in time but never shortened.
HikariRouter
| Knob | Bound | Source |
|---|---|---|
| Deadline | Block-timestamp enforced | Modifier ensure(deadline) |
| Slippage | Caller-supplied amountOutMin / amountInMax | Reverted on every swap path |
The router holds no state and no funds across calls. It is a thin coordinator that wraps WLCAI, sequences HikariPair calls, and refunds dust.
Disclosure policy
If you find a vulnerability in any HikariSwap contract, frontend, or supporting infrastructure, please email hikari@hikariswap.com with:
- A clear description and reproduction steps.
- Expected vs. actual behavior.
- An impact + likelihood severity estimate.
Do not open a public GitHub issue for security findings. We acknowledge within 72 hours and coordinate disclosure timelines, including remediation milestones.
Risks you accept by using HikariSwap
HikariSwap is open-source software, deployed by its maintainers, used at your own risk. By interacting with it you accept that:
- Constant-product AMMs are subject to impermanent loss — your LP position can be worth less than holding the underlying assets.
- Imported tokens are not vetted by HikariSwap. Anyone can deploy a token that looks like
USDC. Always verify the contract address against a trusted source. - Tax tokens deployed via the factory have an owner. That owner can lower (but never raise) tax rates and configure AMM-pair flags. Read the token before you trade it.
- Mintable tokens have a
maxSupply. The owner can mint up to that cap, diluting holders. Read the cap before you buy. - Smart-contract risk is non-zero, even with thorough testing and audits. Do not deposit funds you cannot afford to lose.