Is 1claw AI (1CLAWAI) Safe? Smart Contract Security Analysis

Security Findings

2 High2 Med2 Low1 Info

High

Denial of Service in `mintInflation()` due to unbounded loop

H-01The `mintInflation()` function contains a `while` loop that iterates for each full year passed since the last minting: `while (block.timestamp > currentYearStart_ + 365 days)`. If this function is not called for an extended period (e.g., several years), the loop could iterate many times, potentially consuming excessive gas and causing the transaction to revert due to an out-of-gas error. This would prevent the owner from minting inflation tokens, disrupting the token's intended economic model (7.2 Code Security, 7.8 Operations).

IssueThe `mintInflation()` function contains a `while` loop that iterates for each full year passed since the last minting: `while (block.timestamp > currentYearStart_ + 365 days)`. If this function is not called for an extended period (e.g., several years), the loop could iterate many times, potentially consuming excessive gas and causing the transaction to revert due to an out-of-gas error. This would prevent the owner from minting inflation tokens, disrupting the token's intended economic model (7.2 Code Security, 7.8 Operations).

FixImplement a mechanism to cap the number of iterations per transaction or allow for partial minting over multiple transactions. Consider storing the `mintableAmount` and `currentYearStart` in a way that allows for claiming in chunks or limits the number of years processed at once to ensure the function remains callable under all circumstances.

StatusUnresolved

High

Potential Integer Overflow in `mintInflation()` Calculation

H-02The `mintInflation()` function calculates `yearMint` and `partialYearMint` using multiplication before division: `(supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days)`. While `uint256` has a large maximum value, if the `supply` grows to an extremely large number (e.g., `2 * 10^53` tokens with 18 decimals), the intermediate product `supply * yearlyMintRate_ * timeLeftInCurrentYear` could exceed `uint256` maximum, leading to an integer overflow and incorrect minting amounts. This could result in an unexpected token supply or a denial of service if the transaction reverts (7.2 Code Security, 7.4 Economic).

IssueThe `mintInflation()` function calculates `yearMint` and `partialYearMint` using multiplication before division: `(supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days)`. While `uint256` has a large maximum value, if the `supply` grows to an extremely large number (e.g., `2 * 10^53` tokens with 18 decimals), the intermediate product `supply * yearlyMintRate_ * timeLeftInCurrentYear` could exceed `uint256` maximum, leading to an integer overflow and incorrect minting amounts. This could result in an unexpected token supply or a denial of service if the transaction reverts (7.2 Code Security, 7.4 Economic).

FixReorder operations to perform division earlier or use a fixed-point math library to prevent intermediate overflow. For example, restructure the calculation to `(supply / (1 ether)) * yearlyMintRate_ * (timeLeftInCurrentYear / (365 days))` or similar, ensuring intermediate values remain within `uint256` limits.

StatusUnresolved

Medium

Centralized Control over Pool Locking

M-01The `lockPool()` and `unlockPool()` functions, callable only by the contract owner, allow the owner to arbitrarily pause or resume transfers to a specific `pool` address. This introduces a significant centralization risk, as the owner can unilaterally disrupt liquidity or interactions with a designated DeFi pool. While potentially useful for emergencies or controlled rollouts, this power could be misused or become a single point of failure for critical integrations (7.3 Access Control, 7.5 Governance).

IssueThe `lockPool()` and `unlockPool()` functions, callable only by the contract owner, allow the owner to arbitrarily pause or resume transfers to a specific `pool` address. This introduces a significant centralization risk, as the owner can unilaterally disrupt liquidity or interactions with a designated DeFi pool. While potentially useful for emergencies or controlled rollouts, this power could be misused or become a single point of failure for critical integrations (7.3 Access Control, 7.5 Governance).

FixClearly document the intended use cases and limitations of this feature. To mitigate centralization risk, consider implementing a timelock for `lockPool()`/`unlockPool()` operations or requiring multi-signature approval for such critical actions.

StatusUnresolved

Medium

Vesting Start Time Dependency on Deployment

M-02The `vestingStart` variable is set to `block.timestamp` in the constructor, meaning vesting begins immediately upon contract deployment. This design choice ties the vesting schedule directly to the deployment time, which might not always align with the project's intended vesting start date, especially if there are unforeseen delays in ecosystem setup or initial token distribution. This could lead to vesting starting earlier or later than desired (7.4 Economic, 7.8 Operations).

IssueThe `vestingStart` variable is set to `block.timestamp` in the constructor, meaning vesting begins immediately upon contract deployment. This design choice ties the vesting schedule directly to the deployment time, which might not always align with the project's intended vesting start date, especially if there are unforeseen delays in ecosystem setup or initial token distribution. This could lead to vesting starting earlier or later than desired (7.4 Economic, 7.8 Operations).

FixConsider allowing `vestingStart` to be set by the owner after deployment, perhaps with a timelock, or by a governance mechanism. This would provide greater flexibility and control over the vesting schedule, allowing for better coordination with project milestones. Alternatively, ensure precise coordination of contract deployment with the desired vesting start.

StatusUnresolved

Low

Lack of Event Emission for Critical State Changes

L-01Several critical state-changing functions, including `lockPool()`, `unlockPool()`, `updateMintRate()`, and `updateTokenURI()`, do not emit events. While the `Ownable` contract emits `OwnershipTransferred`, changes to these specific parameters are not logged on-chain. This makes it difficult for off-chain monitoring tools, users, and auditors to track important administrative actions and verify the contract's current configuration, reducing transparency (7.2 Code Security, 7.8 Operations).

