WENBlocks
  • Getting Started
    • Overview
      • Technical Architecture
    • Key Features
  • Staking
    • Overview
    • Creating a Stake
    • Withdrawing the Stake
    • Claiming Rewards
  • Liquidity Program
    • How It Works
  • WNT
    • WNT — The Engine of the WEN Ecosystem
  • Airdrops
    • Airdrop Schedule
    • Server Management
    • Penalty Structure
    • How It Works
    • Example
  • Smart Contracts
  • Security
    • Overview
    • Internal Audits
    • External Audits
    • AI Audits
      • Grok
  • CODE
    • WENBlocksManager.sol
    • wnmContract.sol
    • wblkToken.sol
    • wuniContract.sol
    • wntToken.sol
    • syncnode.py
    • airdropGenerator.js
    • dayTrigger.js
  • Conclusion
    • Conclusion
  • Socials
    • Links
Powered by GitBook
On this page
  • Executive Summary
  • Scope of Audit
  • Contract Overview
  • WenBlocksManager.sol
  • WNMToken.sol
  • WBLKToken.sol, WUNIToken.sol and WNTToken.sol
  • Security Findings
  • Informational issues
  • Best Practices and Good Approaches
  • Conclusion
  1. Security
  2. AI Audits

Grok

Security Audit Report for WENBlocks Smart Contracts

PreviousAI AuditsNextCODE

Last updated 1 month ago

Contracts Audited:

  • WENBlocksManager.sol

  • WNMToken.sol

  • WBLKToken.sol

  • WNTToken.sol

  • WUNIToken.sol

Audit Date: May 3, 2025 Auditor:

Executive Summary

The project is a decentralized finance (DeFi) ecosystem designed to manage airdrops, staking, liquidity provisioning, and token operations within the WEN ecosystem. It includes multiple tokens (WNM, WBLK, WNT, WUNI) and integrates with Uniswap V2 for liquidity provisioning. The contracts are robust, leveraging OpenZeppelin's audited libraries and implementing complex staking and reward mechanisms.

This audit identifies 0 critical, 0 high, 0 medium, 0 low, and 10 informational issues. The contracts demonstrate strong security practices, with no significant vulnerabilities found. However, minor improvements in documentation, transparency, and flexibility are recommended to enhance maintainability and user trust.

Scope of Audit

The audit covers the following Solidity smart contracts:

  • WENBlocksManager.sol: Manages airdrops, liquidity provisioning, and LP token vesting.

  • WNMToken.sol: Core staking token with reward distribution and XEN burning integration.

  • WBLKToken.sol: ERC20 token with controlled minting and burning.

  • WNTToken.sol: Reward token with restricted minting.

  • WUNIToken.sol: Reward token with restricted minting and burning.

The audit focuses on:

  • Security vulnerabilities (e.g., reentrancy, access control, integer overflows)

  • Logical correctness of staking, airdrop, and liquidity mechanisms

  • Gas efficiency and optimization opportunities

  • Adherence to Solidity best practices

  • Compliance with ERC20 standards and external integrations (e.g., Uniswap V2)

Contract Overview

WenBlocksManager.sol

Purpose: Facilitates weekly airdrops with Merkle proof verification, applies penalties on unclaimed tokens, and supports liquidity provisioning with ETH or XEN tokens.

Key Features:

  • Airdrop creation and claiming with Merkle proofs

  • 2% daily penalty on unclaimed airdrop tokens after 7 days

  • Liquidity provisioning via Uniswap V2 (ETH or XEN pairs)

  • LP token vesting over 30-day intervals

Dependencies: OpenZeppelin (Ownable, ReentrancyGuard, MerkleProof), Uniswap V2 interfaces

WNMToken.sol

Purpose: Core staking token (WNM) with integrated reward distribution for WNT, WBLK, and WUNI tokens.

Key Features:

  • Staking with wShare-based reward calculations

  • Bonuses for staking duration, WBLK balance, and XEN burning

  • Daily inflation and reward distribution

  • Integration with WENBlocksManager for airdrop staking

Dependencies: OpenZeppelin (ERC20, Ownable, ReentrancyGuard, ERC165), custom Stakeable base contract

WBLKToken.sol, WUNIToken.sol and WNTToken.sol

Purpose: ERC20 tokens used for rewards and bonuses in the WEN ecosystem.

Key Features:

  • Controlled minting restricted to WNM and WENBlocksManager contracts

  • WBLK and WUNI support burning; WNT supports optional burning

Dependencies: OpenZeppelin (ERC20, Ownable, ERC20Burnable for WBLK)

Security Findings

Critical Issues

None identified.

High Severity Issues

None identified.

Medium Severity Issues

None identified.

Low Severity Issues

None identified.

