Is Towns Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Info

Medium

Fixed and Significant Token Transfer Lock on Undelegation

M-01The `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.

IssueThe `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.

FixEnsure 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.

StatusUnresolved

Info

Unused `onlyAllowed` Modifier in `LockBase`

I-01The `_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).

IssueThe `_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).

FixDocument 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.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh3/10

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.

UpgradesHigh1/10

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.

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

74.3% in top 10

37.1% in wallets37.2% in contracts

Effective Concentration52.0%

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.

Liquidity Depth

$222.8K across 2 pairs

AerodromeWETHanalysed$222.4K AerodromeUSDC$444

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder62.2%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x9f26…77ad

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.

What Raised This Score

8 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

Is Towns Safe?