Security Audit Report

WalletGuard.ai, powered by Gestalt Labs

April 17, 2026

ID: 03335ea6

0xd3ed...92baEVMBench: 2025-02-thorwalletv1View audit historyEthereumLive TargetModerate Risk

Verified on BaseVerify externally Prompt 0xd29afd...

Apr 17, 2026, 06:24

Standard AuditModel: Claude Sonnet 4.6

What you got

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

Risk Level: Moderate Risk

Efficiency

0C2H6M6L

14 security | 1 code quality | 1 gas

2 High: MergeTgt.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 appears to be a token merge/migration contract (MergeTgt) that allows users to exchange TGT tokens for TITN tokens over a time-decaying schedule, paired with the TITN OFT token contract supporting LayerZero cross-chain bridging. The analysis identified 0 critical, 2 high, 5 medium, 5 low, and 2 informational findings after deduplication and scope calibration. The most dangerous pattern is the owner's unrestricted ability to withdraw TITN tokens allocated for user claims, which can result in total loss of user funds after they have irrevocably deposited TGT. The contract carries significant centralization risk and several logic boundary errors that could trap user funds; it should not be considered safe for permissionless use without additional trust assumptions about the owner.

Critical Highlights

highOwner withdraw() Can Drain TITN Allocated for User Claims

After users permanently lock their TGT tokens into the contract, the contract owner can call a single function to remove all TITN tokens from the contract, leaving users with nothing to claim. There is no protection that reserves the tokens users have already earned, so the owner can effectively take all user funds at any time.

highDivision by Zero in withdrawRemainingTitn When initialTotalClaimable Is Zero

If no users have accrued claimable TITN before the 360-day deadline is reached, a key contract function permanently breaks. Any attempt to recover remaining TITN will crash the contract with a divide-by-zero error, and there is no way to fix this without deploying a new contract.

mediumTitn transfer restrictions on Arbitrum block all non-owner token transfers regardless of bridged status

On the Arbitrum network, when the transfer lock is active (which is the default state), no user can move their TITN tokens to anyone except the contract owner or a specific whitelisted address. This applies to every user on Arbitrum regardless of how they received their tokens, and the owner can keep this lock active indefinitely with no time limit.

14 Security Findings | 1 Code Quality | 1 Gas Optimization

high(2)

medium(6)

low(6)

Code Quality Observations(1)

Gas Optimizations(1)

Decentralization

1 centralization point identified

Owner withdraw() Can Drain TITN Allocated for User Claims

The exploit requires the owner to act maliciously or be compromised; the vulnerability is the absence of an accounting guard in an intentional owner-privileged function, which is a centralization risk rather than a permissionless attack surface.

withdraw()

Attack Chain Analysis

Zero-Output Swap Locks User TGT Permanentlyhigh

Finding 11 (quoteTitn rounds to zero for small deposits) and Finding 2 (onTokenTransfer does not check for zero titnOut) combine into a single exploit path: a user calls transferAndCall near the 360-day boundary with a small TGT amount, quoteTitn returns 0 due to integer rounding, and onTokenTransfer credits the user with 0 claimable TITN while the TGT is transferred into and permanently locked in the contract. The user loses their TGT with no recourse and no revert to protect them.

quoteTitn returns 0 after 360 days but onTokenTransfer only checks > 360 days, allowing zero TITN swapsquoteTitn Returns Non-Zero for Expired Period in Edge Cases Due to Integer Division

Owner Fund Drainage via Unrestricted Withdrawalhigh

Finding 8 (withdraw drains TITN) and Finding 3 (withdraw has no accounting guard) are two agent perspectives on the same underlying issue: the owner can call withdraw() on the TITN token at any time after users have deposited TGT and accrued claimable TITN. The absence of any balance sufficiency check means claimTitn() and withdrawRemainingTitn() will revert for all users after the drain, resulting in total loss of all user-deposited value.

Owner withdraw() Can Drain TITN Allocated for User Claimswithdraw Function Has No Access Control Beyond onlyOwner — Can Drain Any Token

Agent Coverage