IssueSeveral critical state-changing functions, including `lockPool()`, `unlockPool()`, `updateMintRate()`, and `updateTokenURI()`, do not emit events. While the `Ownable` contract emits `OwnershipTransferred`, changes to these specific parameters are not logged on-chain. This makes it difficult for off-chain monitoring tools, users, and auditors to track important administrative actions and verify the contract's current configuration, reducing transparency (7.2 Code Security, 7.8 Operations).

FixEmit specific events for all critical state changes. For example: `event PoolLocked(address indexed pool, bool isLocked);`, `event MintRateUpdated(uint256 oldRate, uint256 newRate);`, and `event TokenURIUpdated(string newURI);`.

StatusUnresolved

Low

`burn()` function burns from owner's balance

L-02The `burn()` function, callable only by the owner, burns tokens from `owner()`'s balance (`_burn(owner(), amount)`). If the intention was for the owner to burn tokens held by the contract itself (e.g., unvested tokens or tokens sent to the contract by mistake), the current implementation would not achieve this directly without the owner first transferring those tokens to their own address. This might lead to confusion or require additional steps for certain burning scenarios (7.2 Code Security, 7.8 Operations).

IssueThe `burn()` function, callable only by the owner, burns tokens from `owner()`'s balance (`_burn(owner(), amount)`). If the intention was for the owner to burn tokens held by the contract itself (e.g., unvested tokens or tokens sent to the contract by mistake), the current implementation would not achieve this directly without the owner first transferring those tokens to their own address. This might lead to confusion or require additional steps for certain burning scenarios (7.2 Code Security, 7.8 Operations).

FixClarify the intended use of the `burn()` function. If the goal is to allow the owner to burn tokens held by the contract, modify the function to `_burn(address(this), amount);` or provide a separate function for that specific purpose. If the current behavior is intended, ensure it is clearly documented.

StatusUnresolved

Info

Unused `Nonces` import

I-01The contract imports `Nonces` from `@openzeppelin/utils/Nonces.sol` but does not explicitly inherit from it. The `ERC20Permit` contract, which `DERC20` already inherits from, itself inherits from `Nonces`. Therefore, the direct import of `Nonces` in `DERC20.sol` is redundant and can be removed without affecting functionality (7.2 Code Security).

IssueThe contract imports `Nonces` from `@openzeppelin/utils/Nonces.sol` but does not explicitly inherit from it. The `ERC20Permit` contract, which `DERC20` already inherits from, itself inherits from `Nonces`. Therefore, the direct import of `Nonces` in `DERC20.sol` is redundant and can be removed without affecting functionality (7.2 Code Security).

FixRemove the redundant `import { Nonces } from "@openzeppelin/utils/Nonces.sol";` statement to improve code clarity and reduce unnecessary dependencies.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The DERC20 contract is built upon robust OpenZeppelin standards (ERC20, ERC20Votes, ERC20Permit, Ownable), providing a solid foundation for token operations (7.1 Architecture). The custom vesting and pool locking mechanisms are generally well-structured. However, the `mintInflation()` function presents two significant technical risks: a potential integer overflow in its calculation logic, which could lead to incorrect token minting (7.2 Code Security), and a denial-of-service vulnerability due to an unbounded `while` loop that could exhaust gas if not called frequently (7.2 Code Security, 7.8 Operations). The `_update` override for pool locking functions as intended (7.3 Access Control).

GovernanceHigh3/10

The contract operates under an `Ownable` access control model, granting the owner significant power over key parameters (7.5 Governance). The owner can set and update the `yearlyMintRate`, control the `pool` locking mechanism, and burn tokens (7.3 Access Control). This centralization introduces a medium economic risk, as the owner's actions can directly impact token liquidity and supply dynamics (7.4 Economic). The vesting mechanism is standard, but its start time is fixed at deployment, which might not align with all project timelines (7.4 Economic). Pre-mint limits are enforced in the constructor, contributing to initial supply control.

UpgradesMedium4/10

The DERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, it does not inherit the specific upgradeability risks associated with proxy patterns, such as storage collisions or improper initialization. Any future changes to the contract's logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

53.8% in top 10

11.2% in wallets42.6% in contracts

Effective Concentration28.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

$162.0K across 5 pairs

Uniswap v4WETHanalysed$161.9K Uniswap v4USDC$41 Uniswap v4USDC$25 Uniswap v4USDC$16 Uniswap v4ETH$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 Holder85.1%

Top-3 Unlocked100.0%

Key Addresses

4 addresses

Deployer

0xb2f5…431e

Unlocked LP Held By

0xe397…2bee0xaf84…53150x8ee4…485a

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)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 20% (53.8% total → 28.2% effective; 11.2% in EOAs, 42.6% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 85.1% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
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

Not Signed In

Is 1claw AI Safe?

Security Findings

Denial of Service in `mintInflation()` due to unbounded loop

Potential Integer Overflow in `mintInflation()` Calculation

Centralized Control over Pool Locking

Vesting Start Time Dependency on Deployment

Lack of Event Emission for Critical State Changes

`burn()` function burns from owner's balance

Unused `Nonces` import

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 1claw AI?