
Loading...
Loading
Loading...
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 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.
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.
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.
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.
1 centralization point identified
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()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.
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.
| 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 |
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/03335ea6-d3a2-484e-a668-cfbc53e887be)
<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>