Security at LiquitX

This page describes the security work behind the LiquitX protocol as it stands today: the engineering discipline, the internal audit arc, and what is still ahead. Everything here is internal work. No external audit has been completed yet, and we say so plainly.

Development Discipline

Every contract starts as a specification. Expected behaviors, unwanted behaviors, edge cases, and attack vectors are written down first, and tests encoding that specification are written before the implementation they constrain.

The protocol test suite is organized into five categories: unit, security, fuzz, adversarial, and integration. Each category runs separately in CI, and changes do not merge while any category fails.

Internal Audit Arc

From April through June 2026 the protocol went through multi-agent internal security audits: repeated review passes over the contract surface, with every finding tracked to a fix. Two remediation waves came out of that work:

MERGED 2026-04-24

Remediation batch 1

6 critical and 8 high severity findings fixed, along with a set of medium severity fixes.

MERGED 2026-06-10

Remediation batches 2 and 3

4 critical, 5 high, and 2 medium severity findings fixed.

These counts are findings we found and fixed ourselves, before any external review. We publish them because a codebase is better described by how issues get found and closed than by a claim that there are none.

Threat Model

A documented threat model is maintained for the protocol: attack surfaces, trust assumptions, privileged roles, and the invariants each contract must preserve. It is revisited as the system evolves rather than written once and shelved.

External Audit and Current Deployment

An external audit is planned before any mainnet deployment. The protocol currently runs on the Base Sepolia testnet only.

Design Principles

A few rules hold across the codebase:

Checks-effects-interactions ordering in every state-changing function.
Custom errors instead of string reverts, so failure modes are explicit and machine-decodable.
Explicit state machines for asset lifecycles: transitions are enumerated and tested, never implied.
Fail-closed admin surfaces: privileged operations deny by default when preconditions are not met.

Questions about any of this are welcome. Contact us