Is Ratspeak Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High2 Med2 Low

Critical

Division by Zero in Vesting Calculation

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

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

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

StatusUnresolved

High

Centralized Control Over Token Inflation

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

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

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

StatusUnresolved

High

Arbitrary Pool Lock/Unlock by Owner

H-02The `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.

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

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

StatusUnresolved

Medium

PERMIT_2 Infinite Allowance Implications

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

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

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

StatusUnresolved

Medium

Unclear Purpose of `tokenURI` for ERC20

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

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

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

StatusUnresolved

Low

Limited Burn Functionality

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

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

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

StatusUnresolved

Low

Redundant Vesting Start Check

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

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

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

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh2/10

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.

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

38.9% in top 10

12.8% in wallets26.1% in contracts

Effective Concentration23.2%

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

$367.4K across 10 pairs

Uniswap v4WETHanalysed$354.7K Uniswap v4USDC$11.2K Uniswap v4USDC$1.3K Uniswap v4USDC$133 Hydrex CLAMMWETH$30 Uniswap v4USDC$25

Show 4 more pairsShow less

Uniswap v4USDC$8 Uniswap v4ETH$7 Uniswap v4USDC$6 Uniswap v4USDC$1

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 Holder84.4%

Top-3 Unlocked99.4%

Key Addresses

10 addresses

Deployer

0x256b…328e

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.

What Raised This Score

9 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

Is Ratspeak Safe?

Security Findings

Division by Zero in Vesting Calculation

Centralized Control Over Token Inflation

Arbitrary Pool Lock/Unlock by Owner

PERMIT_2 Infinite Allowance Implications

Unclear Purpose of `tokenURI` for ERC20

Limited Burn Functionality

Redundant Vesting Start Check

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 Ratspeak?