Security Audit Report

WalletGuard.ai, powered by Gestalt Labs

April 17, 2026

ID: c82b6d5e

0xf611...7f53EVMBench: 2026-01-tempo-stablecoin-dexv1View audit historyEthereumLive TargetCritical Risk

Verified on BaseVerify externally Prompt 0xd29afd...

Apr 17, 2026, 06:36

Standard AuditModel: Claude Sonnet 4.6

What you got

Tier: Standard ($29)
Model: Sonnet
Specialists completed: 8 of 8

Risk Level: Critical Risk

Efficiency

5C2H4M3L

14 security | 1 code quality | 1 gas

5 Critical: StablecoinDEX.sol (5)

2 High: StablecoinDEX.sol (2)

In-Scope Security Score Guide

8.0 - 10.0Low Risk. No critical issues. Safe for interaction.

5.0 - 7.9Moderate Risk. Some issues found. Review before interacting.

1.0 - 4.9High/Critical Risk. Significant vulnerabilities detected.

Score is based on 16 findings from 9 specialist agents.

Exploit Analysis

Forge fork-validation ran but no findings met the threshold for PoC inclusion. See the per-finding "Forge validated" badges in the report below for individual results.

Executive Summary

The analyzed contract is a decentralized orderbook exchange (AMM/DEX variant) supporting token deposits, order placement, fills, and withdrawals. The analysis identified 3 critical, 3 high, 4 medium, 2 low, and 2 informational findings across 8 specialist agents. The single most dangerous pattern is an unchecked arithmetic underflow in the emergencyWithdraw pathway, which allows any user with zero balance to silently wrap their internal balance to near type(uint128).max and drain the entire token reserves of the contract in a single transaction. This contract is unsafe for deployment in its current state; the critical vulnerabilities allow complete fund loss for all depositors and must be remediated before any mainnet use.

Critical Highlights

criticalemergencyWithdraw has no balance check — arbitrary fund drainage

Any user, even one with no funds deposited, can call a special emergency withdrawal function with any amount they choose. Because the contract uses unsafe math that does not check for negative results, subtracting a large amount from a zero balance silently produces an astronomically large fake balance instead of reverting. The attacker can then withdraw real tokens belonging to other users, draining the entire contract in one transaction.

criticalCEI Violation in withdraw(): State Updated After External Call

The withdrawal function sends tokens to the user before recording that the withdrawal happened. If the token being withdrawn has a callback mechanism (such as ERC-777 tokens), a malicious recipient can re-enter the withdrawal function repeatedly before the balance is reduced, withdrawing the same funds multiple times and draining the contract.

highUnauthorized order cancellation — no msg.sender check in cancel()

The function that cancels orders does not verify that the person canceling the order is the person who created it. Anyone can cancel any open order belonging to any market maker. An attacker can wipe out all active orders on the entire orderbook, disrupting trading and enabling targeted griefing or front-running of profitable orders.

14 Security Findings | 1 Code Quality | 1 Gas Optimization

critical(5)

high(2)

medium(4)

Attack Chain Analysis

Balance Corruption to Full Draincritical

An attacker first calls emergencyWithdraw with an amount exceeding their zero balance. The unchecked underflow in _processWithdrawal (Finding: emergencyWithdraw has no balance check) wraps balances[attacker][token] to near type(uint128).max. The attacker then calls the standard withdraw function, which checks balances[msg.sender][token] >= amount and passes because the corrupted value is enormous. The safeTransfer sends all real tokens held by the contract to the attacker, fully draining every depositor's funds. The CEI violation in withdraw (Finding: CEI Violation in withdraw()) further compounds this by allowing a re-entrant call during the token transfer if the token has a callback hook, accelerating the drain.

emergencyWithdraw has no balance check — arbitrary fund drainageemergencyWithdraw Has No Balance Check — Bypasses All Access ControlsCEI Violation in withdraw(): State Updated After External Call

Order Cancellation Griefing Enabling Profitable Fill Front-Runhigh

An attacker monitors the mempool for large profitable fill transactions. Using the unauthorized cancel vulnerability (Finding: Unauthorized order cancellation), the attacker cancels the target order before the legitimate fill transaction confirms, causing the filler's transaction to revert. The attacker then re-places a similar order at a manipulated price and fills it themselves, capturing the profit. The incomplete order deletion (Finding: Incomplete order deletion in _cancelOrder) leaves stale linked-list state that could further corrupt orderbook traversal.

Unauthorized order cancellation — no msg.sender check in cancel()Incomplete order deletion in _cancelOrder leaves remaining/next/prev fields set

Price Manipulation via Unenforced Deviation and Truncated Quotehigh

