Technical audit report

Every report opens by stating what it covered, because a finding only means something against a scope. The commit is named so you can check that what shipped is what was read.

We found twelve issues: one critical, two high, four medium, one low and four informational. Every actionable finding was fixed by the team and re-verified by us against the original exploit, except one medium accepted with a documented plan.

The critical finding allowed complete draining of pooled funds and was reproduced on a fork before disclosure. After remediation, the codebase holds against every attack we constructed.

Severity scales are not standardised across the industry, so a report that does not define its own is asking you to guess. Ours is impact first: what happens if someone exploits it.

Every finding carries a status. A report that lists issues without saying what became of them tells you only that someone looked.

HIGH. Router.sol, swapExact(), lines 88-97.

swapExact() accepts a minimum-out of zero and no deadline. Pending transactions can be sandwiched: an attacker moves the price before the victim's swap executes and restores it after, pocketing the difference. Stuck transactions can also execute much later at a worse price.

In plain terms: an order without a price floor or expiry is a blank cheque. Bots that watch pending transactions can worsen your price on purpose and keep the difference.

Impact: every user swap is exposed to MEV sandwiching — a measurable, ongoing value leak rather than a single dramatic theft.

Proof of concept: a sandwich bot script on a fork extracted 2.4% from a sample swap with zero minimum-out.

Recommendation: require a non-zero minimum output and a deadline on every swap, and have the front-end set sane defaults.

Resolution: fixed and verified. The sample sandwich now reverts the victim transaction instead of filling at the worse price.

TA-07, medium. RewardStaker.sol, claimAll(), lines 112-126.

claimAll() iterates every historical reward epoch for the caller. A long-lived account eventually exceeds the block gas limit and can never claim through this path again.

In plain terms: the claim function re-reads a user's whole history every time. Stay staked long enough and your own history grows too heavy to carry, locking the claim button for you.

Impact: long-term stakers, the protocol's best users, can be locked out of rewards. Funds are not lost but recovery requires a migration.

Resolution: accepted for launch with a documented cap on epoch count and an accumulator refactor scheduled for the next release. We re-tested the cap.

We publish accepted findings rather than quietly dropping them. A report where everything was fixed is either a very short engagement or an incomplete account of one.

After the team's remediation commit, we re-executed every proof of concept, the full fuzzing corpus and the invariant suite. No fixed finding reproduces, and the accepted finding's cap holds under test.

The public attestation for this engagement references both the audited and the remediated commit hashes, so anyone checking it can tell which code was read and which code shipped.