Is the sleeping giant (TSG) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med3 Low1 Info

High

Centralized Control by Owner

H-01The contract utilizes the Ownable pattern, granting the owner significant control over critical functions. The owner can `lockPool`/`unlockPool`, `burn` tokens, `updateMintRate` (within a cap), trigger `mintInflation` (minting to themselves), and `updateTokenURI`. While the owner is identified as an OZ_ProxyAdmin with a 3/6 multisig, the concentration of these powers still represents a high risk if the multisig itself is compromised or mismanaged. The ability to control inflation and freeze pool transfers are particularly sensitive.

IssueThe contract utilizes the Ownable pattern, granting the owner significant control over critical functions. The owner can `lockPool`/`unlockPool`, `burn` tokens, `updateMintRate` (within a cap), trigger `mintInflation` (minting to themselves), and `updateTokenURI`. While the owner is identified as an OZ_ProxyAdmin with a 3/6 multisig, the concentration of these powers still represents a high risk if the multisig itself is compromised or mismanaged. The ability to control inflation and freeze pool transfers are particularly sensitive.

FixEnsure the multisig controlling the owner address has robust security practices, including strong key management, regular audits, and clear operational procedures. Consider implementing time-locks or additional governance mechanisms for highly sensitive operations like `updateMintRate` or `unlockPool` to introduce a delay, allowing for community review or emergency intervention.

StatusUnresolved

Medium

Constructor Constraint on Vested Tokens

M-01The constructor includes a `require(vestedTokens < initialSupply, MaxTotalVestedExceeded(...));` statement. This condition prevents the total amount of pre-minted and vested tokens (`vestedTokens`) from being equal to the `initialSupply`. This implies that a portion of the `initialSupply` must always be minted directly to the `recipient` without vesting. This design choice might limit flexibility if the project intends to vest 100% of the initial supply or could lead to unexpected behavior if the `initialSupply` is small and `vestedTokens` approaches it.

IssueThe constructor includes a `require(vestedTokens < initialSupply, MaxTotalVestedExceeded(...));` statement. This condition prevents the total amount of pre-minted and vested tokens (`vestedTokens`) from being equal to the `initialSupply`. This implies that a portion of the `initialSupply` must always be minted directly to the `recipient` without vesting. This design choice might limit flexibility if the project intends to vest 100% of the initial supply or could lead to unexpected behavior if the `initialSupply` is small and `vestedTokens` approaches it.

FixReview this constraint to confirm it aligns with the intended token distribution strategy. If the intention is to allow for 100% of the initial supply to be vested, change the condition to `vestedTokens <= initialSupply`. If the current behavior is intentional, ensure it is clearly documented.

StatusUnresolved

Low

Precision Loss in Vesting and Inflation Calculations

L-01The `computeAvailableVestedAmount` and `mintInflation` functions perform calculations involving multiplication followed by integer division. For example, `totalAmount * (block.timestamp - vestingStart) / vestingDuration` and `(supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days)`. Integer division truncates any fractional part, effectively rounding down. This can lead to minor precision loss, resulting in slightly less than perfectly proportional amounts being released for vesting or minted for inflation over time.

IssueThe `computeAvailableVestedAmount` and `mintInflation` functions perform calculations involving multiplication followed by integer division. For example, `totalAmount * (block.timestamp - vestingStart) / vestingDuration` and `(supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days)`. Integer division truncates any fractional part, effectively rounding down. This can lead to minor precision loss, resulting in slightly less than perfectly proportional amounts being released for vesting or minted for inflation over time.

FixWhile this is a common characteristic of integer arithmetic in Solidity and often acceptable for minor discrepancies, it's important to be aware of its implications. For higher precision, consider using fixed-point arithmetic libraries (e.g., ABDKMathQuad) if the minor precision loss is deemed unacceptable. Otherwise, ensure this behavior is understood and communicated to users.

StatusUnresolved

Low

External Dependency on Permit2 Contract

L-02The `allowance` function grants `type(uint256).max` allowance to a specific `PERMIT_2` address (0x0000…8BA3). This is a common integration with the Permit2 contract, enabling gas-efficient approvals. However, it introduces an external dependency. Any vulnerability or compromise within the Permit2 contract itself could indirectly affect the security of funds approved to this DERC20 token via Permit2.

IssueThe `allowance` function grants `type(uint256).max` allowance to a specific `PERMIT_2` address (). This is a common integration with the Permit2 contract, enabling gas-efficient approvals. However, it introduces an external dependency. Any vulnerability or compromise within the Permit2 contract itself could indirectly affect the security of funds approved to this DERC20 token via Permit2.

FixAcknowledge the inherent risk associated with integrating external protocols. While Permit2 is widely used and audited, it's crucial to monitor its security status. No direct action is required on this contract, but awareness of the dependency is important for overall risk assessment.

StatusUnresolved

Low

Operational Dependency for Inflation Mechanism Start