Because MAX_PRICE_DEVIATION is never enforced in placeOrder (Finding: MAX_PRICE_DEVIATION constant is defined but never enforced), a malicious maker can place orders at extreme prices. A taker who fills such an order at a large amount may trigger the uint128 truncation bug in fillOrder (Finding: quoteAmount silently truncated when cast to uint128), paying a drastically reduced quote amount while receiving the full base token amount. The maker loses value and the taker profits at their expense.

MAX_PRICE_DEVIATION constant is defined but never enforcedquoteAmount silently truncated when cast to uint128 in fillOrder

Agent Coverage

Agent	Status	Findings	Severity	Confidence	Duration	Coverage
reentrancy	success	4	2C	87%	40.6s	Cross-function reentrancy in withdraw() and emergencyWithdraw(), CEI (Checks-Effects-Interactions) pattern compliance across all state-mutating functions, unchecked arithmetic blocks in _processWithdrawal, Integer overflow/truncation in fillOrder quoteAmount uint128 cast, Access control on emergencyWithdraw, ERC-777 callback reentrancy risk on safeTransfer calls, Linked list integrity in placeOrder, cancel, fillOrder, Balance accounting consistency across deposit/withdraw/placeOrder/fillOrder, uint128 overflow in balance additions, Order existence checks and authorization
access control	success	4		89%	38.6s	Access control on all state-modifying functions (deposit, withdraw, placeOrder, cancel, fillOrder, emergencyWithdraw), Authorization checks: who can cancel orders, who can call emergencyWithdraw, Unchecked arithmetic in _processWithdrawal and its impact on balance underflow, Integer overflow/truncation in fillOrder quoteAmount cast from uint256 to uint128, Linked list integrity in order insertion, cancellation, and fill removal, Reentrancy: CEI pattern compliance in withdraw, fillOrder, emergencyWithdraw, ERC20 safeTransfer/safeTransferFrom usage, Signature/authentication patterns (none present), Initializer protection (no upgradeable proxy, not applicable), Delegatecall patterns (none present), tx.origin usage (not present)
economic	success	6	1C2H1M1L	88%	52.7s	Flash loan attack surface on balance-based order pricing, Oracle dependency (none found — pure orderbook, no price oracle), Access control on all state-mutating functions (cancel, emergencyWithdraw), Integer overflow/underflow in unchecked arithmetic blocks, Safe downcasting from uint256 to uint128 in fillOrder quoteAmount, Reentrancy via safeTransfer (CEI ordering checked in withdraw, fillOrder, emergencyWithdraw), Linked list integrity after cancel and fill operations, Sandwich/MEV exposure on order fills, Governance attack vectors (none present), Fee-on-transfer and rebasing token interactions, First-depositor inflation attacks (no LP share minting), Price deviation constant enforcement
logic validation	success	5	1C1H2M	88%	52.9s	Input validation on all external functions (deposit, withdraw, placeOrder, cancel, fillOrder, emergencyWithdraw), Unchecked arithmetic blocks for underflow/overflow (found critical issue in _processWithdrawal), Authorization checks on order management functions (found missing auth in cancel), Integer overflow and truncation in quoteAmount cast to uint128, Precision loss and rounding direction in fillOrder quote calculation, Linked list integrity in order insertion, cancellation, and removal, State cleanup completeness in _cancelOrder and _removeFilledOrder, Reentrancy: SafeERC20 used, CEI pattern generally followed, ERC-20 standard compliance via OpenZeppelin imports, totalDeposits accounting correctness, getOrders linked list traversal for DoS via unbounded loop
code quality	success	8	1L	87%	1.2m	Reentrancy in withdraw and emergencyWithdraw, Access control on emergencyWithdraw and cancel, Integer overflow/underflow in unchecked blocks, Unsafe downcasts from uint256 to uint128, Linked list integrity in placeOrder, cancel, and fillOrder, CEI pattern compliance, ERC-20 standard compliance for deposit/withdraw, Precision loss in price calculations, Dead code analysis, Constant/immutable usage
compiler bugs	success	4	1C	88%	42.1s	Access control on cancel(), placeOrder(), fillOrder(), emergencyWithdraw(), Arithmetic overflow/underflow in unchecked blocks (_processWithdrawal), Integer truncation in fillOrder quoteAmount casting, Reentrancy in deposit(), withdraw(), fillOrder() — all follow CEI or use SafeERC20 with balance-before-transfer pattern, Linked list integrity in order insertion/removal (_cancelOrder, _removeFilledOrder), ERC20 transfer safety — SafeERC20 used throughout public entry points, Compiler bug applicability — pragma ^0.8.20 is outside all known affected ranges, Dust order / MIN_ORDER_SIZE enforcement in placeOrder, MAX_PRICE_DEVIATION constant declared but not enforced in placeOrder
assembly safety	success	5		88%	50.0s	Full codepoint-by-codepoint scan for non-ASCII characters, RTLO (U+202E), zero-width characters (U+200B, U+200C, U+200D), and Cyrillic homoglyphs in all identifiers, function names, and string literals — none found, Inline assembly blocks — none present in this contract, Access control on all external/public state-mutating functions (deposit, withdraw, placeOrder, cancel, fillOrder, emergencyWithdraw), Integer arithmetic including unchecked blocks, uint128/uint256 cast truncation risks, Reentrancy patterns and checks-effects-interactions ordering, Linked list manipulation correctness in placeOrder, cancel, fillOrder, Constant enforcement (MIN_ORDER_SIZE, MAX_PRICE_DEVIATION), MockTIP20 contract for minter access control and mint function safety, SafeERC20 usage correctness, Event emission completeness, Flash loan / price oracle manipulation attack surfaces
l2 specific	success	7	1M1L	85%	1.1m	Deposit and withdrawal logic including CEI pattern compliance, emergencyWithdraw unchecked arithmetic and access control, Order placement, cancellation, and fill logic, Authorization checks in cancel() and placeOrder(), Integer overflow/underflow in fillOrder quoteAmount cast, Linked list integrity in _cancelOrder and _removeFilledOrder, MAX_PRICE_DEVIATION enforcement (or lack thereof), Fee-on-transfer token compatibility, Reentrancy vectors across deposit/withdraw/fillOrder, uint128 overflow in balance accumulation, getOrders view function for unbounded loop / DoS, MockTIP20 minter access control, Chain-agnostic analysis (no L2-specific markers found)

