Zenko Protocol Info
Zenko is a next-generation, decentralized crypto infrastructure platform designed to deliver institutional-grade financial tools to a global retail user base. At its core, Zenko addresses a fundamental problem in the digital asset space: the imbalance of access, opportunity, and infrastructure between large institutional participants and everyday users. While hedge funds and trading firms benefit from low-latency execution, advanced analytics, and predictive automation, most retail users are left with fragmented tools, opaque platforms, and limited control over their assets.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Ownership Privileges
- The owner can update the zenBurnRate, but it is strictly limited to a maximum of 20%.
- The owner can exempt specific addresses from transfer restrictions, allowing them to move tokens even when trading is paused.
- The owner can exempt specific addresses from paying the ZEN burn tax on sells, giving them a financial advantage over regular users.
- The owner can enable global transfers, but is explicitly prevented from disabling them again (One-way switch).
- The owner can whitelist new Uniswap Factories, but the list is hard-capped at 10 to prevent gas exhaustion.
- The owner can manually flag any address as a "Liquidity Pair," triggering tax logic on transfers to that address.
- The owner can enable the ability to buy tokens, but is explicitly prevented from disabling it again (One-way switch).
- The owner can manually trigger the pair detection logic to fix missed pairs or register new ones.
- The owner can revoke a pending ownership transfer before it is accepted.
- The owner can renounce ownership to make the contract trustless (Standard Ownable2Step behavior).
Note - This Audit report consists of a security analysis of the ZENKO smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the ZENKO team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
medium Issues | 8 findings
Resolved
#1 medium Issue
Non-Standard ERC20 Logic Modifications
The developer has manually modified the ERC20 base contract logic, introducing deviations from the standard that pose integration risks. Restrictive Approval Logic: The approve function was modified to enforce a "reset-to-zero" requirement (require(amount == 0 || allowance == 0)). This breaks compatibility with standard DeFi protocols (like Uniswap routers) that attempt to update allowances directly, causing those transactions to revert. Removal of Safety Checks: Critical validation checks were removed from _mint, _burn, and _transfer. Specifically, the contract no longer prevents transfers to or from the zero address (address(0)), creating a risk where users can accidentally burn tokens or distort the total supply.
Resolved
#2 medium Issue
Centralization Risk via Disabled Ownership Renouncement
The contract utilizes a custom Ownable implementation that explicitly disables the renounceOwnership function (lines 141-143), causing it to revert when called. While the implementation correctly adds a secure two-step transfer process (transferOwnership and acceptOwnership), the inability to renounce ownership means the contract creates a permanent dependency on the owner wallet. The project administrators can never "burn the keys" or irrevocably give up control to make the protocol fully trustless or decentralized in the future.
Resolved
#3 medium Issue
Critical Functional Failure via WETH Address Mismatch
The constructor accepts _weth as a manual parameter alongside _router, creating a high risk of configuration mismatch. Uniswap V2-style routers are hardcoded to use a specific WETH address. If the deployer inadvertently provides a _weth address that differs from the router's canonical WETH() address, the contract will create and recognize a liquidity pair for the wrong WETH address (TestToken <-> Wrong_WETH). Meanwhile, the Router (and the standard Uniswap frontend) will facilitate trades using the canonical WETH, interacting with a different pair (TestToken <-> Router_WETH) that the contract does not recognize in its isPair mapping. As a result, critical token logic associated with trading—such as taxes or burn mechanisms—will fail to execute for actual user trades, rendering the token's economic model dysfunctional.
Resolved
#4 medium Issue
Centralization Risk via Mutable "Dead" Address
The contract includes a setDeadAddress function that allows the owner to arbitrarily update the destination address for the mandatory TES token "burns" collected during sells. While the variable is named deadAddress (implying tokens are permanently removed from circulation), the owner can reset this address to a wallet they control (e.g., a treasury or personal wallet). This capability effectively allows the project team to silently convert the deflationary "burn" mechanism into a "fee collection" mechanism, capturing the value that users believe is being destroyed.
Resolved
#5 medium Issue
Excessive Max Burn Rate (Honeypot Risk)
The setTesBurnRate function allows the contract owner to set the tesBurnRate to as high as 100%. If set to this maximum, users attempting to sell TestToken would be required to burn an equivalent amount of TES tokens (1:1 ratio). Depending on the relative price of the two tokens, this could make the cost of selling effectively infinite or exceed the value of the sale itself (e.g., burning $200 of TES to sell $100 of TestToken). This mechanism can be used maliciously to lock user funds (Honeypot) or create a Denial-of-Service condition where users are unable to afford the exit tax.
Resolved
#6 medium Issue
Centralized Trading Pause (Honeypot Risk)
The setTransferOpen function allows the contract owner to arbitrarily toggle the global transfer status (transferOpen) on or off at any time. While useful for coordinating the initial launch, the ability to disable transfers after trading has begun grants the owner a "Kill Switch" over the token economy. A malicious owner could execute a rug pull or honeypot attack by letting users buy the token and then immediately setting transferOpen to false, effectively freezing all user assets and preventing anyone from selling or exiting their positions.
Resolved
#7 medium Issue
Centralized Buy Control (Market Manipulation Risk)
The setBuyOpen function allows the contract owner to toggle the ability for users to buy tokens (buyOpen). Unlike standard "trading enable" functions which are one-way, this function permits the owner to disable buys at any time. The Risk: Disabling buys while keeping sells open guarantees that the token price can only decrease. This capability can be used for market manipulation or to damage the project's reputation. It serves no standard security purpose after the initial launch phase.
Pending
#8 medium Issue
Sell-Side Dependency on External Token (DoS & Economic Risk)
The contract enforces a "burn-on-sell" mechanism that makes the ability to sell TestToken contingent on the user holding and approving a secondary token (ZEN). Denial of Service (DoS): If a user does not have sufficient ZEN balance or has not approved the ZENKO contract to spend it, the sell transaction will revert, effectively trapping their funds. Economic Instability: The burn calculation relies on a hardcoded 1:1 unit ratio (ZENAmount = zenkoAmount * rate / 100). It does not account for the market price difference between the two tokens. If the price of ZEN rises significantly relative to ZENKO, the mandatory "exit tax" could exceed the value of the sale itself, making exits economically irrational or impossible.
low Issues | 4 findings
Resolved
#1 low Issue
Deployment Denial-of-Service (DoS) Risk via createPair
The constructor unconditionally calls IUniswapV2Factory.createPair() to establish the liquidity pool. Since the Uniswap Factory's createPair function reverts if a pair already exists, this creates a Denial-of-Service (DoS) vector. A malicious actor observing the deployment transaction in the mempool could predict the new token's address and front-run the deployment by calling createPair manually. If the attacker's transaction executes first, the pair will already exist when the constructor attempts to create it, causing the createPair call—and consequently the entire deployment transaction—to revert. This results in wasted gas and a failed launch.
Resolved
#2 low Issue
Restrictive Whitelist Logic Blocking Pre-Launch Distribution
The whitelist logic applied when transfers are closed (transferOpen = false) is functionally flawed. The current implementation dictates that if a sender is whitelisted (transferWhitelist[from]), they are only permitted to send tokens to other whitelisted recipients (require(transferWhitelist[to])). This creates a "trapped" state where whitelisted administrative contracts—such as Airdrop distributors, Presale claim contracts, or Vesting vaults—cannot distribute tokens to regular users. As a result, the project is unable to perform standard pre-launch token distributions unless the Owner wallet (which is exempt) performs every transfer manually, or every single user recipient is manually whitelisted first.
Resolved
#3 low Issue
Gas Exhaustion Denial-of-Service via Unbounded Loop in _transfer
The _maybeMarkPair function, which is called on every transfer to a non-pair contract address, contains an unbounded loop that iterates through the factories array. When a user transfers tokens to any contract address that is not yet marked as a pair, the code executes this loop to check if it's a valid liquidity pool. The Risk: The factories array grows every time the owner calls setFactoryAllowed. There is no limit on the array size. If the factories array becomes large (either through malicious intent or administrative bloat), the gas cost of transferring tokens to new contracts will exceed the block gas limit, causing transactions to revert. This creates a potential Denial-of-Service (DoS) condition for interacting with other protocols.
Resolved
#4 low Issue
Double-Failure in _burnTes Execution Flow
The _burnTes function attempts two methods to collect the tax: first calling TES.burnFrom, and if that fails, falling back to TES.transferFrom to a dead address. However, both methods fundamentally rely on the same precondition: the user must have approved the TestToken contract to spend their TES balance. If the allowance is missing, both calls will fail sequentially, causing the transaction to revert. The "fallback" logic provides no actual safety net for the most common failure mode (missing approval).
informational Issues | 2 findings
Acknowledged
#1 informational Issue
Floating pragma solidity version.
Adding the constant version of solidity is recommended, as this prevents the unintentional deployment of a contract with an outdated compiler that contains unresolved bugs.
Resolved
#2 informational Issue
Missing events
It is recommended to emit all the critical parameter changes.