L-03The `currentYearStart` and `lastMintTimestamp` variables, which are essential for the `mintInflation()` function to operate, are only initialized when the `unlockPool()` function is called by the owner. If `unlockPool()` is never invoked, `mintInflation()` will consistently revert with `MintingNotStartedYet()`, preventing any token inflation from occurring. This creates an operational dependency where the owner must perform an explicit action to enable the core inflation mechanism.

IssueThe `currentYearStart` and `lastMintTimestamp` variables, which are essential for the `mintInflation()` function to operate, are only initialized when the `unlockPool()` function is called by the owner. If `unlockPool()` is never invoked, `mintInflation()` will consistently revert with `MintingNotStartedYet()`, preventing any token inflation from occurring. This creates an operational dependency where the owner must perform an explicit action to enable the core inflation mechanism.

FixEnsure that the operational team is aware of this dependency and has a clear procedure for calling `unlockPool()` at the appropriate time to initiate the inflation schedule. Document the intended timing and conditions for this action.

StatusUnresolved

Info

Ambiguity in `initialSupply` Interpretation

I-01The constructor uses `initialSupply` as a base for calculating `maxPreMintPerAddress` and `maxTotalPreMint` (e.g., `initialSupply * MAX_PRE_MINT_PER_ADDRESS_WAD / 1 ether`). The term `initialSupply` could be interpreted in multiple ways: as the total supply minted at deployment, or as a base amount from which other distributions are derived. The `vestedTokens < initialSupply` check further implies `initialSupply` acts as a hard cap for total initial distribution. Clarity on this interpretation is important for understanding the token's economic model.

IssueThe constructor uses `initialSupply` as a base for calculating `maxPreMintPerAddress` and `maxTotalPreMint` (e.g., `initialSupply * MAX_PRE_MINT_PER_ADDRESS_WAD / 1 ether`). The term `initialSupply` could be interpreted in multiple ways: as the total supply minted at deployment, or as a base amount from which other distributions are derived. The `vestedTokens < initialSupply` check further implies `initialSupply` acts as a hard cap for total initial distribution. Clarity on this interpretation is important for understanding the token's economic model.

FixAdd explicit NatSpec documentation to the `initialSupply` parameter in the constructor, clearly defining its role and how it relates to `vestedTokens` and the `recipient`'s initial balance. This will prevent potential misinterpretations by future auditors or developers.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The DERC20 contract demonstrates good technical architecture, building upon battle-tested OpenZeppelin standards for ERC20, ERC20Votes, ERC20Permit, and Ownable. This significantly reduces the risk of common vulnerabilities (7.1 Architecture, 7.2 Code Security). The custom `_update` function correctly implements a pool locking mechanism, preventing transfers to the designated pool address when locked. However, the inflation and vesting calculations use integer division, which inherently leads to minor precision loss (L-01). Additionally, the inflation mechanism requires an explicit `unlockPool()` call by the owner to begin, posing an operational dependency (L-03).

GovernanceMedium5/10

The contract's economic model includes an inflationary mechanism with a configurable yearly mint rate, capped at 2% of the total supply. The owner, a multisig address, holds significant control over critical functions such as updating the mint rate, locking/unlocking the pool, and burning tokens (7.3 Access Control, 7.4 Economic). While the use of a multisig mitigates single-point-of-failure risk, the concentration of power remains a high-severity concern (H-01). A specific constructor constraint prevents the total vested amount from equaling the initial supply, which might limit distribution flexibility (M-01). The integration with Permit2 introduces an external dependency risk (L-02).

UpgradesLow7/10

The DERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades). Its logic is immutable once deployed. However, certain parameters like the `yearlyMintRate`, `tokenURI`, and the `pool` address can be updated by the owner. This configurability allows for operational adjustments without requiring a full contract redeployment, but does not constitute a full upgrade mechanism.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

62.0% in top 10

6.3% in wallets55.7% in contracts

Effective Concentration28.6%

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

$97.5K across 2 pairs

Uniswap v4WETHanalysed$97.5K Uniswap v4USDC$53

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 Holder48.1%

Top-3 Unlocked90.8%

Key Addresses

6 addresses

Deployer

0x561a…4708

Unlocked LP Held By

0x6363…8c010x05f6…d9040x4df4…2f620xcbe3…f04d0xc1d5…a59d

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

What Raised This Score

7 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Top-10 concentration > 20% (62.0% total → 28.6% effective; 6.3% in EOAs, 55.7% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top3 unlocked holders = 90.8% (independent LP — depth risk)
1 High finding(s) from audit
1 Medium finding(s) from audit
3 Low 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 the sleeping giant Safe?

Security Findings

Centralized Control by Owner

Constructor Constraint on Vested Tokens

Precision Loss in Vesting and Inflation Calculations

External Dependency on Permit2 Contract

Operational Dependency for Inflation Mechanism Start

Ambiguity in `initialSupply` Interpretation

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of the sleeping giant?