Quantum Audit Logo
Launch App

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

Is the sleeping giant Safe?

TSGBase
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance5/10Upgrades7/10Checks passed3 of 5Findings1 High · 1 Medium · 3 Low · 1 Info6
SummaryAI Copilot

The DERC20 token contract implements an ERC20 token with voting, permit, and ownership functionalities.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 90.8%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 3 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
55.7%Contracts6.3%38.0%Everyone else
55.7%Contracts6.3%38.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
62.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking55.7%
  • Walletsanonymous holders, free to sell6.3%
  • Everyone elsethe rest of the supply38.0%
Effective concentrationwhat the score reads28.6%
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$97.5K 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$97.5KShare of depth99.9%
Top-1 Unlocked Holder48.1%
Top-3 Unlocked90.8%
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.

Security Findings

1 High1 Medium3 Low1 Info
High

Centralized Control by Owner

The 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.H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Constructor Constraint on Vested Tokens

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

Issue

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

Fix

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

Status

Unresolved

Low

Precision Loss in Vesting and Inflation Calculations

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Low

External Dependency on Permit2 Contract

The 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.L-02

Issue

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

Fix

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

Status

Unresolved

Low

Operational Dependency for Inflation Mechanism Start

The 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.L-03

Issue

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

Fix

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

Status

Unresolved

Info

Ambiguity in initialSupply Interpretation

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

The DERC20 token contract implements an ERC20 token with voting, permit, and ownership functionalities. It includes a vesting mechanism for initial token distribution and an inflation mechanism controlled by the owner. The contract leverages well-audited OpenZeppelin libraries, enhancing its foundational security. Key areas of concern include the significant centralized control retained by the owner over critical functions and a specific constraint in the constructor regarding vested token amounts.

Technical8/10Low risk

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

Governance5/10Medium risk

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

Upgrades7/10Low risk

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.

Final RecommendationWhat to do about this score

It is recommended to carefully manage the owner's multisig keys and ensure robust operational procedures for critical functions like unlockPool() and updateMintRate().

Consider reviewing the MaxTotalVestedExceeded constraint in the constructor to ensure it aligns with the project's long-term distribution strategy. While precision loss in integer arithmetic is common, ensure stakeholders are aware of its minor implications for vesting and inflation calculations. Thoroughly document all owner-controlled parameters and their intended use.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age3mo
Contract0x4c43…eba3
Deployer0x561a…4708
Badge for your website
the sleeping giant 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. Sep 4, 202637Medium
  2. Aug 17, 202640Medium

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

Frequently Asked Questions

What is the TSG contract address?

The the sleeping giant (TSG) contract on Base is 0x4c433f4ef87fe506a7eed2fd1d822cbed411eba3. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is the sleeping giant a scam?

Quantum Audit's risk score for the sleeping giant is 37/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is TSG liquidity locked?

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

Who holds TSG?

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

Related Audits

6 more on the recordAll audits
OpenGradientOPG · Base37MediumZoraBase37MediumnoiceBase37MediumChainLink TokenLINK · Base37MediumMUSWORLDMUSEWORLD · Base37MediumAave TokenAAVE · Base38Medium

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

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