Titan Locker's ContractWolf Security Audit: Findings, Fixes, and What Changed
How ContractWolf's audit of Titan Locker V2 went, the 4 findings it turned up (1 Major, 2 Medium, 1 Informational, 0 Critical), how each was fixed, and why the fix shipped as a new contract address instead of an upgrade.
7 min readUpdated First published By Titan Locker
Titan Locker's V2 contracts (TitanLockerManagerV2 and TitanLockerV2) went through a professional third-party security audit by ContractWolf, completed July 18, 2026. The audit found 4 issues — 1 Major, 2 Medium, 1 Informational, 0 Critical — and every one was fixed and shipped as version 2.1.0, deployed fresh as TitanLockerManagerV2_1, which is now the manager that creates every new lock on Robinhood Chain. (The same audited contract also holds the locks created on Stable Chain, where Titan Locker is no longer offered; those existing locks are unaffected and remain verifiable on Stablescan.) ContractWolf's own verdict: AUDIT PASSED. This article walks through what that engagement actually covered, what each finding meant in practice, and why the fixes live at a new contract address rather than an in-place upgrade.
Why get audited at all
Titan Locker's whole pitch rests on the contracts being trustworthy without anyone having to trust Titan Locker the company: immutable, non-custodial, no admin override. A claim like that is worth nothing without someone independent checking it. An internal test suite (Titan Locker also runs Slither, Aderyn, Mythril, Foundry fuzz/invariant tests, Echidna, and Halmos - see Fees & security for the full toolchain) catches a different class of bugs than a human auditor reading the code line by line looking for the ways an attacker would think about it. A paid, external audit is that second check.
Who ContractWolf is and what they reviewed
ContractWolf is an independent smart-contract security auditor. Their engagement here was a Standard Audit - manual line-by-line review plus automated analysis - covering the full TitanLockerManagerV2/TitanLockerV2 contract pair: every locking, vesting, and fee-collection code path, not just a sample of it.
The 4 findings
Ranked by severity, from the one that mattered most to the one that mattered least. None of them were exploitable against a lock that already existed at the time of the audit - all 4 involved how a lock could be created or how fees were computed, not a way to reach into an existing lock's funds.
| Finding | Severity | The fix |
|---|---|---|
| SWC-114 — Transaction Order Dependence: a token-fee change landing between a user submitting a lock-creation transaction and it being mined could, in the worst case, confiscate more of the deposit than the user agreed to. | Major | The token fee is now capped at 5% (down from an unbounded 100%), and callers can additionally set their own max-fee guard that reverts the transaction outright if the actual fee exceeds what they expected. |
| Basis-point rounding let a sufficiently small ("dust") lock round its fee down to zero, letting it skip the fee entirely. | Medium | Fee calculation now rounds up (ceiling division) instead of down, so no lock size can land on a zero fee by rounding. |
| collectFees() misreported the collected amount for Uniswap V4 position locks specifically - the reported number didn't reliably match what was actually transferred. | Medium | Collected amounts are now captured via a real balance delta (measuring the lock owner's balance - the fees' recipient - before and after the collect call) instead of trusting a return value. |
| Missing validation allowed a lock to be created with a zero token amount - functionally pointless, and free to spam. | Informational | Zero-amount locks now revert at creation instead of silently succeeding. |
Every fix has dedicated test coverage across the Hardhat, Foundry fuzz/invariant, and Halmos symbolic-proof suites - not just a manual check that the specific reported case no longer reproduces.
Why the fix is a new contract, not an upgrade
Titan Locker's contracts are deliberately non-upgradeable - no proxy, no admin key that can swap out the logic behind an existing address. That's the same property that makes "no admin can move your tokens early" true in the first place, but it means a fix genuinely can't be applied in place. Instead, the fixed code was deployed fresh as TitanLockerManagerV2_1 (0x102a70bDA2C833b3483A2eE55C14c7ea0fb7A01B), and the app now creates every new lock there. The original TitanLockerManagerV2 (0x26b0654a0756dcd036d4e7215324f3d2be34d79e) is superseded: it's still deployed with its code unchanged, but the app no longer creates locks on it and treats it as read-only, so locks already on it stay viewable and withdrawable. Those existing locks are unaffected either way - none of the 4 findings above involve custody of an existing lock, only the mechanics of creating a new one or collecting V4 fees going forward.
| Contract | Address | Status |
|---|---|---|
| TitanLockerManagerV2 (original) | 0x26b0654a0756dcd036d4e7215324f3d2be34d79e | Superseded, read-only in the app, pre-audit-fix logic; existing locks stay withdrawable |
| TitanLockerManagerV2_1 (audit-fixed) | 0x102a70bDA2C833b3483A2eE55C14c7ea0fb7A01B | Current on Robinhood Chain, verified, carries all 4 fixes; the same address on Stable Chain is retired for new locks, and its existing locks are unaffected |
The legacy V1 manager (which predates V2) and the Titan.fun launch vaults that hold launched tokens' liquidity are separate deployments; every address, including the retired Stable Chain deployment, is in the contract registry.
Verifying this independently
None of the above should be taken on faith from this page. The report itself, and ContractWolf's own listing of the engagement, are both hosted independently of Titan Locker, and the contract source is public under the GPL-3.0 license:
Two more independent services read Titan Locker's contracts on their own. DefiLlama lists Titan Locker (category Token Locker, Robinhood Chain) and tracks its TVL and lock-fee revenue with its own adapter - its TVL counts only the ETH, WETH, USDG, and USDe side of locks, so it reads lower than the priced active value on Titan's own statistics page; both are correct, they measure different things. Quick Intel's token scanner recognises liquidity locked in Titan Locker on Robinhood Chain and reports it as locked. Neither is a security review - they confirm what the contracts hold and that third-party tools read them correctly, not that the code is bug-free.
What an audit doesn't cover
- An audit is a point-in-time review of the code as it existed on the audited commit - it says nothing about code changed afterward that wasn't re-audited.
- It covers the contracts' own logic, not the tokens people choose to lock - a malicious or fee-on-transfer token can still behave unexpectedly inside a perfectly correct lock contract.
- "0 Critical" findings reduces risk; it isn't a guarantee of zero bugs. Treat it the way it's meant - real, independent evidence, not a warranty.
Related resources
Frequently asked questions
Is Titan Locker audited?
Yes. ContractWolf ran a professional Standard Audit against TitanLockerManagerV2/TitanLockerV2, completed July 18, 2026. It found 4 issues (1 Major, 2 Medium, 1 Informational, 0 Critical), and every one was fixed and shipped as version 2.1.0.
What was the most serious finding?
A Major transaction-order-dependence issue: a token-fee change landing between a user's transaction being submitted and mined could take more of the deposit than intended. It's fixed by capping the token fee at 5% and letting callers set their own max-fee guard.
Do the findings affect locks that already existed before the audit?
No. All 4 findings involved how a lock could be created or how V4 fees were reported - none of them involve custody of a lock that already existed. Existing locks on the original TitanLockerManagerV2 are unaffected.
Why is the fix a new contract address instead of an upgrade?
Titan Locker's contracts have no upgrade proxy or admin key by design - the same property that guarantees no admin can move funds early also means a fix can't be applied in place. The fixed code was deployed fresh as TitanLockerManagerV2_1.
How can I verify the audit myself instead of trusting this page?
ContractWolf hosts both Titan Locker's project listing and the original report PDF independently, on contractwolf.io and ContractWolf's own GitHub - both linked above, neither controlled by Titan Locker. The contract source itself is public on GitHub under GPL-3.0.
Is Titan Locker tracked by any independent services besides the auditor?
Yes. DefiLlama lists Titan Locker as a Token Locker on Robinhood Chain and tracks its TVL and lock-fee revenue with its own adapter (counting only the ETH, WETH, USDG, and USDe side of locks, so its TVL is lower than Titan's own priced active value). Quick Intel's token scanner recognises liquidity locked in Titan Locker on Robinhood Chain and reports it as locked. Neither is a security audit.
Something unclear or out of date? Tell us in Telegram support