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.
Published · Last reviewed · 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. 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 current pass counts) 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 contract's balance 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). The original TitanLockerManagerV2 (0x26b0654a0756dcd036d4e7215324f3d2be34d79e) keeps running completely unchanged, and every lock already on it is 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 | Live, unchanged, pre-audit-fix logic |
| TitanLockerManagerV2_1 (audit-fixed) | 0x102a70bDA2C833b3483A2eE55C14c7ea0fb7A01B | Live, verified, carries all 4 fixes |
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:
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.