fluxswap

A decentralized exchange (DEX) protocol in Solidity, built with Foundry. Liquidity pools, a router, staking and a timelock - with invariants and full test coverage.

TL;DR

A decentralized exchange (DEX) protocol in Solidity: liquidity pools, a router, staking and a timelock. The contract moves real funds, so a bug is not a fix for the next release, it is lost money. That is why invariants and full test coverage in Foundry matter, not saying it looks like it works.

Overview

Most software lives on the fact that bugs can be fixed. An on-chain contract takes that comfort away: it is immutable and holds other people's money. That inverts how you write code, because you no longer check that the happy path works, you check that a rule meant to hold always cannot be broken.

fluxswap is built around that difference. Liquidity pools, a router, staking and a timelock are features, but the real work sits in the invariants that must hold after every possible sequence of operations, including the one nobody foresaw.

Code you cannot patch after the fact

An ordinary app has a bug, you ship a fix, life goes on. An on-chain contract is immutable and holds other people's money, so a bug in the liquidity pool logic is not a defect, it is a vector someone drains funds through. There is no release number two where you fix it.

That one property changes everything. You write assuming that everyone looking at the contract is hunting for a way to break its rules, and that the only defense is proving they cannot be broken.

Pool.sol · bash

uint256 kBefore = reserveX * reserveY;
_swap(amountIn, amountOut);
require(reserveX * reserveY >= kBefore, "K");

Individual tests check specific inputs you invent yourself, so they check only what you already anticipated. Invariant tests in Foundry do something stronger: they randomly bombard the contract with thousands of operation sequences and after each one check that the rule still holds.

Token sums add up, the reserve product does not drop, nobody withdrew more than they put in. The difference is fundamental, because it is the fuzzer, not you, that invents the scenario which breaks the contract, and it does so thousands of times in a row.

1000+

random sequences per invariant

scenarios breaking the constant-product rule

The timelock, or time to react

Warning

The timelock on sensitive operations exists so parameter changes cannot be pushed from one minute to the next. Even the owner waits, and the community sees what is coming before it happens, with time to react if the change is hostile.

This safeguard does not protect against a bug in the code but against abuse of privilege. Without a timelock the owner could quietly reset protocol parameters just before an attack. With it, every such change is visible and delayed, which strips it of the element of surprise.

Proof instead of hope

The result is a protocol whose security rests on proof, not on the belief that we tested the most important cases. The invariants hold across thousands of random sequences, sensitive changes are delayed by the timelock, and the most dangerous rules, like the constant reserve product, are enforced directly in the contract code.

Invariants and what they guarantee

Invariant	What it guarantees
Constant product	the reserve product does not drop after a swap
Token sum	deposits equal withdrawals plus balance
Withdrawal	nobody takes more than they put in
Timelock	parameter changes are delayed and public

More projects

More work from the same category - see how we tackle similar challenges.

Have a similar project?

Get in touch - a quote is free and comes back within an hour.