LayerTao Info
LayerTao is the abstraction layer on Bittensor, giving developers simple APIs, smart routing, and seamless payments to build decentralized AI faster. Bittensor has introduced a new paradigm: machine learning models running in a decentralized, incentive-driven network. In theory, this unlocks a global marketplace of intelligence. In practice, however, interacting with that network is still difficult.
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.
Smart Contract Analysis Statement
Contract Analysis
The LayerTao (LAYERTAO) contract implements an ERC20 token with a configurable trading fee, automatic fee-to-ETH swap and distribution to two designated fee receivers, per-wallet holding limits, and a claimable ETH fallback mechanism for failed distributions. It is built on OpenZeppelin v4.9 (ERC20, Ownable, ReentrancyGuard, SafeERC20) with a fixed supply of 100,000,000 tokens minted at deployment. While the overall design follows common patterns for fee-on-transfer tokens on Ethereum, a few areas need attention:
- The auto-swap mechanism that converts accumulated fee tokens to ETH uses zero slippage protection (
amountOutMin = 0) and an ineffective deadline (block.timestamp), making every swap maximally extractable by MEV bots. While this only affects ETH flowing to fee receivers and is bounded by the swap threshold, it represents a persistent value leak on every auto-swap event. - During the auto-swap phase, ETH is pushed directly to fee receiver addresses with unrestricted gas forwarding. If a fee receiver is a contract rather than an externally owned account, this opens a cross-function reentrancy window where the receiver could interact with the token contract before the swap phase completes. Users should verify the current fee receiver addresses are standard wallets.
- The owner can disable the auto-swap mechanism and immediately withdraw all accumulated fee tokens to their own address, bypassing the normal ETH distribution to the configured fee receivers. There is no timelock, cooldown period, or multi-signature requirement between these two actions.
Ownership Privileges
The ownership of the contract follows OpenZeppelin's single-owner Ownable pattern. The owner retains full privileges including:
- Exempt any wallet from trading fees or per-wallet holding limits
- Change the two fee receiver addresses and their distribution shares at any time
- Reduce the trading fee to any lower value (currently 5%, can only decrease)
- Enable or disable the auto-swap mechanism
- Withdraw accumulated fee tokens from the contract (when swap is disabled)
- Withdraw stuck ETH and foreign ERC20 tokens sent to the contract
- Add or remove secondary liquidity pairs
- Adjust the swap threshold and per-wallet holding limit
However, the contract also enforces the following limitations on owner actions:
- The trade fee can never be increased -
updateTradeFeerequires the new fee to be strictly lower than the current one. At 5% today, it can only go down or stay unchanged. - The per-wallet holding limit can never be decreased -
updateTokenLimitPerWalletrequires the new limit to be equal to or higher than the current value. - The primary liquidity pair is immutable and cannot be removed or changed.
- The total supply is permanently fixed at 100,000,000 tokens. There is no mint function, no burn function, no blacklist mechanism, and no upgrade path.
Security Features
The contract implements several positive security features:
- OpenZeppelin's ReentrancyGuard protects the
claimFeesandwithdrawStuckETHfunctions against reentrancy, and theclaimFeesfunction follows the Checks-Effects-Interactions pattern by zeroing the claimable balance before the external call. - A fallback mechanism credits failed ETH distributions to a
claimableETHmapping, allowing fee receivers to recover funds viaclaimFeesrather than losing them permanently. ThewithdrawStuckETHfunction correctly reserves these claimable amounts and only allows withdrawal of excess ETH. - The auto-swap uses
try/catcharound the router call, preventing a failed swap from blocking all token transfers. Failed swaps emit aSwapFailedevent for off-chain monitoring. - All administrative functions emit events, providing a transparent on-chain audit trail. Input validation includes zero-address checks, duplicate checks, and boundary enforcement on all owner-configurable parameters.
Note - This audit report consists of a security analysis of the LayerTao smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the LayerTao 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
low Issues | 3 findings
Pending
#1 low Issue
Auto-swap uses zero slippage protection (`amountOutMin = 0`)
The auto-swap path calls `swapExactTokensForETHSupportingFeeOnTransferTokens` with `amountOutMin = 0`, accepting any output amount. This makes swaps vulnerable to sandwich/value extraction. Impact is bounded by `swapThreshold` and primarily reduces ETH distributed to fee receivers.
Pending
#2 low Issue
External ETH push in `_transfer` creates reentrancy-sensitive execution window
During sell-triggered auto-swap, `_transfer` performs external calls via `sendETH` before `swapping` is reset. While this is not a strong permissionless exploit vector, it expands risk if fee receiver addresses are malicious/misconfigured contracts. This is primarily a trust-model/operational risk tied to privileged configuration.
Pending
#3 low Issue
Owner can redirect accumulated fee tokens by disabling swap and withdrawing
Owner can call `toggleSwap(false)` and then `withdrawFeeTokens()` to transfer contract-held fee tokens to owner. This bypasses normal swap-to-ETH distribution flow and represents a centralization/trust assumption.
optimization Issues | 1 findings
Pending
#1 optimization Issue
Use named basis-point constant instead of repeated `10000`
Repeated literal `10000` appears across validation and fee calculations. A named constant improves maintainability and reduces accidental inconsistency.
informational Issues | 4 findings
Pending
#1 informational Issue
Fee receiver/share config is not directly observable via public getters
`feeReceiver` and `feeShare` are private and not directly queryable through explicit getters, reducing visibility of live fee-routing configuration.
Pending
#2 informational Issue
Defensive check absent before ETH balance subtraction
`withdrawStuckETH` computes `address(this).balance - totalClaimableETH` without a prior explicit guard. Solidity 0.8 protects via revert, but error context is less clear.
Pending
#3 informational Issue
Swap deadline uses current block timestamp
Using `block.timestamp` as deadline provides little practical stale-tx protection. This is mainly an execution-quality anti-pattern and compounds low-slippage safeguards.
Pending
#4 informational Issue
Fee wallet updates do not validate ETH receivability
`updateFeeWallet` checks only zero/duplicate addresses. Non-payable or incompatible contract wallets can force fallback accounting and potentially strand distributions operationally.