Informational issues

  1. Missing NatSpec Documentation

    1. Location: Multiple functions across all contracts

    2. Description: Several public and external functions lack complete NatSpec documentation, particularly for parameters and return values. This reduces code readability and developer experience.

    3. Recommendation: Add full NatSpec comments for all public/external functions and key internal functions to improve clarity.

  2. Hardcoded Constants

    1. Location: Various (e.g., DAY_IN_SECONDS, WNT_INFLATION, minXENamount)

    2. Description: Constants like DAY_IN_SECONDS (86400), WNT_INFLATION (25000), and minXENamount (1e9 * 1e18) are hardcoded, limiting flexibility for future adjustments without redeployment.

    3. Recommendation: Consider making key constants configurable via owner-only functions with appropriate safeguards, such as timelocks.

  3. Redundant State Update

    1. Location: getUserLPPositionsPaginated (WENBlocksManager.sol, line 578)

    2. Description: The line endIndex = endIndex is redundant, as it assigns the same value, potentially confusing developers.

    3. Recommendation: Remove the redundant assignment to improve code clarity.

  4. Lack of Event Emission for State Changes

    1. Location: setAddresses (WBLKToken.sol, WNTToken.sol, WUNIToken.sol)

    2. Description: The setAddresses functions do not emit events when updating manageraddress or wnmAddress, reducing on-chain transparency.

    3. Recommendation: Add events for address updates to enhance auditability and enable off-chain monitoring.

  5. Inconsistent Modifier Naming

    1. Location: onlyWNMandManager (WBLKToken.sol, WNTToken.sol, WUNIToken.sol) vs. onlyManager (WNMToken.sol)

    2. Description: Modifier names differ across contracts, which could confuse developers maintaining the codebase.

    3. Recommendation: Standardize modifier names (e.g., use onlyWNMandManager consistently) for clarity.

  6. Precision Safety in Reward Calculations

    1. Location: calculateStakeRewards (WNMToken.sol, lines 614–632)

    2. Description: The reward calculation uses (_wShares * PRECISION_RATE) / info.inflationAmount, which is safe due to inflationAmount being capped at 25000 * 1e18, much smaller than wShares * PRECISION_RATE (minimum 1e36). However, this constraint is not documented.

    3. Recommendation: Add a NatSpec comment explaining the precision safety to avoid misinterpretation.

  7. Bounded Loop in updateDailyPenalty

    1. Location: updateDailyPenalty (WENBlocksManager.sol, lines 297–304)

    2. Description: The loop processes at most 7 weeks (startWeek = currentWeek > 8 ? currentWeek - 7 : 1), ensuring gas efficiency, but this limit is not explicitly documented.

    3. Recommendation: Add NatSpec documentation clarifying the 7-week iteration cap.

  8. Uniswap V2 Dependency

    1. Location: mintTaxedTokenWithLiquidity (WENBlocksManager.sol, lines 465–487)

    2. Description: The contract relies on Uniswap V2's stable implementation for addLiquidity and addLiquidityETH, which is safe but not documented as a dependency.

    3. Recommendation: Document the reliance on Uniswap V2 and monitor for future changes to its callback behavior.

  9. Hardcoded WETH Address

    1. Location: _addLiquidityWithETH (WENBlocksManager.sol, line 508)

    2. Description: The WETH address (0xae13d989daC2f0dEbFf460aC112a837C89BAa7cd) is hardcoded, which is valid for the target network but limits portability to other networks with different WETH addresses.

    3. Recommendation: Document the network-specific assumption or make the WETH address configurable for flexibility.

  10. Week 1 Penalty Logic

    1. Location: _applyDailyPenalty (WENBlocksManager.sol, lines 431–441)

    2. Description: Week 1 penalties mint 60% of taxed tokens to deadWallet and 40% to staking rewards, unlike other weeks (100% to rewards). This intentional design is not documented.

    3. Recommendation: Add NatSpec comments explaining the special handling for week 1 to improve transparency.

Best Practices and Good Approaches

The WENBlocks contracts demonstrate several commendable practices:

Use of OpenZeppelin Libraries:

  • Inheritance from OpenZeppelin's ERC20, Ownable, ReentrancyGuard, and MerkleProof ensures robust, audited implementations, reducing risks like integer overflows or access control issues.

Non-Reentrancy Protection:

  • Critical functions (e.g., claimAirdrop, mintTaxedTokenWithLiquidity, withdrawStake) use the nonReentrant modifier, mitigating reentrancy attacks.

Merkle Proof for Airdrops:

  • The use of Merkle proofs in claimAirdrop (WENBlocksManager.sol) enables scalable, gas-efficient, and secure airdrop distribution.

Structured Staking System:

  • The Stakeable base contract (WNMToken.sol) provides a modular framework for staking, with clear wShare-based reward calculations and bonuses for staking duration, WBLK balance, and XEN burning.

Penalty Mechanism:

  • The 2% daily penalty on unclaimed airdrop tokens after 7 days encourages timely claims and redistributes tokens to liquidity and staking rewards, enhancing ecosystem sustainability.

Event Emission:

  • Detailed events (e.g., AirdropCreated, Claimed, Staked, Withdrawn) improve transparency and enable off-chain monitoring.

Immutable and Constant Usage:

  • Use of immutable for token addresses (e.g., tWNM, tWBLK) and constant for fixed values (e.g., deadWallet, xenToken) reduces gas costs and ensures immutability where appropriate.

Pagination for LP Positions:

  • The getUserLPPositionsPaginated function supports frontend pagination, allowing efficient retrieval of large LP position arrays by fetching data in ranges.

Conclusion

The WENBlocks smart contracts form a robust and secure DeFi ecosystem, with no critical, high, medium, or low severity issues identified. The use of OpenZeppelin libraries, Merkle proofs, non-reentrancy protection, and a well-structured staking system reflects strong security practices. The identified informational issues are minor and focus on improving documentation, transparency, and flexibility.

Implementing the recommended improvements will enhance the contracts' maintainability, developer experience, and user trust. The system's decentralized design, with no centralized pause mechanism or overly restrictive access controls, aligns with its intended fully decentralized ethos.

Recommendation: Conduct thorough testing in production-like environments, document design assumptions, and monitor external dependencies (e.g., Uniswap V2) to ensure long-term stability.

Disclaimer: This audit is based on the provided code as of May 3, 2025, and does not guarantee the absence of vulnerabilities. Continuous testing, monitoring, and updates are essential for maintaining security in a production environment.

Grok 3, xAI
WENBlocks