Agent	Status	Findings	Severity	Confidence	Duration	Coverage
reentrancy	success	6	1M	81%	53.6s	Cross-function reentrancy in onTokenTransfer, claimTitn, withdrawRemainingTitn, CEI pattern compliance across all state-modifying functions, ReentrancyGuard usage and placement, ERC-677 callback (onTokenTransfer) reentrancy via Tgt.transferAndCall, Arithmetic correctness in quoteTitn and withdrawRemainingTitn, Boundary condition consistency between onTokenTransfer and claimTitn, Owner privilege abuse paths in withdraw(), Transfer restriction logic in Titn._validateTransfer, OFT _credit override and bridged token holder tracking, Integer overflow/underflow in proportional share calculation, Access control on deposit, withdraw, setLaunchTime, setLockedStatus
access control	success	5	2M1L	78%	1.0m	Access control on all public/external functions (onlyOwner, msg.sender checks), ERC-677 callback authentication in onTokenTransfer, Reentrancy protection via nonReentrant modifier, Arithmetic in quoteTitn and withdrawRemainingTitn for overflow/underflow, Division by zero in withdrawRemainingTitn when initialTotalClaimable == 0, Transfer restriction logic in Titn._validateTransfer for chain ID and bridged holder checks, Signature/auth patterns (none present), Initializer/upgrade safety (no proxy, immutable constructor), Boundary conditions between claimTitn and withdrawRemainingTitn timing, Owner ability to drain user-claimable funds via withdraw, OFT _credit function and isBridgedTokenHolder tracking, TGT transferAndCall callback chain integrity
economic	success	7	1H1L	81%	1.3m	Flash loan attack surface on MergeTgt (no price feed or balance-based pricing, not applicable), Oracle usage (none present), Reentrancy guards on claimTitn, withdrawRemainingTitn, onTokenTransfer, Access control on deposit/withdraw/setLaunchTime/setLockedStatus, ERC677 onTokenTransfer callback authenticity check, Timing boundary conditions in onTokenTransfer vs claimTitn vs withdrawRemainingTitn, Division by zero in withdrawRemainingTitn when initialTotalClaimable==0, Snapshot manipulation via balance donation, Over-payment arithmetic in withdrawRemainingTitn, Titn transfer restriction logic on Arbitrum (hardcoded chain ID), Bridged token holder tracking in _credit, LayerZero OFT integration (credit/debit overrides), MEV/sandwich exposure (no swaps present), Governance attack surface (none present), Fee-on-transfer token handling (TGT and TITN are standard ERC20s per source), First-depositor inflation (no LP shares), Supply caps and minting functions in Titn
logic validation	success	7	1L	77%	1.3m	Input validation on all public/external functions in MergeTgt.sol, Arithmetic safety in quoteTitn, withdrawRemainingTitn, claimTitn, State machine integrity: lockedStatus, launchTime, merge lifecycle, Timestamp dependence in time-based calculations, Reentrancy guards on state-mutating functions, ERC677 callback security in onTokenTransfer, Transfer restriction logic in Titn._validateTransfer, OFT _credit override and bridged token holder tracking, Owner privilege abuse paths, Fee-on-transfer token accounting (TITN is a standard ERC20, not fee-on-transfer), Division by zero edge cases in withdrawRemainingTitn, Cross-function interaction between claimTitn and withdrawRemainingTitn, Titn.sol transfer lock on Arbitrum chain ID hardcode, Consistency of time boundary checks across functions
code quality	success	8	1L	81%	1.4m	ERC-20 conformance (Titn and Tgt tokens), OFT LayerZero integration and _credit override, Transfer restriction logic in _validateTransfer, MergeTgt token exchange logic (onTokenTransfer, quoteTitn), Claim and withdrawal flows (claimTitn, withdrawRemainingTitn), Access control on owner functions, Arithmetic precision and overflow/underflow, Reentrancy guards, Time-based logic and boundary conditions, Division by zero risks, Over-distribution in withdrawRemainingTitn, ERC-677 callback pattern in Tgt.transferAndCall
compiler bugs	success	4		85%	53.4s	Reentrancy protection in onTokenTransfer and claimTitn, ERC677 callback mechanism and msg.sender validation, 360-day boundary consistency between onTokenTransfer, claimTitn, and withdrawRemainingTitn, withdrawRemainingTitn arithmetic correctness and balance sufficiency, Titn transfer restriction logic on Arbitrum vs non-Arbitrum chains, Bridged token holder flag management in _credit, Owner-only deposit/withdraw functions, quoteTitn calculation for correctness, Integer overflow/underflow in Solidity 0.8+, Access control on setLockedStatus, setLaunchTime, setTransferAllowedContract, Compiler version analysis for known solc bugs (pragma ^0.8.9, ^0.8.20, ^0.8.22 - all outside vulnerable ranges)
assembly safety	success	6	1M1L	81%	1.1m	Full source code codepoint-by-codepoint scan for non-ASCII characters, RTLO (U+202E), zero-width characters, and homoglyphs — none found, Assembly blocks in Tgt.sol (extcodesize usage), MergeTgt.sol: onTokenTransfer ERC677 callback, access control, reentrancy guard usage, MergeTgt.sol: claimTitn and withdrawRemainingTitn logic, boundary conditions, arithmetic correctness, MergeTgt.sol: withdrawRemainingTitn proportional share calculation and snapshot initialization, MergeTgt.sol: deposit exact-amount enforcement, Titn.sol: _validateTransfer transfer restriction logic, Arbitrum chainid hardcoding, Titn.sol: _credit function, isBridgedTokenHolder tracking, Titn.sol: OFT LayerZero integration patterns, Tgt.sol: transferAndCall ERC677 implementation, constructor-context extcodesize bypass, Integer overflow/underflow in Solidity ^0.8.x (protected by default), Reentrancy: nonReentrant guards present on state-mutating external functions, Access control: onlyOwner on admin functions verified
l2 specific	success	8	1H2M1L	79%	1.3m	MergeTgt: token swap logic via onTokenTransfer ERC677 callback, MergeTgt: claimTitn time boundary and state update logic, MergeTgt: withdrawRemainingTitn proportional distribution math and underflow risks, MergeTgt: quoteTitn linear decay formula and rounding, MergeTgt: deposit access control and one-time enforcement, MergeTgt: reentrancy protection via nonReentrant, Titn: transfer restriction logic via _validateTransfer, Titn: hardcoded chain ID in transfer validation, Titn: isBridgedTokenHolder permanent flag setting in _credit, Titn: OFT cross-chain bridging integration, Tgt: transferAndCall ERC677 implementation, Tgt: extcodesize check for isContract (relevant on L2 but contract is on mainnet chain ID 1), Cross-contract interaction: MergeTgt trust of TGT token callback, Integer overflow/underflow in all arithmetic operations, Access control: owner-only functions in MergeTgt and Titn

