Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Towns Safe?

TOWNSBase
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance3/10Upgrades1/10Checks passed1 of 5Findings1 Medium · 1 Info2
SummaryAI Copilot

The Towns contract serves as an ERC-20 token with voting capabilities, cross-chain mint/burn functionality, and a unique token transfer lock mechanism tied to delegation.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 62.2%
  • LP top3 unlocked holders = 100.0%
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (74.3% total → 52.0% effective; 37.1% in EOAs, 37.2% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 62.2% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 1 Medium finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
37.2%Contracts37.1%Wallets25.7%Everyone else
37.2%Contracts37.1%Wallets25.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
74.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking37.2%
  • Walletsanonymous holders, free to sell37.1%
  • Everyone elsethe rest of the supply25.7%
Effective concentrationwhat the score reads52.0%
How holder types affect the score

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$222.8K across 2 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$222.4KShare of depth99.8%
Top-1 Unlocked Holder62.2%
Top-3 Unlocked100.0%
Unlocked LP held by
0xfa2b…52bb0x375f…9491

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

1 Medium1 Info
Medium

Fixed and Significant Token Transfer Lock on Undelegation

The Towns contract implements a token transfer lock mechanism tied to voting delegation. When a user undelegates their voting power (by delegating to address(0)), their tokens become subject to a 30-day transfer lock. This defaultCooldown is set during initialization via __LockBase_init(30 days) and cannot be modified later, making the 30-day lock period a permanent and unchangeable feature. While this is an intended design, its fixed and substantial duration could lead to unexpected liquidity restrictions for users who are unaware of this cooldown period, potentially impacting user experience and token utility.M-01

Issue

The Towns contract implements a token transfer lock mechanism tied to voting delegation. When a user undelegates their voting power (by delegating to address(0)), their tokens become subject to a 30-day transfer lock. This defaultCooldown is set during initialization via __LockBase_init(30 days) and cannot be modified later, making the 30-day lock period a permanent and unchangeable feature. While this is an intended design, its fixed and substantial duration could lead to unexpected liquidity restrictions for users who are unaware of this cooldown period, potentially impacting user experience and token utility.

Fix

Ensure that the fixed 30-day token transfer lock upon undelegation is clearly communicated to all users through official documentation, user interfaces, and any relevant educational materials. Consider adding a warning or confirmation step in front-end applications when a user attempts to undelegate, explicitly stating the impending transfer lock duration. While the contract design makes this immutable, transparent communication is crucial to manage user expectations.

Status

Unresolved

Info

Unused onlyAllowed Modifier in LockBase

The _canLock() function in the Towns contract, which is an override from LockBase, always returns false. This design choice renders the onlyAllowed modifier within the LockBase contract effectively unusable. While Towns does not directly expose any external functions that utilize this modifier, its presence in the inherited LockBase contract, coupled with _canLock() always returning false, indicates a potential design inconsistency or an unimplemented feature from the ILock interface (e.g., enableLock, disableLock, setLockCooldown are not implemented in Towns with this modifier).I-01

Issue

The _canLock() function in the Towns contract, which is an override from LockBase, always returns false. This design choice renders the onlyAllowed modifier within the LockBase contract effectively unusable. While Towns does not directly expose any external functions that utilize this modifier, its presence in the inherited LockBase contract, coupled with _canLock() always returning false, indicates a potential design inconsistency or an unimplemented feature from the ILock interface (e.g., enableLock, disableLock, setLockCooldown are not implemented in Towns with this modifier).

Fix

Document the explicit design decision behind _canLock() always returning false and the implications for the onlyAllowed modifier in LockBase. If the onlyAllowed modifier and associated external functions from ILock were never intended to be used or exposed, consider removing them from LockBase or clarifying their purpose to avoid confusion for future developers or auditors. If they were intended, ensure proper implementation and exposure.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The Towns contract serves as an ERC-20 token with voting capabilities, cross-chain mint/burn functionality, and a unique token transfer lock mechanism tied to delegation. It is deployed as a UUPS upgradeable proxy on the Base network. The contract leverages well-audited Solady libraries and OpenZeppelin components, demonstrating a robust architectural foundation. The primary area of concern identified is the fixed and significant 30-day token transfer lock imposed on users who undelegate their voting power, which could lead to unexpected liquidity restrictions.

Technical6/10Medium risk

The contract exhibits a strong technical foundation (7.1 Architecture), utilizing battle-tested Solady libraries for ERC20Votes, Ownable, and UUPSUpgradeable, along with OpenZeppelin interfaces. Access control for critical functions like cross-chain minting and burning (7.3 Access Control) is appropriately restricted to designated bridge addresses, enhancing security. The use of CustomRevert for error handling (7.2 Code Security) is a gas-efficient practice. However, the fixed 30-day lock on token transfers after undelegation introduces a significant operational constraint (7.8 Operations) that users might not anticipate, impacting liquidity.

Governance3/10High risk

The Towns token incorporates standard ERC20Votes functionality, allowing for robust on-chain governance (7.5 Governance) through delegation. The economic model (7.4 Economic) includes a mechanism to lock tokens for 30 days upon undelegation, which is a design choice intended to influence voter behavior. While this mechanism is clearly implemented, its immutability and duration could impact user liquidity and participation if not well-understood. The cross-chain mint/burn functions are appropriately controlled, preventing unauthorized supply manipulation.

Upgrades1/10High risk

The contract implements the UUPS upgradeability pattern (7.7 Upgrades), which is a secure and widely adopted standard. The _authorizeUpgrade function is correctly overridden to restrict upgrade authorization to the contract owner via the onlyOwner modifier, ensuring controlled and secure upgrade pathways. This setup provides flexibility for future enhancements while maintaining strong access control over critical contract modifications.

Final RecommendationWhat to do about this score

It is recommended to ensure comprehensive user education regarding the fixed 30-day token transfer lock that activates upon undelegation.

Clear communication channels, documentation, and user interface warnings should highlight this significant cooldown period to prevent unexpected liquidity issues for token holders. Additionally, consider documenting the design choice behind the _canLock() function always returning false to clarify the intended behavior of the LockBase contract's onlyAllowed modifier for future development and auditing efforts.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkBase
Token age1y
Contract0x0000…9a38
Deployer0x9f26…77ad
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Towns security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 12, 202671High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the TOWNS contract address?

The Towns contract on Base is 0x00000000a22c618fd6b4d7e9a335c4b96b189a38. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Towns a scam?

Quantum Audit's risk score for Towns is 71/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is TOWNS liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $222.8K.

Who holds TOWNS?

As of Sep 4, 2026, the 10 largest holders own 74.3% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
XMAQUINADEUS · Base71HighICPBase71HighGAME by VirtualsGAME · Base71HighMAGICBase71HighRecallBase72HighVANRYBase72High

Would You Like a More Detailed Audit of Towns?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page