Loading...
LoadingLoading...
LoadingLoading audit report...
WalletGuard.ai, powered by Gestalt Labs
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.
The analyzed contract is a THORChain/Avalanche cross-chain router and aggregator system, responsible for bridging ETH, AVAX, and ERC-20 tokens between chains via vault-based allowance accounting. The analysis identified 0 critical, 4 high, 7 medium, 5 low, and 5 informational findings across 21 total submissions before deduplication and scope gating. The single most dangerous pattern is the aggregator swapIn function consuming the contract's entire ETH/AVAX balance rather than only swap proceeds, enabling any caller to drain accumulated funds in a single transaction. Overall, the contract system carries meaningful risk and should not be considered production-safe until the balance-sweep vulnerability in aggregators and the tx.origin authorization flaw in ETH_RUNE are remediated.
When a user performs a token-to-ETH swap through the aggregator, the contract forwards its entire ETH balance to the THORChain router, not just the ETH received from that specific swap. If the aggregator contract holds any leftover ETH from prior activity, a user can drain it by triggering a swap with a small amount. This effectively lets anyone steal accumulated ETH from the aggregator in a single transaction.
The ETH_RUNE token's transferTo function identifies the token owner using tx.origin, which is always the original human wallet that started the transaction chain, rather than the immediate caller. This means any malicious contract that a user interacts with can call transferTo and transfer that user's RUNE tokens to an attacker without the user's consent. No approval is needed; simply interacting with a phishing site or malicious contract is enough to lose all RUNE tokens.
The swapIn function in both aggregator contracts accepts a router address as a user-supplied parameter and sends all collected ETH to it. Because there is no validation of this address, an attacker can supply a malicious contract address, causing the aggregator to forward all its ETH to an attacker-controlled contract. When combined with the balance-sweep bug, this allows draining the aggregator's full ETH balance in one call.
2 centralization points identified
Loss of owner key results in permanent inability to call rescueFunds, locking any ETH held in the aggregator. This is a property of the ownership model the buyer should know about.
rescueFunds()The permissionless vault operation is an acknowledged THORChain design choice; the ETH routing path enables event spoofing from arbitrary callers but does not drain held user funds without vault key compromise.
transferOut()An attacker exploits two cooperating flaws in swapIn. First, the balance sweep bug causes safeAmount to equal address(this).balance rather than just the current swap's output, inflating the ETH forwarded. Second, the tcRouter parameter has no whitelist, so the attacker supplies a malicious contract implementing a depositWithExpiry interface. The aggregator calls depositWithExpiry on the malicious contract with the full contract balance, effectively transferring all accumulated ETH to the attacker. Neither flaw alone is as severe: the balance sweep without a malicious router only inflates a legitimate deposit, while the unrestricted router without the balance sweep only redirects the current swap's proceeds. Together they enable complete ETH drainage in a single transaction.
The transferOutAndCallV5 function in THORChain_Router transfers ERC-20 tokens to an aggregator target and then calls swapOutV5. If the aggregator fails or reverts, the router does not recover the tokens and has no fallback transfer to the recipient. An attacker controlling or influencing the aggregator can deliberately cause swapOutV5 to fail, leaving ERC-20 tokens stranded in the aggregator. If the aggregator also lacks a rescue mechanism, user funds are permanently locked. The unrestricted target address in transferOutAndCall means a vault operator could direct this flow at a malicious or non-functional aggregator.
| Agent | Status | Findings | Severity | Confidence | Duration | Coverage |
|---|---|---|---|---|---|---|
| reentrancy | success | 7 | 2M1L | 81% | 1.3m | Cross-function reentrancy in AvaxRouter and THORChain_Router (deposit, transferOut, transferAllowance, returnVaultAssets), ERC-20 callback reentrancy via malicious transferFrom (EvilToken pattern), CEI pattern compliance in all router deposit and transfer functions, nonReentrant modifier placement and coverage on all public/external state-modifying functions, Balance accounting in swapIn (pre-existing ETH/AVAX balance vulnerability), tx.origin usage in ETH_RUNE.transferTo(), safeApprove usage in AvaxAggregator, transferOutAndCallV5 ERC-20 stranding risk, EvilCallback reentrancy attempt via receive() hook, batchTransferOutV5 and batchTransferOutAndCallV5 nonReentrant guard coverage, depositWithExpiry expiration check ordering, _transferOutAndCallV5 failure recovery paths |
| access control | success | 10 | 1H2M2L | 82% | 1.7m | tx.origin authorization patterns in ETH_RUNE.transferTo(), Access control on bridge router functions (transferOut, transferOutAndCall, deposit), Reentrancy guards across all router and aggregator contracts, ETH balance sweep vulnerability in swapIn functions, Signature/authentication patterns (none present - not applicable), Initialization safety (no upgradeable proxies - not applicable), Ownership patterns in THORChain_Aggregator, safeApprove usage and potential DoS via non-zero allowance, Deposit expiry bypass via direct deposit() call, Arbitrary target calls in transferOutAndCall functions, EvilCallback and EvilToken test contracts for reentrancy analysis, Cross-chain replay attacks (THORChain uses memo-based validation off-chain), selfdestruct usage (none present), delegatecall usage (none present) |
| economic | success | 10 | 2M | 81% | 1.6m | Flash loan / balance manipulation in swapIn (address(this).balance usage), Reentrancy across all router and aggregator functions, Access control on vault management functions (transferOut, transferAllowance, returnVaultAssets), Oracle manipulation - no price feeds present, N/A, ERC-20 approval patterns (safeApprove with wrong amounts, dangling approvals), tx.origin usage in ETH_RUNE transferTo, Batch function ETH distribution correctness (batchTransferOutAndCallV5), Fee-on-transfer token handling in safeTransferFrom, Governance attack surface - no governance present, N/A, MEV/sandwich exposure on swapOut functions, Cross-contract composability with external DEX routers, THORChain_Router deposit/withdrawExpiry nonReentrant coverage, EvilCallback/EvilToken test contract analysis, USDT and ETH_RUNE ERC-20 standard compliance |
| logic validation | success | 9 | 1H1M | 88% | 1.3m | AvaxAggregator swapIn and swapOut ETH/AVAX balance handling, THORChain_Aggregator swapIn balance handling and approval logic, THORChain_Router deposit, transferOut, transferAllowance, returnVaultAssets access control, AvaxRouter deposit, transferOut, transferAllowance access control, Reentrancy guard implementation across all router contracts, Integer arithmetic in Solidity 0.8.x contracts (overflow protection built-in), ETH_RUNE tx.origin usage in transferTo, EvilCallback and EvilToken reentrancy test contracts, Batch function DoS via unbounded loops, Fee-on-transfer token handling in aggregators, Vault allowance underflow protection (Solidity 0.8+ reverts), transferOutAndCall and transferOutAndCallV5 fallback behavior, safeTransferFrom balance-delta pattern correctness |
| code quality | success | 11 | 79% | 1.6m | Reentrancy guards across all router and aggregator contracts, Access control on vault/allowance management functions, ETH/token balance accounting in swapIn/swapOut flows, tx.origin usage in ETH_RUNE transferTo, Fee-on-transfer token handling in safeTransferFrom and approve flows, Arbitrary external call targets (tcRouter, tcVault) in aggregators, ERC-20 compliance of Token, ETH_RUNE, EvilToken, StealToken, TetherToken, Integer overflow/underflow in Solidity 0.7.6 contracts (SafeMath usage), Vault allowance accounting correctness, Cross-function reentrancy via EvilCallback and EvilToken, depositWithExpiry expiration check, returnVaultAssets ETH forwarding, transferOutAndCall fallback behavior, batchTransferOutV5 unbounded loop DoS potential, Storage variable optimization opportunities | |
| compiler bugs | success | 3 | 1H1M | 88% | 40.8s | AvaxAggregator.swapIn and swapOut - ETH balance handling and parameter validation, AvaxRouter deposit, transferOut, transferOutAndCall, returnVaultAssets - reentrancy, allowance accounting, THORChain_Router (both chain/ and ethereum/ versions) - all transfer functions, batch operations, reentrancy guards, THORChain_Aggregator and THORChain_Failing_Aggregator - swapIn, swapOut, swapOutV5, rescueFunds, ETH_RUNE token - transferTo tx.origin pattern, mint access control, burn functions, EvilToken and EvilCallback - understanding of existing attack vectors already modeled, USDT (TetherToken) - fee-on-transfer behavior impact on router safeTransferFrom, Compiler bug checks - pragmas are 0.8.9, 0.8.22, 0.7.6, 0.4.17; no affected ABIEncoderV2 storage array patterns found, Reentrancy across all router functions - nonReentrant guards in place and correctly structured, Access control on rescueFunds and admin functions, Integer overflow/underflow - 0.8.x contracts use built-in checks; 0.7.6 and 0.4.x use SafeMath |
| assembly safety | success | 9 | 1M3L | 81% | 1.5m | Full codepoint scan for non-ASCII characters, RTLO (U+202E), zero-width joiners, Cyrillic homoglyphs — none found, Inline assembly blocks — none present in any contract, AvaxAggregator and THORChain_Aggregator swapIn/swapOut logic, AvaxRouter and THORChain_Router deposit, transferOut, transferAllowance, returnVaultAssets, transferOutAndCall, transferOutAndCallV5, batchTransferOutV5, batchTransferOutAndCallV5, Reentrancy guard implementation and cross-function reentrancy vectors, ETH/AVAX balance accounting in aggregator swap flows, ETH_RUNE tx.origin usage in transferTo, ERC20 allowance patterns (safeApprove without reset), Access control on vault management functions, EvilToken and EvilCallback reentrancy test contracts, msg.value reuse in batch functions, THORChain_Failing_Aggregator swapOutV5 always-revert design, USDT/TetherToken fee-on-transfer compatibility with router safeTransferFrom, SushiRouterSmol and WETH helper contracts, StealERC20Token transfer-based token theft pattern, Integer overflow/underflow (all critical contracts use 0.8.x with built-in checks except ETH_RUNE at 0.7.6 with SafeMath) |
| l2 specific | success | 12 | 86% | 1.5m | Reentrancy guards across all router and aggregator contracts, Cross-function reentrancy (deposit, transferOut, transferAllowance sharing _status), ETH/AVAX balance sweeping in swapIn functions, tx.origin usage in ETH_RUNE.transferTo, ERC20 approval patterns (safeApprove without zero-reset), Vault allowance accounting in _adjustAllowances and _vaultAllowance, transferOutAndCallV5 ERC20 failure path - missing fallback for stuck tokens, transferOutAndCall ETH failure path - fallback to recipient then vault, batchTransferOut* iteration with external calls, safeTransferFrom balance-delta pattern for fee-on-transfer tokens, EvilERC20Token and EvilCallback test contracts for reentrancy attack vectors, StealToken transfer side-effect pattern, depositWithExpiry expiration check, returnVaultAssets ETH forwarding, THORChain_Aggregator.rescueFunds owner access control, No L2-specific predeploys or cross-domain messengers found (chain-agnostic Ethereum/Avalanche contracts) |
This automated audit has inherent limitations. The following areas are not covered.
This report is an automated point-in-time assessment and does not guarantee protection against all possible attacks. It does not cover off-chain components, economic modeling, or business logic correctness unless explicitly noted. Changes to the contract after the audit commit are not reviewed. This is not financial or legal advice. WalletGuard, powered by Gestalt Labs, provides this analysis as-is with no warranty of completeness.
[](https://walletguard.ai/audit/4f6e1d28-7e42-4f71-9b65-43415ca0a58d)
<a href="https://walletguard.ai/audit/4f6e1d28-7e42-4f71-9b65-43415ca0a58d"> <img src="https://walletguard.ai/api/badge/4f6e1d28-7e42-4f71-9b65-43415ca0a58d" alt="WalletGuard Audit Badge" /> </a>
Secured by WalletGuard