Quantum Audit Logo
Launch App

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

Is Ratspeak Safe?

RATSPEAKBase
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/10Governance2/10Upgrades6/10Checks passed5 of 7Findings1 Critical · 2 High · 2 Medium · 2 Low7
SummaryAI Copilot

The DERC20 token contract implements standard ERC20 functionality with extensions for voting, permit, and ownership.

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 top1 unlocked holder = 84.4%
  • LP top3 unlocked holders = 99.4%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (38.9% total → 23.2% effective; 12.8% in EOAs, 26.1% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 84.4% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 99.4% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
26.1%Contracts12.8%Wallets61.1%Everyone else
26.1%Contracts12.8%Wallets61.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
38.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking26.1%
  • Walletsanonymous holders, free to sell12.8%
  • Everyone elsethe rest of the supply61.1%
Effective concentrationwhat the score reads23.2%
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$367.4K across 10 pairs
Show 4 more 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$354.7KShare of depth96.5%
Top-1 Unlocked Holder84.4%
Top-3 Unlocked99.4%
Unlocked LP held by
0x575e…fe980x50f5…d2700xced6…c2490x3269…b9070xe1f6…806f0xbc75…a8dd0xd0f5…48170x6c94…80160x8457…d8f2

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

Security Findings

1 Critical2 High2 Medium2 Low
Critical

Division by Zero in Vesting Calculation

The computeAvailableVestedAmount function performs a division by vestingDuration. If vestingDuration is initialized to 0 in the constructor, any call to computeAvailableVestedAmount (and consequently release()) will result in a division-by-zero error, making all vested tokens permanently unclaimable. The constructor currently lacks a check to ensure vestingDuration_ is greater than zero.C-01

Issue

The computeAvailableVestedAmount function performs a division by vestingDuration. If vestingDuration is initialized to 0 in the constructor, any call to computeAvailableVestedAmount (and consequently release()) will result in a division-by-zero error, making all vested tokens permanently unclaimable. The constructor currently lacks a check to ensure vestingDuration_ is greater than zero.

Fix

Add a require(vestingDuration_ > 0, "Vesting duration must be positive") check in the constructor to prevent vestingDuration from being set to zero.

Status

Unresolved

High

Centralized Control Over Token Inflation

The mintInflation() function, which controls the token's supply expansion, mints all new tokens exclusively to the owner(). Additionally, the updateMintRate() function, which sets the yearlyMintRate, is restricted to onlyOwner. This grants the contract owner significant centralized control over the token's economic policy and the accumulation of newly minted supply, potentially leading to manipulation or disproportionate ownership.H-01

Issue

The mintInflation() function, which controls the token's supply expansion, mints all new tokens exclusively to the owner(). Additionally, the updateMintRate() function, which sets the yearlyMintRate, is restricted to onlyOwner. This grants the contract owner significant centralized control over the token's economic policy and the accumulation of newly minted supply, potentially leading to manipulation or disproportionate ownership.

Fix

Consider implementing a more decentralized approach for inflation management. Options include: (1) directing minted tokens to a community treasury or a staking pool, (2) requiring a governance vote for updateMintRate changes, or (3) transferring ownership to a robust multi-signature wallet or a DAO.

Status

Unresolved

High

Arbitrary Pool Lock/Unlock by Owner

The lockPool() and unlockPool() functions, which control whether transfers to the designated pool address are allowed, are restricted to onlyOwner. This means the contract owner can arbitrarily prevent or allow transfers to a critical external protocol (the pool), potentially disrupting its functionality or creating a single point of failure for users interacting with that pool.H-02

Issue

The lockPool() and unlockPool() functions, which control whether transfers to the designated pool address are allowed, are restricted to onlyOwner. This means the contract owner can arbitrarily prevent or allow transfers to a critical external protocol (the pool), potentially disrupting its functionality or creating a single point of failure for users interacting with that pool.

Fix

Evaluate the necessity of this level of centralized control. If a pool lock mechanism is required, consider implementing a time-lock for lockPool()/unlockPool() operations or requiring a multi-signature approval to provide a delay and transparency for such critical actions.

Status

Unresolved

Medium

PERMIT_2 Infinite Allowance Implications

The allowance function is overridden to return type(uint256).max (infinite allowance) if the spender is PERMIT_2 (0x0000…8BA3). While this is a feature of the Permit2 standard, it means that any user who interacts with Permit2 and approves this token effectively grants Permit2 the ability to move an unlimited amount of their tokens. This is a significant security implication that users should be fully aware of.M-01

Issue

The allowance function is overridden to return type(uint256).max (infinite allowance) if the spender is PERMIT_2 (). While this is a feature of the Permit2 standard, it means that any user who interacts with Permit2 and approves this token effectively grants Permit2 the ability to move an unlimited amount of their tokens. This is a significant security implication that users should be fully aware of.

Fix

Ensure clear communication to users about the implications of interacting with Permit2 and the infinite allowance granted to it. Provide educational resources or warnings within the dApp interface if applicable.

Status

Unresolved

Medium

Unclear Purpose of tokenURI for ERC20

The contract includes a tokenURI state variable and an updateTokenURI function, typically associated with ERC721 or ERC1155 tokens for metadata. For an ERC20 token, this field is non-standard and its intended purpose is unclear from the code alone. This could lead to confusion or indicate an incomplete design if it was meant to integrate with NFT-like features.M-02

Issue

The contract includes a tokenURI state variable and an updateTokenURI function, typically associated with ERC721 or ERC1155 tokens for metadata. For an ERC20 token, this field is non-standard and its intended purpose is unclear from the code alone. This could lead to confusion or indicate an incomplete design if it was meant to integrate with NFT-like features.

Fix

Clarify the intended use case for the tokenURI field in the contract documentation. If it's not serving a specific purpose, consider removing it to reduce contract complexity and potential for misinterpretation. If it's for off-chain metadata, ensure its purpose is well-defined.

Status

Unresolved

Low

Limited Burn Functionality

The burn() function is restricted to onlyOwner and only allows burning tokens from the owner()'s balance. This provides a very limited burn mechanism, as general users cannot burn their own tokens, nor can the owner burn tokens from other addresses. If a broader token burning utility was intended, the current implementation is insufficient.L-01

Issue

The burn() function is restricted to onlyOwner and only allows burning tokens from the owner()'s balance. This provides a very limited burn mechanism, as general users cannot burn their own tokens, nor can the owner burn tokens from other addresses. If a broader token burning utility was intended, the current implementation is insufficient.

Fix

If a general burn mechanism for all token holders is desired, consider implementing a public burn(uint256 amount) function that allows msg.sender to burn their own tokens. If the current limited functionality is intentional, document this design choice clearly.

Status

Unresolved

Low

Redundant Vesting Start Check

The hasVestingStarted modifier includes require(vestingStart > 0, VestingNotStartedYet()). However, vestingStart is initialized to block.timestamp in the constructor, which will always be a positive value. Therefore, this check is redundant and will always pass.L-02

Issue

The hasVestingStarted modifier includes require(vestingStart > 0, VestingNotStartedYet()). However, vestingStart is initialized to block.timestamp in the constructor, which will always be a positive value. Therefore, this check is redundant and will always pass.

Fix

Remove the require(vestingStart > 0, VestingNotStartedYet()) check from the hasVestingStarted modifier as it is redundant.

Status

Unresolved

Analysis

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

The DERC20 token contract implements standard ERC20 functionality with extensions for voting, permit, and ownership. It includes custom features for token vesting, an inflation mechanism, and a configurable pool lock. The audit identified a critical vulnerability related to potential division by zero in the vesting calculation, which could render vested tokens unclaimable. High-severity issues include significant owner control over token supply inflation and the ability to arbitrarily lock/unlock transfers to a designated pool address. Several medium and low-severity findings highlight design considerations and minor inefficiencies.

Technical6/10Medium risk

The contract leverages OpenZeppelin libraries for core ERC20 functionality, contributing to a robust foundation (7.2 Code Security). The custom vesting and inflation mechanisms are generally well-structured, with clear state variables and modifiers (7.1 Architecture). However, a critical vulnerability exists where passing a zero vestingDuration in the constructor leads to a division-by-zero error, making vested tokens permanently inaccessible (7.2 Code Security). Additionally, the PERMIT_2 infinite allowance, while a feature, introduces a significant security consideration for users (7.3 Access Control).

Governance2/10High risk

The contract design grants significant centralized control to the owner (7.5 Governance). The owner can control the yearlyMintRate (within a cap) and is the sole recipient of all minted inflation tokens, allowing for substantial influence over the token's economic supply (7.4 Economic). Furthermore, the owner has the exclusive ability to lock and unlock transfers to a designated pool address, which could disrupt interactions with integrated protocols (7.3 Access Control, 7.6 External). While MAX_YEARLY_MINT_RATE_WAD provides a cap, the owner's discretion over minting timing and recipient remains a central point of control.

Upgrades6/10Medium risk

The DERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades). Its core logic and state variables are immutable once deployed, which eliminates upgrade-related risks such as storage collisions or faulty upgrade paths. Any changes to the contract's functionality would require a new deployment and migration of assets, a standard practice for non-upgradeable contracts.

Final RecommendationWhat to do about this score

Address the critical division-by-zero vulnerability by adding a require check for vestingDuration_ > 0 in the constructor.

Consider decentralizing control over inflation and pool locking mechanisms, potentially through a multi-signature wallet or a time-locked governance contract, to reduce single points of failure and enhance trust. Clearly document the purpose of the tokenURI field for an ERC20 token to avoid confusion. Ensure users are fully aware of the implications of granting infinite allowance to PERMIT_2.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age3mo
Contract0xf1e9…bba3
Deployer0x256b…328e
Badge for your website
Ratspeak 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 30, 202680High

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

Frequently Asked Questions

What is the RATSPEAK contract address?

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

Is Ratspeak a scam?

Quantum Audit's risk score for Ratspeak is 80/100 (High 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; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is RATSPEAK liquidity locked?

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

Who holds RATSPEAK?

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

Related Audits

6 more on the recordAll audits
Superfluid TokenSUP · Base81HighHodlHerHODL · Base79HighWrapped PROSPROS · Base77HighCortexCX · Base77HighzipcoinZC · Base83HighCysicCYS · Base84High

Would You Like a More Detailed Audit of Ratspeak?

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