New, and not audited yet
The audit.
What is being reviewed, what is not, what we did before handing it over, and where the engagement stands. Written so a firm can price it from this page and anyone else can hold us to it.
Budget
$3,500 – $5,000
chosen and set aside
Where it stands
Picking the firm
proposals in hand, nothing signed yet
Then
About two weeks
from signature to report, on the firm’s estimate
In scope.
| Contract | Lines | Address | What it does |
|---|---|---|---|
| SounderExecutor SounderExecutorV3.sol | 250 | 0xA93856…a552 2026-09-10 | Runs a fill through the chain’s router, counts what arrives, reverts if it comes up short, and burns SOUNDER inside the same transaction. The contract people route money through. |
| SounderOrders SounderOrders.sol | 187 | 0x4CF734…f2bB 2026-09-14 | Limit orders with a floor on chain. Anyone may fill an order the chain can meet; the SOUNDER escrowed with it is burned on the fill. |
| SounderLens SounderLens.sol | 169 | 0xdbd0dd…d6f3 2026-09-04 | View only. The pool readings and the fee composition, from inside the chain. No storage, no owner, cannot hold a token. |
| SounderBurner SounderBurner.sol | 227 | not deployed | Buys SOUNDER with a fee and destroys it. Source complete and tested; not deployed until a plain SOUNDER pool exists to buy from. |
For reference, not for review: the two earlier executors (SounderExecutorV2.sol, 225 lines; SounderExecutor.sol, 190 lines). They are retired, still callable, and hold nothing. Out of scope: the chain’s router, Permit2, the Uniswap v3 and v4 contracts and every pool. They are read and called, not owned.
What must always hold.
- Nothing at rest
- No contract in scope holds a token between transactions. A balance left in any of them after a call is a bug.
- The floor holds
- A fill that returns less than the caller’s floor reverts, whatever the router reported. The check is on the contract’s own balance, not on a number from the router.
- The burn is real
- Every fill moves the quoted SOUNDER from the caller to the dead address in the same transaction, or the fill does not happen.
- No owner
- No address can pause, upgrade, drain or replace a dependency. The one privileged role is a keeper on the executor and the orders contract, which can set the SOUNDER burn quantity per fill and a ceiling per input token, both logged, and nothing else. It cannot reach a balance.
- Keyed off msg.sender
- Approvals, balances and outputs belong to the caller. tx.origin is never read.
- Refusals are named
- Every revert carries a selector with a name, so a refusal can be read by a wallet and by a person.
What was done before handing it over.
- The scope, fixed
- Six source files, 1,248 lines. Four are the review; two are retired executors kept for reference. Nothing else is ours on this chain.
- Tests on the real bytecode
- Twenty-seven tests, every one run against the chain’s own pool manager, router and Permit2, forked at a named block. No mocks.
- Every external call named
- Which contracts are called, with what, and what can come back, written beside the code. The router’s own surprises on this chain (the 64-byte v3 path, the price limit it refuses) are documented where they bite.
- The deployment reproducible
- Compiler, optimizer runs and constructor arguments published for each live address, so the bytecode on chain can be rebuilt from the source in the repository.
- Known behaviour written down
- What the contracts deliberately do not guard (the router’s own price limit, hooked pools taking their toll inside the swap) is stated up front, so it is not rediscovered as a finding.
What happens with the result.
The report is published here in full: every finding with its severity, what we changed, and what we chose to leave as is with the reason. Until then every page that touches the executor keeps saying what it says today: new, and not audited yet.