Liquid
PartnersSupport

Security & Audits

How Liquid is audited, hardened, and disclosed against — backed by the Lux security stack.

Security & Audits

Liquid sits inside the Lux security stack — shared audit cadence, formal-verification harnesses, post-quantum cryptography, MPC-backed key management, Quasar post-quantum consensus, and disclosure paths used across every Lux protocol.

Audit coverage

External audit reports live in luxfi/audits (LaTeX, peer-reviewed). Per-component reports tracked there with the mainnet-deployment tag they cleared.

ComponentAuditSource
Smart contracts2025-12-30 contracts auditluxfi/audits
Cryptography2025-12-30 crypto auditluxfi/audits
Architecture2025-12-30 architecture reviewluxfi/audits
Consensus2025-12-30 consensus auditluxfi/audits

For Liquid-specific deltas (transmuter, position decay, strategy classifier), re-audit scope runs before each major version bump.

Internal security practices

  • Foundry unit + invariant tests in src/test/ and src/test/Invariants/
  • Foundry fuzzing — 1000-run fuzz suite on every PR
  • Halmos — symbolic execution over check_* properties (make halmos)
  • Slither + Aderyn + Semgrep — static analysis on every PR (make security)
  • Multi-reviewer code review — minimum two engineers + one security
  • Forked-mainnet integration tests — strategy adapters run against mainnet state
make audit       # lint + tests + slither + semgrep + aderyn
make halmos      # symbolic property checking
make test-fuzz   # fuzz suite

Upgradeability & governance

  • Core vault logic (Liquid.sol, LiquidPosition.sol, LiquidTransmuter.sol) — immutable. No upgrade path.
  • Adjustable parameters (caps, fees, classes, transmuter cadence) — Lux DAO governance.
  • Strategy adapters + curator/allocator/classifier/gauge — admin role held by the Safe owned by ModuleGovernorV1 (see Governance).
Proposal on lux.vote
  → DLUX-weighted vote (StrategyV1)
  → ModuleGovernorV1 queues + executes through Safe
  → Safe calls Liquid contract

Post-quantum cryptography — luxfi/crypto

NIST-PQC algorithms run in production today. Every signing surface is crypto-agile — verifiers dispatch on the algorithm tag, accepting both classical and PQ keys.

PrimitiveSpecClassUse
ML-KEM-768FIPS 203PQ KEM (Module-LWE)X-Wing hybrid, KMS replication
X-WingIETF draftHybrid KEMML-KEM-768 + X25519
ML-DSA-65FIPS 204PQ sig (Module-LWE+SIS)PQ identity proofs
SLH-DSAFIPS 205PQ sig (hash-based)Stateless backup signature
BLS12-381Classical pairingAggregate sigs, validator threshold
Ed25519, secp256k1ClassicalService signing, EVM

GPU-accelerated batch verification for ML-DSA, ML-KEM, and BLS.

Threshold + MPC — luxfi/mpc, luxfi/threshold

Three distinct threshold paths, used for different purposes:

SchemeTypeRoundsRepo
CGGMP21Threshold ECDSAMulti-roundluxfi/mpc
FROSTThreshold EdDSA2-roundluxfi/mpc
RingtailThreshold lattice (Ring-LWE / Module-LWE)2-roundluxfi/ringtail via luxfi/threshold

Ringtail is its own Ring-LWE / Module-LWE 2-round threshold scheme — it is not "threshold ML-DSA". They are separate cryptographic constructions that both happen to be lattice-based.

ML-DSA-65 is used in Quasar alongside Ringtail as a separate single-signer PQ identity signature.

Consensus — Quasar (luxfi/consensus)

Liquid runs on Lux chains protected by Quasar, the post-quantum consensus overlay. Quasar offers three independent signing paths, each toggleable per-deployment:

PathLayerScheme
1BLSBLS12-381 threshold (classical)
2RingtailRing-LWE 2-round threshold (PQ)
3ML-DSA-65FIPS 204 identity signatures (PQ)
ModeCompositionUse case
BLS-onlypath 1Fastest classical, PoA-style
BLS + ML-DSApaths 1+3Dual with PQ identity
BLS + Ringtailpaths 1+2Dual with PQ threshold
Triple (full Quasar)paths 1+2+3Full PQ — IsTripleMode()

In triple mode, all three signing paths run in parallel goroutines. Liquid mainnet runs on the Lux C-Chain under triple-mode Quasar.

Z-Chain — PQ identity via ML-DSA + Groth16

Lux Z-Chain (luxfi/chains/zkvm) provides PQ identity by verifying ML-DSA-65 signatures inside Groth16 zk proofs. This composes PQ identity attestations into existing zk circuits without revealing identity material. Z-Chain also provides FHE compute (TFHE/LuxFHE) and zk verification precompiles for cross-chain proofs.

Cross-chain — Warp V2

luxfi/warp — cross-chain messaging with PQ safety via random Ringtail validation plus private messaging via Z-Chain FHE. Liquid uses Warp for cross-chain settlement notifications when strategies bridge yield back to Lux.

Key management — luxfi/kms

Operational keys (allocator operator, gauge keeper, governance Safe co-signers) live in luxfi/kms — the MPC-backed Lux KMS. Never plaintext, never env files, never plaintext in databases. Universal Auth (client-id/secret → short-lived bearer); deploy CI fetches per-environment secrets via documented KMS endpoints. Replicated state encrypted with age (X25519 → X-Wing PQ-upgrade path), backed by luxfi/zapdb.

Compliance

For deployments using regulated collateral (security tokens, regulated yield), Liquid pairs with luxfi/compliance:

  • Per-vault KYC level via LiquidComplianceGate
  • IDV providers via hanzoai/idv (Jumio, Onfido, Plaid)
  • AML screening: OFAC SDN, EU consolidated, UK HM Treasury, PEP — plus optional Jube sidecar for real-time scoring
  • Travel Rule (FATF Rec. 16), CTR detection, stablecoin policies
  • 20 jurisdictions, 14 frameworks (US SEC+FINRA, UK FCA, IOMFSA, EU MiCA, MAS, ASIC, FINMA, …)

Container signing

Liquid container images are signed with Sigstore Cosign and attested via in-toto:

cosign verify --certificate-identity-regexp '^https://github.com/luxfi/' \
  ghcr.io/luxfi/<service>:<tag>

Vulnerability disclosure

Emailsecurity@lux.network
PGP/.well-known/security.txt
Embargo90 days standard
Bug bountyImmunefi (live with mainnet tag)

In-scope: Liquid contracts, Transmuter, strategy adapters, position NFT, governance gates. Out-of-scope: third-party DeFi protocols (file with the upstream), social engineering, physical attacks.

Resources

Last updated on

On this page