Scope and Methodology

Target0xf6118a2190311d3b2ef2d77ed3cd8e63a0617f53

ChainEthereum

Complexitymoderate

Standards DetectedERC20

Analysis ModelClaude Sonnet 4.6

Specialist Agents9

Agent Types

reentrancyaccess controleconomiclogic validationcode qualitycompiler bugsassembly safetyl2 specific

Scope TemplateDeFi - AMM/DEX (auto-selected)

MethodologyAutomated multi-agent analysis. Each specialist agent independently reviews the contract source code for vulnerabilities in its domain. Findings are deduplicated, scored, and synthesized into this report.

Findings are gated by demonstrated exploit feasibility against the analyzed contract. Observations that describe accepted blockchain behavior, consensus-layer issues, or infeasible preconditions are excluded from scored findings. See scope policy.

Severity Classification

CriticalDirect loss of funds or complete protocol compromise. Exploitable with high likelihood. Requires immediate remediation.

HighSignificant risk to funds or protocol integrity. Conditionally exploitable or requires specific circumstances. Should be fixed before deployment.

MediumLimited or conditional impact. May require unlikely conditions to exploit. Should be addressed but not blocking.

LowMinor impact. Best practice deviations, minor inefficiencies. Fix when convenient.

InformationalNo direct security impact. Code quality observations, gas optimizations, style recommendations.

Limitations

This automated audit has inherent limitations. The following areas are not covered.

-Business logic correctness beyond pattern matching: this audit detects deviations from documented patterns (CEI, overflow protection) but cannot verify whether the orderbook's economic incentives, order matching logic, or fee structure behave as the protocol designers intended across all market conditions.

-Off-chain component security: the security of any keeper bots, indexers, or front-end interfaces that interact with this contract's getOrders view function or order events is outside the scope of this analysis; a compromised off-chain component could manipulate order display or submission independently of the on-chain logic.

-Economic modeling and tokenomics: the viability of the stablecoin parity assumption, liquidity depth requirements, and the economic sustainability of the orderbook model under adversarial market conditions cannot be assessed through static code analysis alone.

-Cross-protocol composability risks: integrations with external protocols (flash loan providers, token contracts with non-standard behavior beyond fee-on-transfer) that are not part of the analyzed contract may introduce exploit paths that were not fully enumerable from this contract's code alone.

-Governance and social dynamics: if contract ownership or admin key management is relevant to future upgrades, the security of key storage, multisig configurations, and social governance processes (signer collusion, key compromise) is not assessed here.

-Token whitelist enforcement: the contract does not enforce a token whitelist, meaning any ERC-20 token including rebasing tokens, tokens with blacklists, or tokens with multiple entry points can be deposited; the full exploit surface for arbitrary token interactions cannot be exhaustively enumerated in a single audit pass.