Scope and Methodology

Target0xd3ed5b8d40e668160629e74674795f648f3492ba

ChainEthereum

Complexitycomplex

Standards DetectedERC20, OFT

Analysis ModelClaude Sonnet 4.6

Specialist Agents9

Agent Types

reentrancyaccess controleconomiclogic validationcode qualitycompiler bugsassembly safetyl2 specific

Scope TemplateGeneral Smart Contract (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: the audit verifies whether the contract matches identifiable patterns and internal consistency, but cannot verify whether the token exchange ratio, decay schedule, or TITN_ARB constant reflect the protocol's intended economic design or external agreements with users.
-Off-chain component security: the security of the LayerZero endpoint infrastructure, relayer key management, oracle operator behavior for cross-chain messaging, and any keeper bots that may trigger setLaunchTime or setLockedStatus are outside the scope of this analysis.
-Economic modeling: the viability of the TGT-to-TITN exchange rate, whether the 173,700,000 TITN allocation is economically sound relative to TGT supply, and whether the linear decay formula produces fair outcomes under real market conditions have not been evaluated.
-Cross-protocol composability: interactions between this contract and other protocols that may hold or integrate TITN or TGT tokens, including secondary markets, liquidity pools, and lending protocols that could be affected by the Arbitrum transfer lock, are not analyzed.
-Governance and social dynamics: the audit cannot assess whether the owner key is a multisig, timelocked, or controlled by a single party; the concentration of owner privilege documented here represents a significant trust assumption whose real-world risk depends entirely on operational key management.
-Prompt injection notice: no instructions embedded in source code or finding descriptions were detected that attempted to direct scope classifications; analysis proceeded under standard rules.

Disclaimer

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.

Embed Badge

Markdown

[![WalletGuard Audit](https://walletguard.ai/api/badge/03335ea6-d3a2-484e-a668-cfbc53e887be)](https://walletguard.ai/audit/03335ea6-d3a2-484e-a668-cfbc53e887be)

HTML

<a href="https://walletguard.ai/audit/03335ea6-d3a2-484e-a668-cfbc53e887be">
  <img src="https://walletguard.ai/api/badge/03335ea6-d3a2-484e-a668-cfbc53e887be" alt="WalletGuard Audit Badge" />
</a>

Secured by WalletGuard

How We Audit View all reports for this contractUID: 0xa7c4cf9b...6a480aThis report was produced by generic vulnerability pattern matching.

Modelsonnet

Duration3.0m

CostN/A

Tokens- in / - out

Source verified via Etherscan