| name | symmetry-sniper |
| description | Find asymmetric logic in paired smart-contract operations that should mirror each other (deposit/withdraw, mint/burn, stake/unstake, add/remove, open/close, and single-vs-batch variants) where the mismatch breaks an invariant, omits a check present on only one side, or lets an attacker extract value by round-tripping. Use when reviewing contracts that expose paired or inverse state-changing entry points. |
Analyze the codebase for symmetry violations: paired operations that should be logical inverses or strict mirrors but differ in ways that break invariants, bypass checks, or create profit and leakage paths.
Only report issues that can cause an invariant break, unauthorized state change, value extraction, fund leakage, locked funds, or accounting drift an attacker can force. A difference that is documented and safe, internal-only with no attacker reach, or that does not move security-critical state is not a finding.
Applicability gates
Proceed if either is present:
- obvious operation pairs by naming, docs, tests, events, or interfaces (deposit/withdraw, mint/burn, stake/unstake, add/remove, open/close)
- single vs batch variants (doX vs doMany/multicall) operating on the same core state or assets
Otherwise do not force findings.
High-signal probes
1) Map the candidate pairs
Use naming, events, interfaces, and tests to identify operations that are meant to mirror. Include router and wrapper functions against the underlying core functions they call.
Establish the intended symmetry before judging any difference. If no pair is actually meant to mirror, do not report.
2) Diff state and value across the pair
For each pair, compare the two sides directly:
- state updates (which mappings, struct fields, and totals change, and by how much)
- asset movements (token/ETH transfers, fee collection, burns, escrow changes)
- edge cases (zero, max, boundary conditions, partial fills, cancellation paths)
Report when the pair fails to conserve or correctly invert the quantity it tracks (shares, totalAssets, balances, debt) and an attacker can gain value or lock redemptions.
3) Authorization parity
Check that every sensitive guard on one side has a counterpart on the other: roles, ownership, allowlists, pausing, limits.
Report when a check exists on one side but is missing on its counterpart, enabling an unauthorized exit, withdraw, burn, or close.
4) Rounding, fees, and round-trips
Look at the direction each side rounds and how fees apply across a full cycle.
Report when an attacker can round-trip a pair to extract value or skip a fee, or when repeated cycles produce attacker-favorable drift.
5) Batch versus single parity
For batch and multicall operations, the per-item behavior must match the single path:
- per-item validation and access control are preserved
- limits and caps apply per-item or per-batch as intended and cannot be bypassed
- failures are handled intentionally (atomic vs partial) without enabling griefing or accounting drift
Report when the batch path skips a check or constraint the single path enforces and an attacker can exploit it.
